KR101647144B1

KR101647144B1 - 원격 유저 인터페이스 서비스에서 리소스에 대한 제어 방법, 장치 및 그 저장 매체

Info

Publication number: KR101647144B1
Application number: KR1020090093532A
Authority: KR
Inventors: 류영선; 이국희; 송재연
Original assignee: 삼성전자주식회사
Priority date: 2008-11-03
Filing date: 2009-09-30
Publication date: 2016-08-23
Also published as: WO2010062064A2; WO2010062064A3; KR20100049481A; WO2010062064A4; CN102239482A; EP2359255A4; EP2359255B1; CN102239482B; EP2359255A2

Abstract

본 발명은 원격 유저 인터페이스(Remote User Interface:RUI)시스템에서 RUI 서버의 리소스에 대한 이용을 제한하는 방법 및 장치에 관한 것으로, RUI 클라이언트에 의해 접근 가능한, RUI 서버의 모든 리소스 각각에 대응하여, RUI 클라이언트에 의한 현재의 점유 상태를 나타내는 뮤텍스(MUTEX:Mutual Exclusion)를 구비한다. 그리고 RUI 클라이언트가 RUI 서버의 특정 리소스를 이용하고자 할 때에, 특정 리소스에 대응하는 뮤텍스를 액세스하여 다른 RUI 클라이언트에 의한 점유 상태를 확인하고, 해당 뮤텍스가 이용 제한 상태라면, 일정한 응답 대기 시간 내에 특정 리소스에 대한 이용이 종료되는 경우, 또는 RUI 클라이언트에 의한 이용 양도 요청에 따라 특정 리소스에 대한 이용이 양도되는 경우에, RUI 클라이언트는 특정 리소스를 이용할 수 있게 된다.

RUI, MUTEX, 이용 권한

Description

원격 유저 인터페이스 서비스에서 리소스에 대한 제어 방법, 장치 및 그 저장 매체{METHOD AND APPARATUS FOR　CONTROLLING A RESOURCE OF A REMOTE USER INTERFACE SERVICE THEREOF COMPUTER READABLE MEDIUM}

본 발명은 원격 유저 인터페이스(Remote User Interface: RUI)에 관한 것으로, 특히, 원격 UI 서버(Remote UI Server)가 RUI를 제공하고, 원격 UI 클라이언트(Remote UI Client)가 이를 통해 원격지의 디바이스를 제어할 때, RUI 서버의 리소스에 대한 이용을 제어하는 방법에 관한 것이다.

DLNA(Digital Living Network Alliance), HAVi(Home Audio-Video Interoperability), UPnP(Universal Plug and Play) 등과 같은 많은 산업 표준 단체들에 의해 홈 네트워크 기술의 향상을 위한 연구가 활발히 진행되고 있다. 이러한 홈 네트워크에서 하나의 디바이스가 다른 디바이스의 기능을 제어하기 위해 RUI(Remote User Interface) 기술이 사용될 수 있다. 간단하게 설명하면, RUI 기술은 클라이언트-서버 아키텍쳐를 기반으로 한 것으로, RUI 클라이언트가 RUI 서버로부터 UI를 가져와서, 사용자가 RUI 클라이언트에서 UI를 통해 RUI 서버를 제어할 수 있도록 하는 기술이다.

RUI에 관한 표준인 CEA-2014는 UPnP(Universal Plug and Play) 네트워크와 인터넷상에서의 RUI를 위한 프로토콜과 프레임 워크를 정의하는데, CEA-2014에 의하면 UPnP 디바이스(RUI 서버)는 사용자 인터페이스를 CE-HTML 형식의 웹 페이지로 제공하고, 사용자는 이러한 웹 페이지를 통해 원격에서 UPnP 디바이스의 애플리케이션을 제어할 수 있다. CE-HTML은 HTML의 특수한 버전으로, XHTML을 기반으로 한다.

도1은 CEA-2014 표준에 따라 RUI 서버와 RUI 클라이언트가 통신하는 방법을 나타낸 도면이다. 홈 네트워크에서 RUI를 사용하기 위해서는 우선 RUI 서버(20)에 대한 탐색(discovery)이 수행되어야 한다. CEA-2014는 UPnP 네트워크를 기반으로 하기 때문에 RUI 서버(20)를 UPnP 탐색(Discovery) 과정을 통해 발견한다. 도1에서는 RUI 클라이언트(10)와 컨트롤 포인트(CP, Control Point)(30)를 분리하여 표시하였으나, RUI 클라이언트(10)에 UPnP CP(30)가 내장(embedded)된 경우에는 RUI 클라이언트(10)가 직접 RUI 서버(20)를 발견할 것이다. 만약 RUI 클라이언트(10)에 CP(30)가 없고 별도의 CP(30)에서 RUI 서버(20)의 UI(User Interface)를 RUI 클라이언트(10)로 보내려고 할 때에는 RUI 클라이언트(10)도 CP(30)가 UPnP 탐색을 통해 발견한다.

탐색 과정이 끝나면 RUI 클라이언트(10)는 UPnP 장치 디스크립션(Device Description) 내에 포함된 RUI 페이지가 있는 URL을 참고하여 RUI 페이지를 획득한다. 더욱 상세하게는, RUI 클라이언트(10)의 XHTML 브라우저(browser)가 RUI 서버(20)의 웹 서버에게 UI페이지를 요구한다. RUI 페이지는 RUI 서버(20)의 애플리 케이션(application)을 제어할 수 있도록 구성되어 있으므로, RUI 클라이언트(10)는 RUI 페이지를 이용하여 RUI 서버(20)의 애플리케이션을 제어한다. 종래 기술에 따라 RUI 서버(20)와 RUI 클라이언트(10)가 통신하는 방법은 CEA-2104 표준 등의 문헌에 상세하게 설명되어 있으므로, 여기서는 더 이상의 설명을 생략한다.

이와 같이, 종래 기술에서의 RUI 서비스는 일반적인 웹 서버(Web server) - HTML 브라우저(Browser)의 구조를 기반으로 하고 있다. 일반적인 웹 서버는 특정 리소스의 접근에 대한 관리를 하고 있지 않으며, 단지 브라우저에서 요구하는 페이지를 리턴해 준다. 따라서 일반적으로 웹 서버에서는 어떤 브라우저가 페이지를 요구하고 난 후, 종료되었는지의 여부와 같은 정보를 전혀 알 수 없으므로, 클라이언트의 접속을 관리할 수 없다.

그러나 CEA-2014와 같이 웹 서버가 단순히 클라이언트에게 정보를 제공하는 것이 아니라, 제공된 정보, 즉 RUI 페이지를 통해 RUI 서버(20)의 기능을 제어하는 경우에는 리소스에 대한 RUI 클라이언트(10)의 이용 권한을 제어할 필요가 있다. 이는 어떤 사용자가 기기를 제어하는 도중에 다른 사용자가 동일한 기기를 제어하여 기기 사용에 있어서의 충돌이 발생할 수 있기 때문이다.

예를 들어, 튜너 제어(Tuner control), 전화 라인(Phone line)등은, 경우에 따라, 하나의 클라이언트가 사용 중일 경우 다른 클라이언트가 동일한 리소스 또는 애플리케이션 리소스에 접근하지 못하도록 제어할 필요가 있다.

다른 예로, 도2에 도시된 바와 같이, RUI 클라이언트 A(11)가 41단계에서　RUI 서버(20)로부터 RUI 페이지를 획득한 후, 43단계에서 특정 채널을 통해 수신되는 방송 프로그램에 대한 녹화를 요청하면, RUI 서버(20)는 해당 방송 프로그램을 녹화한다. 한편, RUI 클라이언트 B(12)가 51단계에서 RUI 서버(20)로부터 RUI 페이지를 획득하고, 51단계에서 획득한 RUI 페이지를 통해 RUI 서버(20)에게 상기 방송 프로그램에 대한 녹화 취소를 요청할 수 있다. 하지만, 이때에 RUI 클라이언트 A(11)가 녹화 유지를 원할 경우, 문제가 발생한다.

이러한 문제를 해결하기 위해 RUI 클라이언트(10)와 RUI 서버(20) 간의 접속 또는 세션을 관리하고자 하는 경우에는 웹 서버에서 별도로 사용자 별로 접속을 관리하기 위한 데이터베이스를 두거나, RUI 클라이언트(10)가 애플리케이션 별로 active X와 같은 플러그 인(plug-in)을 사용할 수밖에 없다. 그러나 일반적으로 CE 기기는 다양한 OS를 사용하고 리소스가 여유롭지 않으므로, 자유롭게 플러그 인을 설치할 수 없는 문제가 있다.

본 발명은 이와 같은 문제점을 해결하기 위해 여러 개의 RUI 클라이언트가 RUI 서버의 특정 리소스에 대해 사용을 시도할 때 이를 제어할 수 있는 방법 및 장치를 제공한다.

그리고 본 발명은 RUI 클라이언트가 사용이 제한된 리소스를 사용하려고 할 때, RUI 클라이언트에게는 적정한 RUI를 제공할 수 있는 방법 및 장치를 제공한다.

한편, 본 발명은, RUI(Remote User Interface) 시스템에서 RUI 클라이언트가 RUI 서버의 리소스에 대한 액세스를 제어하는 방법에 있어서, 상기 RUI 서버로 상기 리소스를 제어하기 위해 RUI 페이지 요청을 전송하고, 상기 RUI 페이지를 수신하는 과정과, 상기 수신된 RUI페이지를 이용하여, 상기 리소스에 대응하는 상기 RUI 서버의 뮤텍스(MUTEX:Mutual Exclusion)에 대한 커넥션을 생성하는 과정과, 상기 리소스에 대한 액세스를 제한하기 위한 뮤텍스 잠금 요청을 전송하는 과정을 포함함할 수 있다.

그리고 본 발명은, RUI(Remote User Interface) 시스템에서 RUI 서버가 상기 RUI 서버의 리소스에 대한 액세스를 제어하는 방법에 있어서, RUI 클라이언트의 요청에 따라, 상기 리소스를 제어하기 위해 RUI 페이지를 상기 RUI 클라이언트로 전송하는 과정과, 상기 리소스에 대응하는 상기 RUI 서버의 뮤텍스(MUTEX:Mutual Exclusion)에 대한 커넥션을 생성하는 RUI 클라이언트로부터, 상기 리소스에 대한 액세스를 제한하기 위한 뮤텍스 잠금 요청을 수신하는 과정을 포함할 수 있다.
또한 본 발명에 따라, RUI(Remote User Interface) 시스템에서 RUI 서버의 리소스에 대한 액세스를 제어하는 RUI 클라이언트 장치는 상기 RUI 서버와 통신하는 통신부와, 상기 RUI 서버의 상기 리소스에 대한 액세스를 제어하는 제어부를 포함하며, 상기 제어부는 상기 RUI 서버로 상기 리소스를 제어하기 위해 RUI 페이지 요청을 전송하고, 상기 RUI 페이지를 수신하는 웹 브라우저 모듈과, 다른 RUI 클라이언트에의해 상기 RUI 페이지에서 선택된 리소스에 대한 액세스 제한 요청을 상기 RUI 서버로 전송하는 뮤텍스(MUTEX:Mutual Exclusion) 핸들러를 포함하며, 상기 RUI 서버로부터 상기 선택된 리소스에 대한 액세스 허가를 수신하면, 상기 웹 브라우저 모듈은 상기 선택된 리소스를 제어할 수 있는 RUI 페이지를 사용자에게 제공할 수 있다.
그리고 본 발명에 따라, RUI(Remote User Interface) 시스템에서 리소스에 대한 액세스를 제어하는 RUI 서버 장치는, 상기 RUI서버 장치에 의해 제공되는 애플리케이션들과 관련된 각각의 제어 소유권에 대응하는 각각의 리소스에 대응하는 복수의 뮤텍스(MUTEX:Mutual Exclusion)에 대한 정보를 저장하는 저장부와, RUI 클라이언트의 요청에 따라, 상기 리소스를 제어하기 위해 RUI 페이지를 상기 RUI 클라이언트로 전송하고, 다른 RUI 클라이언트에 의해 상기 RUI페이지에서 선택된 리소스에 대한 액세스 제한 요청을 상기 RUI 클라이언트로부터 수신함에 따라, 상기 선택된 리소스에 대한 액세스 요청을 수신하고, 상기 선택된 리소스에 대응하는 뮤택스가 액세스 제한 상태를 나타내지 않으면, 상기 선택된 리소스에 대한 액세스 허가를 상기 RUI 클라이언트로 전송하는 웹 서버를 포함할 수 있다.

본 발명은 여러 개의 RUI 클라이언트가 RUI 서버의 리소스에 대한 접근을 시도할 때 이를 제어할 수 있으며, RUI 클라이언트에게 적정한 RUI를 제공할 수 있고, 이에 따라 원활한 원격 제어가 이루어지도록 할 수 있다.

이하, 첨부된 도면을 참조하여 본 발명에 따른 바람직한 일실시예를 상세히 설명한다. 도면에서 동일한 구성요소들에 대해서는 비록 다른 도면에 표시되더라도 가능한 한 동일한 참조번호 및 부호로 나타내고 있음에 유의해야 한다. 또한, 본 발명을 설명함에 있어서, 관련된 공지기능 혹은 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명은 생략한다.

본 발명이 적용되는 원격 유저 인터페이스(Remote User Interface:RUI) 서비스는 RUI 서버가 RUI를 제공하고, RUI 클라이언트가 제공된 RUI를 통해 원격지의 디바이스를 제어하는 서비스이다. 본 발명은 이러한 RUI 서비스에서 RUI 서버의 리소스에 대한 이용 권한을 제어하고 관리하는 방법을 제안한다.

이에 따라, 본 발명은 RUI 클라이언트에 의해 접근 가능한, RUI 서버의 모든 리소스 각각에 대응하여, RUI 클라이언트에 의한 현재의 점유 상태를 나타내는 뮤텍스(MUTEX:Mutual Exclusion)를 구비한다. 그리고 임의의 RUI 클라이언트가 RUI 서버의 특정 리소스를 이용하고자 할 때에 해당 리소스를 곧장 액세스할 수 있게 하는 것이 아니라, 특정 리소스에 대응하는 뮤텍스를 액세스하여 다른 RUI 클라이언트에 의한 점유 상태를 확인하게 한다. 그리고 확인 결과에 따라 임의의 RUI 클라이언트의 특정 리소스 이용에 대한 허여가 결정되게 하는 것이다. 만약, 특정 리소스가 이미 다른 RUI 클라이언트에 의해 점유되어 해당 뮤텍스가 이용 제한 상태라면, 일정한 응답 대기 시간 내에 특정 리소스에 대한 이용이 종료되는 경우, 또는 임의의 RUI 클라이언트에 의한 이용 양도 요청에 따라 특정 리소스에 대한 이용이 양도되는 경우에, 임의의 RUI 클라이언트는 특정 리소스를 이용할 수 있게 된다.

이러한 RUI 서비스가 적용되는 RUI 시스템에 대한 본 발명의 일 실시예에 따른 구성을 도3에 도시하였다. 도3을 참조하면, RUI 시스템은 본 발명의 일 실시예에 따라, 하나 이상의 RUI 클라이언트(100,110)와, 하나 이상의 RUI 서버(200)를 포함한다.

제1RUI 서버(200)는 RUI 클라이언트에게 RUI를 제공할 수 있는 서버로서, 본 발명의 일 실시예에 따라 웹 서버(201), 복수의 RUI 콘텐츠(content)(211,12,213)를 저장하는 콘텐츠 저장부(210)와, 각 RUI 콘텐츠와 1대1 대응하는 복수의 뮤텍스(221,222,223)를 포함한다.

웹 서버(201)는 RUI 페이지를 제공하기 위한 소프트웨어 모듈이다. RUI 페이지는 XHTML(eXtensible HyperText Markup Language) 콘텐츠로 구성되며, 이러한 XHTML 콘텐츠는 제1RUI서버(200)의 애플리케이션에 대한 제어 권한을 관리하기 위한 플러그인 오브젝트가 포함된다. 이에 따라 RUI 클라이언트의 웹 브라우저(Web Browser) 모듈은 플러그 인 오브젝트를 해석할 수 있으며, 이 플러그인 오브젝트는 제어 권한의 관리를 위한 것이므로 사용자에게 보여줄 필요는 없다.

그리고 웹 서버(201)는 본 발명에 따라 각 제어 리소스에 대한 이용 제한 또는 제한 해제와 같은 복수의 뮤텍스(221,222,223)의 상태 설정을 관리한다.

콘텐츠 저장부(210)는 RUI를 표시하기 위해 XHTML, 이미지, 스크립트(script)등으로 구성된 하나 이상의 RUI 콘텐츠(211,12,213)를 저장한다. RUI 콘텐츠(211,12,213) 각각은 제1RUI 서버(200)에서 제공하는 애플리케이션과 관련된 제어 권한 각각에 대응하는 리소스를 나타낸다.

본 발명의 일 실시예에 따라 하나의 RUI 콘텐츠(211,12,213), 즉, 하나의 리소스 당 하나의 뮤텍스(221,222,223)가 존재하며, 뮤텍스(221,222,223)는 대응 리소스에 대한 RUI 클라이언트에 의한 현재의 점유 상태를 나타낸다. 각각의 뮤텍스(221,222,223)는 URL(Uniform Resource Locator)로 구분되며, 각 뮤텍스(221,222,223)의 URL은 RUI 페이지에 포함되어 RUI 클라이언트로 전달될 수 있다.

때문에 임의의 RUI 클라이언트는 특정 리소스를 이용하고자할 때, 특정 리소스에 대응하는 뮤텍스에 접근하여 특정 리소스가 다른 RUI 클라이언트에 의해 점유되어 있는지 확인한다. 이때, 뮤텍스에 대한 접근은 네임드 리소스(named resource) 방식에 의해 이루어진다. 만약, 특정 리소스가 다른 RUI 클라이언트에 의해 이미 점유된 상태라면 해당 뮤텍스는 이용 제한 상태를 유지하고, 어떠한 RUI 클라이언트에 의해서도 특정 리소스가 점유되어 있지 않다면 해당 뮤텍스는 제한 해제 상태가 된다. 임의의 RUI 클라이언트는 특정 리소스의 뮤텍스가 이용 제한 해제 상태일 때 특정 리소스에 대한 이용 권한을 획득할 수 있게 된다. 리소스에 대한 이용 제한 상태는 뮤텍스 잠금으로, 리소스에 대한 이용 제한 해제 상태는 뮤텍스 잠금 해제로 표현할 수도 있다.

이에 따라, 동시에 여러 개의 RUI 클라이언트가 하나의 리소스에 접근을 시도할 때는, 뮤텍스에 대한 접근 권한을 획득한 후에 해당 리소스를 사용할 수 있게 된다.

제1RUI 클라이언트(100)와 제2RUI 클라이언트(110)는 유사하게 구성되며, 이에 따라 하기 설명에서는 제1RUI 클라이언트(100)의 제1UI 셸(User Interface shell) 모듈(101), 제1웹 브라우저 모듈(102), 제1플러그인 인터페이스(103), 제1뮤텍스 핸들러(Mutual Exclusion handler)(104)에 대해서만 설명하지만, 제2RUI 클라이언트(110)의 제2UI 셸 모듈(111), 제2웹 브라우저 모듈(102), 제2플러그인 인터페이스(113), 제2뮤텍스 핸들러(114)에 대해 유사한 기능 및 동작이 적용될 수 있다.

제1RUI 클라이언트(100)는 제1UI 셸모듈(101), 제1웹 브라우저 모듈(102), 제1플러그인 인터페이스(103), 제1뮤텍스 핸들러(104)를 포함한다.

제1웹 브라우저 모듈(102)은 XHTML로 구성된 RUI 페이지를 렌더링(rendering)하고 표현(presentation)하는 소프트웨어 모듈 이다. 그리고 제1웹 브라우저 모듈(102)은 사용자 입력에 대응하여 RUI 페이지를 요청하고, RUI 페이지 상에서 선택된 임의의 리소스에 대응하는 제어 명령을 RUI 서버로 송신하는 과정을 제어한다.

제1UI 셸 모듈(101)은 검색된 네트워크 내의 가용한 UI들의 리스트를 표시하고, 사용자의 입력을 수신하는 모듈이다.

제1뮤텍스 핸들러(104)는 제1RUI 서버(200)의 뮤텍스에 대한 접근 제어를 담당하는 플러그인 오브젝트(plug in object) 이다. 제1뮤텍스 핸들러(104)는 본 발명의 일 실시예에 따라 CE-HTML 내의 오브젝트 태그(tag)로 구동될 수 있으며, 하나의 뮤텍스 핸들러는 여러 개의 뮤텍스에 대한 접근 제어를 관리할 수 있다.

상기한 바와 같이 구성 되는 RUI 시스템에서 본 발명의 일 실시예에 따른 RUI 클라이언트의 동작 과정을 도4에 나타내었고, RUI 서버의 동작 과정을 도5에 나타내었다. 도4 및 도5의 설명에서는 제1RUI 클라이언트(100)를 예로 들어 설명하지만, 제2RUI 클라이언트(110)에도 동일한 과정이 적용될 수 있다.

제1RUI 클라이언트(100)의 사용자는 원격으로 제어하고자 하는 장치로, 제1RUI 서버(200)를 지정하여, 제1RUI 서버(200)에게 RUI 페이지를 요청하는 입력을 제1UI 셀 모듈(101)을 통해 제1RUI 클라이언트(100)로 입력한다. 이에 따라, 도4를 참조하면, 제1RUI 클라이언트(100)는 301단계에서 제1RUI 서버(200)에게 RUI 페이지를 요청한다.

이렇게 제1RUI 클라이언트(100)가 RUI 페이지를 요청함에 따라, 도5를 참조하면, 제1RUI 서버(200)는 401단계에서 RUI 페이지 요청을 수신하게 되고, 웹 서버(201)에 의해 구성된 RUI 페이지를 제1RUI 클라이언트(100)로 전송한다.

제1RUI 클라이언트(100)는 303단계에서 RUI 페이지를 수신하고, 305단계에서 제1웹 브라우저 모듈(102) 및 제1UI 셀 모듈(101)을 통해 사용자에게 제공한다.

제1RUI 클라이언트(100)가 305단계에서 RUI 서버의 리소스 접근을 시도하면, 307단계에서 제1뮤텍스 핸들러(104)는 해당 리소스에 대한 이용 및 이용 제한을 제1RUI 서버(200)로 요청한다. 상기 이용 제한 요청은 해당 제어 리소스를 제1RUI 클라이언트(100)가 독점하기 위한 것으로, 제1뮤텍스 핸들러(104)가 해당 제어 리소스에 대응하는 뮤텍스에 연결하여, 뮤텍스의 상태을 이용 제한으로 변경하는 것을 요청함으로써, 이루어진다. 리소스의 이용 요청 또한 뮤텍스의 상태를 이용 제한으로 변경하는 요청을 전달함으로써 이루어질 수 있다.

이에 따라, 제1RUI 서버(200)는 403단계에서 특정 리소스에 대한 이용 및 이용 제한 요청을 수신하면, 405단계에서 특정 리소스가 이용 제한 상태인지 확인한다. 다시 말해, 제1RUI 서버(200)가, 특정 제어 리소스에 대응하는 뮤텍스의 상태가 이용 제한 상태인지 확인한다. 확인 결과, 특정 리소스가 어떠한 RUI 클라이언트에 의해서도 점유되어 있지 않아, 해당 뮤텍스가 이용 제한 상태가 아니면, 웹 서버(201)는 421단계로 진행하여 특정 리소스의 뮤텍스에 이용 제한을 설정하고, 제1RUI 클라이언트(100)로 이용이 가능함을 알린다.

이에 따라, 제1RUI 클라이언트(100)는 309단계에서 응답 대기 시간 내에 이용 허여를 수신하게 되고, 321단계로 진행하여, 제1웹 브라우저 모듈(102)이 특정 리소스에 대한 이용 가능한 RUI 페이지를 사용자에게 제공할 수 있다.

만약, 상기 405단계에서 특정 제어 리소스의 뮤텍스가 이용 제한 상태라면, 제1RUI 서버(200)의 웹 서버(201)는 407단계로 진행하여 응답 대기 시간 내에 해당 리소스를 현재 점유하고 있는 RUI 클라이언트로부터 이용 제한 해제 요청이 수신되는지 확인한다. 만약, 수신되면 상기 421단계로 진행하여, 웹 서버(201)가 상기 RUI 클라이언트에 의한 이용 제한은 해제하고, 제1RUI 클라이언트(100)의 요청에 대응하여 특정 리소스에 대한 이용 제한을 설정하고, 제1RUI 클라이언트(100)에게 이용 가능함을 알린다.

이에 따른, 제1RUI 클라이언트(100)의 동작은 상기 309단계 및 321단계와 같다.

한편, 407단계에서 응답 대기 시간 내에 해당 제어 리소스를 점유한 RUI 클라이언트로부터 이용 제한 해제 요청이 수신되지 않으면, 웹 서버(201)는 409단계로 진행하여 제1RUI 클라이언트(100)에게 이용 불가를 통보하고, 제1RUI 클라이언트(100)는 311단계에서 이용 불가를 통보받게 된다.

이용 불가를 통보 받으면, 제1RUI 클라이언트(100)는 이용 불가능한 리소스 RUI 페이지를 사용자에게 제공한다.

이후, 사용자의 선택 입력에 따라 또는 자동으로 제1RUI 클라이언트(100)의 뮤텍스 핸들러(104)는 특정 리소스에 대한 이용 양도를 제1RUI 서버(200)로 요청한다.

이에 따라, 제1RUI 서버(200)가 411단계에서 이용 양도 요청을 수신하게 되면 413단계로 진행하여, 현재 특정 리소스를 이용하고 있는 RUI 클라이언트로 특정 리소스에 대한 이용 양도를 요청한다. 이후, 415단계에서 제1RUI 서버(200)는 특정 리소스에 대한 이용 양도를 허여하는 응답을 수신하면 417단계로 진행하여, 특정 리소스에 대한 이용 제한을 제1RUI 클라이언트(100)에 의한 것으로 재설정하고, 이용 양도가 성공하였음을 제1RUI 클라이언트(100)로 전송한다.

이로 인해, 제1RUI 클라이언트(100)는 317단계에서 이용 양도 성공 메시지를 수신하게 되어 상기 321단계로 진행하여, 이용 가능한 리소스 RUI 페이지를 사용자에게 제공하게 된다.

한편, 415단계에서 제1RUI 서버(200)가 현재 특정 리소스를 이용하고 있는 RUI 클라이언트로부터 특정 리소스에 대한 이용 양도를 거부하는 응답을 수신하면, 웹 서버(201)는 419단계로 진행하여, 이용 양도가 실패하였음을 제1RUI 클라이언트(100)로 전달한다.

이 경우, 제1RUI 클라이언트(100)는 317단계에서 이용 양도 실패를 통보받고, 319단계로 진행하여 최종 이용 불가 메시지를 제공하고 동작 과정을 종료한다.

상기한 과정 중, 제1RUI 클라이언트(100)는 321단계를 수행한 이후에, 323단계에서 특정 제어 리소스에 대한 이용이 완료되면, 이용 제한 해제 요청을 제1RUI 서버(200)에게 전달한다. 이에 따라 제1RUI 서버(200)는 상기 423단계에서 리소스 이용 제한 해제 요청을 수신하고, 425단계로 진행하여 특정 리소스에 대응하는 뮤텍스를 이용 제한 해제 상태로 변경한다.

상기한 바와 같이 구성되고, 동작하는 RUI 시스템에서 본 발명의 일 실시예에 따라 사용되는 제어 소유자 플러그인(control ownership plugin) 오브젝트는 다음 표1과 같다.

Property
Number MutexStatus	현재 뮤텍스의 상태 정보를 나타냄.
String Content URL	로드할 RUI 페이지를 명시하는 URL 스트링.
function onMutextLock()	MutextLock()이 완료되면 호출되는 콜백(callback) 함수.
function onReleaseRequest()	이용 제한을 위해 잠금(locking)되어 있는 뮤텍스에 대한 잠금 해제 요청이 발생하면 호출되는 콜백(callback)함수.
Method
MutexOpen(MutexURL)	MutexURL에 기술되어 있는 뮤텍스 리소스로의 커넥션을 생성.
MutexLock(Number TimeoutMS, Boolean ReleaseRequested)	해당 뮤텍스에 대응하는 제어 리소스의 이용을 제한하기 위해 해당 뮤텍스에 대한 잠금(lock)을 요청. 해당 요청은 timeoutMS에 기술된 시간만큼 대기함.
MutexUnlock()	해당 뮤텍스에 대한 잠금 해제(un-lock)를 시도.
MutexTryLock()	뮤텍스에 대한 잠금(Lock)이 가능한지 확인. MutexLock()과 동일하나 뮤텍스에 대한 상태는 변하지 않음.
MutexClose()	해당 뮤텍스에 대한 연결을 해제함.

그리고 상기 표1의 제어 소유자 플러그인(control ownership plugin) 오브젝트를 이용하여, 본 발명의 일 실시예에 따라 RUI 클라이언트와 RUI 서버가 동작하는 과정의 예를 도6 및 도7에 도시하였다.

도6은 본 발명의 일 실시예에 따라 제1RUI 클라이언트(100)가 제1RUI 서버(200)의 리소스 A를 먼저 점유한 상태에서 제2RUI 클라이언트(110)가 리소스 A에 대한 이용을 요청했을 때, 응답 대기 시간 내에 제1RUI 클라이언트(110)가 리소스 A에 대한 점유를 취소한 경우를 나타낸 것이다.

도6을 참조하면, 제1RUI 클라이언트(100)는 501단계에서 제1RUI 서버(200)로 RUI 페이지를 요청한다. 제1RUI 서버(200)는 RUI 페이지 요청에 따라 503단계에서, 제1RUI 클라이언트(100)로 제어 소유권 플러그인 오브젝트(Control ownership plugin object)가 포함된 CE-HTML 페이지, 즉, RUI 페이지를 구성하여 전달한다. RUI 페이지를 수신한 제1RUI 클라이언트(100)는 505단계에서 제1RUI 서버(200)로 제어 리소스 A에 대한 MutexOpen()을 호출하여 MutexURL에 기술되어 있는 리소스 A의 뮤텍스에 커넥션(connection)을 생성한다. 이후 제1RUI 클라이언트(100)는 507단계에서 제1RUI 서버(200)로 MutexLock()을 호출하여 리소스 A에 대한 다른 RUI 클라이언트의 이용을 방지하기 위해 리소스 A의 뮤텍스에 대한 잠금(lock)을 요청한다. 뮤텍스에 대한 잠금 요청은 리소스 A에 대한 이용 제한 요청에 해당한다. 이는 해당 뮤텍스가 지정하고 있는 애플리케이션(application)의 리소스 A에 대한 독점 사용을 의미한다.

MutexLock()에 대한 수행이 완료되면, 제1RUI 서버(200)는 509단계에서 onMutexLock() 콜백(callback)함수를 성공(succeed)으로 호출하여 제1RUI 클라이언트(100)로 전달한다.

onMutexLock() 콜백 함수가 성공(succeed)으로 호출되면, 제1RUI 클라이언트(100)는 511 단계에서 리소스 A를 제어할 수 있는 RUI 페이지를 로드한다.

한편, 제2RUI 클라이언트(110)는 513단계에서 제1RUI 서버(200)로 제1RUI 클라이언트(100)가 사용중인 RUI 페이지와 동일한 RUI 페이지를 요청한다.

제1RUI 서버(200)는 515단계에서 제2RUI 클라이언트(110)로 제어 소유권 플러그인 오브젝트(Control ownership plugin object)가 포함된 CE-HTML 페이지, 즉, RUI 페이지를 전달한다.

RUI 페이지를 전달받은 제2RUI 클라이언트(110)는 517단계에서 제1RUI 서버(200)로 리소스 A에 대한 MutexOpen()을 호출하여 MutexURL에 기술되어 있는 리소스 A의 뮤텍스에 커넥션(connection)을 생성한다. 그리고 제2RUI 클라이언트(110)는 519단계에서 제1RUI 서버(200)로 MutexLock()을 호출하여 리소스 A의 뮤텍스에 대한 이용 잠금을 요청한다. 하지만 제1RUI 서버(200)에서 해당 뮤텍스는 제1RUI 클라이언트(100)에 의해 이용 잠금이 되어 있기 때문에, 521단계에서 제2RUI 클라이언트(110)는 MutexLock() 호출시 파라미터로 전달한 응답 대기 시간만큼 요청이 수락되기를 기다린다.

제2RUI 클라이언트(110)가 대기하는 동안, 제1RUI 클라이언트(100)가 리소스 A에 대한 사용을 완료하면, 523단계에서 MutexUnlock()을 호출하여 해당 뮤텍스의 잠금 해제를 요청한다. 이에 따라, 제2RUI 클라이언트(110)에 의한 MutexLock() 요청이 완료될 수 있고, 제1RUI 서버(200)는 525단계에서 onMutexLock() 콜백함수를 성공으로 호출하여 제2RUI 클라이언트(110)로 전달한다. 만약, 지정된 응답 대기 시간 동안 제2RUI 클라이언트(110)에 의한 뮤텍스에 대한 이용 잠금이 완료되지 않을 경우 onMutexLock() 콜백 함수는 실패(fail)로 호출된다.

제2 RUI 클라이언트(110)는 성공으로 호출된 onMutexLock() 콜백 함수를 획득하면, 527단계에서 리소스 A를 제어할 수 있는 RUI 페이지를 로드한다. 만약, onMutexLock()이 실패하였을 경우에는 리소스 A를 제어하지 못하는 RUI 페이지가 로드된다.

제2 RUI 클라이언트(110)는 리소스 A에 대한 사용을 완료하면, 529단계에서, 제1RUI 서버(200)에서 MutexUnlock()을 호출하여 리소스 A의 뮤텍스에 대한 잠금을 해제한다.

도7은 본 발명의 다른 실시예에 의한 다음과 같은 상태에서의 제1RUI 클라이언트(100), 제2RUI 클라이언트(110), 제1RUI 서버(200)에 대한 동작 과정을 나타낸 도면이다. 도7의 실시예에서는 제1RUI 클라이언트(100)가 제1RUI 서버(200)의 리소스 A를 먼저 점유한 상태에서 제2RUI 클라이언트(110)가 리소스 A에 대한 이용을 요청했을 때, 응답 대기 시간 내에 제1RUI 클라이언트(110)가 리소스 A에 대한 점유를 취소하지 않는다. 때문에 제2RUI 클라이언트(110)가 제1클라이언트(100)에게 리소스 A 에 대한 이용 권한을 회수하는 경우를 나타낸다. 도7에서 601단계에 내지 621단계까지의 단계는, 도6에서 501단계 내지 521단계와 동일하다.

도7을 참조하면, 619단계의 제2RUI 클라이언트(110)는 리소스 A를 이용하기 위해 뮤텍스 잠금 요청했으나, 리소스 A가 제1RUI 클라이언트(100)에 의해 사용되고 있고, 621단계의 응답 대기 시간 동안 제1RUI 클라이언트(100)가 리소스 A의 이용을 종료하지 않기 때문에, 623단계에서 onMutexLock() 콜백 함수는 실패(fail)로 호출된다.

제2RUI 클라이언트(110)는 625단계에서 리소스 A에 대해 제어가 불가능한 RUI 페이지를 로드한다. 그리고 627단계에서 제2RUI 클라이언트(110)는 MutexLock()에 ReleaseRequested 파라미터를 포함시켜, 잠금 해제를 다시 요청함으로서, 리소스 A에 대한 이용 권한 양도를 요청한다.

이에 따라, 제1RUI 서버(200)는 629단계에서 제1RUI 클라이언트(100)로 onReleaseRequest() 콜백 함수를 호출하여, 리소스 A에 대한 이용 권한 양도를 요청하고, 응답 대기 시간 동안 631단계에서 대기한다.

이용 권한 양도를 요청받은 제1RUI 클라이언트(100)는 리소스 A에 대한 이용 권한을 양도하고자 할 경우 633 단계에서 MutexUnlock()을 호출한다. 이때, 제1RUI 클라이언트(100)가 리소스 A에 대한 이용 권한을 양도하는 것을 거부할 경우 제2RUI 클라이언트(110)는 이용 권한을 획득하지 못하게 된다.

633단계에서 제1RUI 클라이언트(100)로부터 이용 권한이 반환되면, 635단계에서 제2RUI 클라이언트(110)에 onMutexLock() 콜백 함수가 성공적으로 호출되어, 제2RUI 클라이언트(110)가 리소스 A에 대한 이용 권한을 획득하게 된다. 때문에 제2RUI 클라이언트(110)는 637단계에서 리소스 A를 제어할 수 있는 RUI 페이지를 로드한다. 그리고 제2 RUI 클라이언트(110)는 리소스 A에 대한 사용을 완료하면, 639단계에서, 제1RUI 서버(200)에서 MutexUnlock()을 호출하여 제어 리소스 A의 뮤텍스에 대한 잠금을 해제한다.

상술한 본 발명의 설명에서는 구체적인 실시예에 관해 설명하였으나, 여러 가지 변형이 본 발명의 범위에서 벗어나지 않고 실시할 수 있다. 예를 들어 응답 대기 시간은 시스템적으로 정해질 수도 있고, 각 RUI 클라이언트에 의해, 각 RUI 클라이언트별로 정해질 수도 있다. 그리고 RUI 서비스를 지원하는 전자 장치는 그 특성과 역할에 따라서 RUI 서버로 동작할 수도 있고, RUI 클라이언트로 동작할 수도 있다. 그리고 도면에는 도시하지 않았지만, RUI 클라이언트와 RUI 서버는 각각 신호 및 데이터를 송수신할 수 있는 통신부를 포함한다. 따라서 본 발명의 범위는 설명된 실시예에 의하여 정할 것이 아니고 특허청구범위와 특허청구범위의 균등한 것에 의해 정해 져야 한다.

도1은 종래의 RUI 페이지 제공 과정을 나타낸 도면,

도2는 종래의 제어 리소스 이용 과정을 나타낸 도면,

도3은 본 발명의 일 실시예에 따른 RUI 시스템의 구성을 나타낸 도면,

도4는 본 발명의 일 실시예에 따른 RUI 클라이언트의 동작 과정을 나타낸 도면,

도5는 본 발명의 일 실시예에 따른 RUI 서버의 동작 과정을 나타내 도면,

도6 및 도7은 본 발명의 일 실시예에 따른 RUI 서버 및 RUI 클라이언트 동작 과정을 나타낸 도면.

Claims

삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
뮤텍스(MUTEX:Mutual Exclusion) 리소스(resource)에 대한 액세스를 제어하는 원격 사용자 인터페이스(Remote User Interface; RUI) 클라이언트에 있어서,

트랜시버; 및

RUI 서버로 RUI 페이지에 대한 요청을 전송하고, 상기 뮤텍스 리소스와 관련된 제어 소유권 객체(control ownership object)를 포함하는 상기 RUI 페이지를 수신하고, 상기 제어 소유권 객체에 기초하여, 상기 RUI 서버의 상기 뮤텍스 리소스에 대한 연결(connection)을 수립(establish)하고, 상기 제어 소유권 객체에 기초하여 상기 RUI 서버가 다른 RUI 클라이언트에 의한 상기 뮤텍스 리소스에 대한 액세스를 제한하기 위한 뮤텍스 잠금 요청(a request for MUTEX lock)을 호출(invoke)하는 프로세서를 포함함을 특징으로 하는, RUI 클라이언트.
제41항에 있어서,

상기 프로세서는, 상기 RUI 서버에 의해 상기 뮤텍스 리소스가 성공적으로 잠겼음을 지시(indicate)하는 정보를 수신하고, 상기 수신된 정보에 기초하여 상기 수신된 RUI 페이지를 로딩함을 특징으로 하는, RUI 클라이언트.
제41항에 있어서,

상기 프로세서는, 상기 뮤텍스 리소스의 사용이 완료되면, 상기 RUI 서버로 상기 뮤텍스 리소스에 대한 뮤텍스 잠금 해제 요청을 전송함을 특징으로 하는, RUI 클라이언트.
제41항에 있어서,

상기 프로세서는, 다른 RUI 클라이언트가 상기 뮤텍스 리소스를 사용하는 중임이 식별되면, 상기 뮤텍스 잠금 요청을 전송한 후에 대기 시간 동안 대기함을 특징으로 하는, RUI 클라이언트.
제41항에 있어서,

상기 프로세서는, 상기 RUI 서버로부터 상기 뮤텍스 리소스에 대한 이용 불가를 수신하면, 사용자에게 상기 뮤텍스 리소스에 대한 제어 불가능한 RUI 페이지를 제공함을 특징으로 하는, RUI 클라이언트.
제41항에 있어서,

상기 제어 소유권 객체는, 상기 뮤텍스 리소스에 대한 점유 상태를 나타내는 정보를 포함함을 특징으로 하는, RUI 클라이언트.
제41항에 있어서, 상기 프로세서는,

상기 다른 RUI 클라이언트에 의해 상기 뮤텍스 리소스가 사용 중임을 나타내는, 상기 뮤텍스 리소스에 대한 이용 불가를 상기 RUI 서버로부터 수신하면, 상기 뮤텍스 리소스에 대한 액세스 제한 해제 요청을 송신하고,

상기 액세스 제한 요청에 대응하여 성공적인 해제를 수신하면, 사용자에게 상기 뮤텍스 리소스 제어를 위한 상기 RUI 페이지를 제공함을 특징으로 하는, RUI 클라이언트.
제42항에 있어서,

상기 프로세서는, 상기 RUI 클라이언트에 상기 RUI 페이지를 디스플레이함을 특징으로 하는, RUI 클라이언트.
뮤텍스(MUTEX:Mutual Exclusion) 리소스에 대한 액세스를 제어하는 원격 사용자 인터페이스(Remote User Interface; RUI) 서버에 있어서,

트랜시버; 및

상기 뮤텍스 리소스와 관련된 제어 소유권 객체(control ownership object)를 포함하는 RUI 페이지를 RUI 클라이언트로 전송하고, 상기 제어 소유권 객체에 기초하여 상기 RUI 서버가 다른 RUI 클라이언트에 의한 상기 뮤텍스 리소스에 대한 액세스를 제한하기 위한 뮤텍스 잠금 요청(a request for MUTEX lock)을 수신하는 프로세서를 포함함을 특징으로 하는, RUI 서버.
제49항에 있어서,

상기 프로세서는, 상기 뮤텍스 잠금 요청을 수신하면, 상기 다른 RUI 클라이언트에 의한 상기 뮤텍스 리소스에 대한 액세스를 제한함을 특징으로 하는, RUI 서버.
제49항에 있어서,

상기 프로세서는, 상기 뮤텍스 리소스의 사용이 완료되어, 상기 RUI 클라이언트로부터 뮤텍스 잠금 해제 요청을 수신하면, 상기 뮤텍스 리소스에 대한 뮤텍스 잠금을 해제함을 특징으로 하는, RUI 서버.
제49항에 있어서,

상기 프로세서는, 상기 RUI 클라이언트가 상기 뮤텍스 리소스를 사용하는 동안 다른 RUI 클라이언트로부터 상기 뮤텍스 리소스에 대한 뮤텍스 잠금 요청을 수신하면, 상기 다른 RUI 클라이언트에게 뮤텍스 잠금 요청을 허가하기 전에 대기 시간 동안 대기함을 특징으로 하는, RUI 서버.
제49항에 있어서, 상기 프로세서는,

상기 뮤텍스 리소스가 액세스 제한 상태를 지시하면, 현재 상기 뮤텍스 리소스를 액세스하는 다른 RUI 클라이언트로부터 응답 대기 시간 내에 액세스 제한 해제 요청이 수신되는지 확인하고,

상기 응답 대기 시간 내에 상기 액세스 제한 해제 요청이 수신되면, 상기 RUI 클라이언트에게 상기 뮤텍스 리소스에 대한 액세스 허가를 전달하고,

상기 응답 대기 시간 내에 상기 액세스 제한 해제 요청 수신이 실패하면, 상기 RUI 클라이언트에게 상기 뮤텍스 리소스에 대한 이용 불가를 전달함을 특징으로 하는, RUI 서버.
제49항에 있어서,

상기 제어 소유권 객체는, 상기 뮤텍스 리소스에 대한 점유 상태를 나타내는 정보를 포함함을 특징으로 하는, RUI 서버.
제49항에 있어서, 상기 프로세서는,

상기 RUI 클라이언트로부터 상기 뮤텍스 리소스에 대한 액세스 제한 해제 요청을 수신하고,

다른 RUI 클라이언트에게 상기 뮤텍스 리소스에 대한 액세스 제한 해제 요청을 전송하고,

상기 다른 RUI 클라이언트로부터 상기 뮤텍스 리소스의 액세스 제한에 대한 해제 허가를 수신하면, 상기 RUI 클라이언트에게 액세스 제한 해제 성공을 전송하고,

상기 다른 RUI 클라이언트로부터 상기 뮤텍스 리소스의 액세스 제한에 대한 해제 불가를 수신하면, 상기 RUI 클라이언트에게 액세스 제한 해제 실패를 전송함을 특징으로 하는, RUI 서버.
제50항에 있어서,

상기 RUI 페이지는, 상기 RUI 클라이언트에 디스플레이 됨을 특징으로 하는, RUI 서버.