KR101485806B1 - 원격 유저 인터페이스를 지원하는 홈 네트워크에서 이벤트 처리 방법 및 이를 위한 장치 - Google Patents

원격 유저 인터페이스를 지원하는 홈 네트워크에서 이벤트 처리 방법 및 이를 위한 장치 Download PDF

Info

Publication number
KR101485806B1
KR101485806B1 KR20090046736A KR20090046736A KR101485806B1 KR 101485806 B1 KR101485806 B1 KR 101485806B1 KR 20090046736 A KR20090046736 A KR 20090046736A KR 20090046736 A KR20090046736 A KR 20090046736A KR 101485806 B1 KR101485806 B1 KR 101485806B1
Authority
KR
South Korea
Prior art keywords
remote user
user interface
notification
client
request
Prior art date
Application number
KR20090046736A
Other languages
English (en)
Other versions
KR20100128370A (ko
Inventor
류영선
이국희
송재연
Original Assignee
삼성전자주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Priority to KR20090046736A priority Critical patent/KR101485806B1/ko
Priority to PCT/KR2010/003311 priority patent/WO2010137861A2/en
Priority to EP10780772.9A priority patent/EP2436149A4/en
Priority to CN201080033088.7A priority patent/CN102484605B/zh
Priority to US12/788,824 priority patent/US8583726B2/en
Priority to TW099117175A priority patent/TWI501587B/zh
Publication of KR20100128370A publication Critical patent/KR20100128370A/ko
Application granted granted Critical
Publication of KR101485806B1 publication Critical patent/KR101485806B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/12—Arrangements for remote connection or disconnection of substations or of equipment thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
    • H04L12/282—Controlling appliance services of a home automation network by calling their functionalities based on user interaction within the home
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces
    • G06F9/452—Remote windowing, e.g. X-Window System, desktop virtualisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/544—Remote
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/545—Gui

Abstract

본 발명은 원격 유저 인터페이스를 지원하는 홈 네트워크에서 이벤트 처리 방법 및 이를 위한 장치에 관한 것으로, 이러한 본 발명은 상술한 과제를 해결하기 위한 본 발명의 바람직한 실시 예에 따른 원격 유저 인터페이스 클라이언트 및 서버로 이루어진 홈 네트워크에서 이벤트 처리 방법은, 상기 서버가 공지 이벤트를 시퀀스 번호별로 저장하는 과정과, 상기 클라이언트가 상기 홈 네트워크에 접속하면, 홈 네트워크 접속전 수신하지 못한 공지 이벤트의 시퀀스 번호를 상기 서버에 요청하는 과정과, 상기 서버가 상기 수신하지 못한 공지 이벤트의 시퀀스 번호를 상기 클라이언트에 전송하는 과정과, 상기 클라이언트가 상기 서버에 상기 수신하지 못한 공지 이벤트의 시퀀스 번호가 지시하는 공지 이벤트를 요청하는 과정과, 상기 서버가 상기 요청한 공지 이벤트를 상기 클라이언트에 전송하는 과정과, 상기 클라이언트가 상기 공지 이벤트에 포함된 주소를 이용하여 공지 페이지를 수신하는 과정을 포함하는 이벤트 처리 방법 및 이를 위한 장치를 제공한다.
RUI, Remote UI,

Description

원격 유저 인터페이스를 지원하는 홈 네트워크에서 이벤트 처리 방법 및 이를 위한 장치{A method for processing event in a home network supporting Remote User Interface and an apparatus thereof}
본 발명은 원격 유저 인터페이스(RUI, Remote User Interface)를 지원하는 홈 네트워크에서 이벤트 처리 방법 및 장치에 관한 것으로, 특히, 원격 유저 인터페이스(RUI, Remote User Interface)를 지원하는 홈 네트워크에서 제3의 장치인 원격 유저 인터페이스 서버에 저장된 공지 이벤트(notification event)를 사용자에게 재전송하기 위한 이벤트 처리 방법 및 장치에 관한 것이다.
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 서버를 제어할 수 있도록 하는 기술이다.
도 1은 종래 기술에 따른 제3의 장치에서 공지 이벤트(3rd party notification event)의 재전송 방법을 설명하기 위한 도면이다.
도 1에, 제3의 장치(Remote UI Server, 이하, "RUIS"로 표기)(10) 및Remote UI Client(이하, "RUIC"로 표기)(20)가 도시되었다.
RUIS (10)는 RUIC (20)와 UI Session을 유지하지 않은 상황에서도 사용자에게 전달하여야 하는 공지 이벤트(notification event)가 발생함을 감지하면, S101 단계에서 이를 홈 네트워크를 통해 멀티캐스트(Multicast)로 전송한다. 멀티캐스트(Multicast)로 전송된 공지 이벤트(notification event)는 홈 네트워크에 참여하고 있는 RUIC(20)를 포함하는 어떠한 클라이언트(Client)라도 수신할 수 있다.
공지 이벤트(notification event)를 수신한 후 공지 이벤트(notification event)에 포함된 URL을 통해 RUIC(10)는 S103 단계에서 공지 페이지(notification page)를 메소드 "http-get"를 통해 RUIS(20)에 요청하여 해당 event의 RUI(Remote UI)를 표시할 수 있다.
S105 내지 S113 단계는 상술한 S101 및 S103 단계와 같은 일반적인 공지(notification) 과정 중 홈 네트워크 상에 공지 이벤트를 수신할 RUIC가 존재하지 않는 경우를 가정한다.
홈 네트워크 상에 공지 이벤트를 수신할 RUIC(10)가 존재하지 않는 경우, RUIS(20)는 S105 단계에서 공지 페이지를 저장한다.
그런 다음, S107 단계에서와 같이, 홈 네트워크 내에 RUIC(10)가 진입하면, RUIS(20)는 S109 단계에서 수신자가 없어 저장되었던 모든 공지 이벤트(notification event)를 멀티캐스트(Multicast) 방식으로 홈 네트워크에 재전송한다. 멀티캐스트(multicast) 방식으로 공지 이벤트(notification event)를 수신한 RUIC(10)는 공지 페이지(notification page)를 요청하고, RUIS(20)는 http request가 있었을 경우Page를 전송한 후 저장했던 공지 페이지(notification page)를 삭제한다.
도 1에서 살펴 본 바와 같이, 공지 이벤트를 수신할 대상(RUIC)이 없는 경우에 이를 저장하였다가 재전송하는 방법은 몇 가지의 문제가 존재한다.
첫째, 저장된 공지 이벤트(notification event)의 재 전송시 RUIS(20)는 어떤 RUIC(11, 12, 13)가 해당 페이지를 요청했는지를 구분할 수 없다. 이러한 이유로 RUIS(20)는 모든 RUIC들(11, 12, 13)이 수신할 수 있도록 멀티캐스트(Multicast) 방식으로 저장된 공지 이벤트(notification event)를 재전송한다.
이는 홈네트워크 내에 RUIC(11, 12, 13)가 하나만 존재할 경우 문제가 되지 않는다. 다만, 도 2에 도시한 바와 같이, 여러 개의 RUIC들(11, 12, 13)이 존재하는 경우, 공지 이벤트(notification event)를 수신한 어떠한 RUIC(11, 12, 13)라도 공지 페이지(notification page)를 요청할 수 있기 때문에 공지 이벤트(notification event) 수신을 원했던 RUIC(11, 12 또는 13)이 실제로 공지 페이지(notification page)를 수신할 수 없는 상황이 발생할 수 있다.
이러한 상황을 도 2에 도시하였으며, 도 2는 종래 기술의 문제점을 설명하기 위한 도면이다. 다음 고에서 기술될 본 발명의 실시 예와 구분을 위해 푸시 모드 모델(Push-mode model)로 칭하기로 한다.
둘째, RUIC(10)가 네트워크에 진입시 저장된 공지 이벤트(notification event)에 대해 특정 공지 이벤트(notification event)에 대한 요청을 할 수 없다. RUIS(20)에 공지 이벤트(notification event)가 저장되는 경우는 사용자가 장시간 부재중인 상황을 가정한다. 따라서 많은 수의 공지 이벤트(notification event)가 저장될 것이며 RUIC(10)가 네트워크에 진입 시 저장되어 있는 모든 공지 이벤트(notification event)가 한꺼번에홈 네트워크 내로 전송됨으로써 사용자가 원하는 공지 이벤트(notification event)를 확인하기힘들다는 문제가 있다.
셋째, 도 1의 S113 단계에서와 같이 종래 기술에서는 저장된 공지 페이지(notification의 page)를 RUIC(10)로부터 의 요청이 있을 시 삭제하도록 되어 있다.
이는 RUIS(20)가 공지 이벤트(notification event)를 삭제 하지 않을 경우 RUIC(10)에서 공지 이벤트(notification event)를 수신한 이후에도 RUIS(20)에서 동일한 공지 이벤트(notification event)를 반복적으로 전송 할 수 있기 때문에 이를 방지하기 위한 방법이다. 그러나 이러한 경우 앞서 첫째의 문제점에서 살펴본 바와 같이 다른 디바이스에서 이벤트를 수신하였을 시 실제 공지 페이지(notification page)는 RUIS(20)에서 삭제됨으로써 사용자가 실제로 원하는 공지 페이지(notification page)를 수신 할 수 없는 문제가 발생한다. 또한, 이미 확인한 공지 이벤트(notification event)라 하더라도경우에 따라서는 재확인이 필요한 경우가 있다. 이럴 경우에도 기존의 방식에서는 이를 제공해 줄 수 있는 방법이 없 다.
따라서 상술한 바와 같은 종래의 문제를 감안한 본 발명의 목적은 복수개의RUIC가 홈 네트워크 내에 존재하는 경우 각 RUIC가 요청하는 조건에 따라 공지 이벤트를 처리 하는 방법 및 장치를 제공함에 있다.
상술한 과제를 해결하기 위한 본 발명의 바람직한 실시 예에 따른 원격 유저 인터페이스 클라이언트 및 서버로 이루어진 홈 네트워크에서 이벤트 처리 방법은, 상기 서버가 공지 이벤트를 시퀀스 번호 별로 저장하는 과정과, 상기 클라이언트가 상기 홈 네트워크에 접속하면, 홈 네트워크 접속 전 수신하지 못한 공지 이벤트의 시퀀스 번호를 상기 서버에 요청하는 과정과, 상기 서버가 상기 수신하지 못한 공지 이벤트의 시퀀스 번호를 상기 클라이언트에 전송하는 과정과, 상기 클라이언트가 상기 서버에 상기 수신하지 못한 공지 이벤트의 시퀀스 번호가 지시하는 공지 이벤트를 요청하는 과정과, 상기 서버가 상기요청한 공지 이벤트를 상기 클라이언트에 전송하는 과정과, 상기 클라이언트가 상기 공지 이벤트에 포함된 주소를 이용하여 공지 페이지를 수신하는 과정을 포함한다.
상술한 과제를 해결하기 위한 본 발명의 바람직한 실시 예에 따른 홈 네트워크에서 이벤트 처리를 위한 장치는, 공지 이벤트를 시퀀스 번호 별로 저장하는 원격 유저 인터페이스 서버 및 상기 홈 네트워크에 접속하면 홈 네트워크 접속 전 수신하지 못한 공지 이벤트의 시퀀스 번호를 상기 서버로부터 획득하여, 획득한 시퀀 스 번호에 따른 공지 이벤트를 요청하여 수신하며, 수신한 공지 이벤트에 포함된 주소를 이용하여 공지 페이지를 수신하는 원격 유저 인터페이스 클라이언트를 포함한다.
이상에서 살펴본 것과 같이 홈 네트워크에서 저장되어 있는 3rd party notification event를 재전송하는 방법에 있어 기존의 방식보다 효율적인 방법을 제시하였다.
첫째, 본 발명에 의하면 복수개의 RUIC 장치가 홈 네트워크 내에 존재할 경우 각 RUIC의 조건에 따라, 서로 다르게 저장된 Notification event를 전달 받을 수 있게 된다. 이는 서로 다른 RUIC 장치 사이에서만 가능한 것은 아니며 동일한 RUIC에서도 request하는 조건을 달리하면 이에 따른 Notification event를 재전송 받을 수 있게 된다.
둘째, 기존의 event 재전송 방식은 Multicast 방식에 의해 타 RUIC 장치에서 event를 처리하였을 경우 해당 notification page가 삭제되어 다른 RUIC장치에서 event를 처리할 수 없는 문제가 있었다.
본 발명에 의하면 notification event의 재전송 과정에 http-get 방식을 도입함으로써 request를 요청한 RUIC에서 해당 event를 처리 할 수 있는 방법을 제공하였다. 또한 서버에서 저장되는 event를 일정 시간 보관해 둠으로써 저장된 event를 한번만 읽을 수 있었던 제약을 벗어나 필요할 경우 몇 번이고 재전송이 가능하게 되었다.
셋째, Notification event의 전송을 SEQ 번호에 따라 단계적으로 처리할 수 있게 함으로써 복수의 notification event가 RUIS에서 저장되어 있었을 경우, RUIC에서는 이를 순차적으로 처리할 수 있다.
본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 발명의 개시가 완전하도록 하고, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
먼저, 본 발명의 실시 예에 따른 이벤트 처리 방법을 개략적으로 설명하기로 한다. 도 3은 본 발명의 실시 예에 따른 이벤트 처리 방법을 설명하기 위한 도면이다.
도 3에 도 2의 방법에 대응하는 본 발명의 실시 예에 따른 이벤트 처리 방법을 도시하였다.
먼저, 본 발명의 실시 예에 따른 원격 유저 인터페이스 서버(Remote User Interface Server, 이하, "RUIS"로 축약함)(200)는 공지 이벤트를 홈 네트워크에 존재하는 원격 유저 인터페이스 클라이언트(Remote User Interface Client, 이하, "RUIC"로 축약함)(100)에 전송하는 역할을 수행한다. 본 발명의 실시 예에 따른 RUIS(200)은 공지 이벤트(notification event)를 시퀀스 번호(Sequence number, SEQ)별로 저장한다.
본 발명의 실시 예에서 RUIC(100)는 일정 기간 홈 네트워크에 존재하지 않았다가 다시 접속한 경우를 상정한다.
이러한 경우, RUIC(100)는 S301 단계에서 홈 네트워크에 존재하지 않는 동안 자신이 수신하지 못한 공지 이벤트를 RUIS(200)에 요청한다. 이러한 요청 과정은 2 단계를 통해 이루어질 수 있다. 먼저, RUIC(100)는 네트워크에서 자신이 존재하지 않은 동안에 수신하지 못한 공지 이벤트의 시퀀스 번호를 요청한다. 이러한 요청 시, RUIC(100)는 자신이 존재하지 않는 동안의 기간을 나타내는 파라미터 또는 네트워크로부터 접속을 종료한 종료 시점을 나타내는 파라미터를 포함하여 RUIS(200)에 요청할 수 있다. 그러면, RUIS(200)로부터 RUIC(100)는 요청한 시퀀스 번호를 수신한다. 그런 다음, RUIC(100)는 수신한 시퀀스 번호에 따른 공지 이벤트를 요청한다.
그러면, RUIS(200)는 S303 단계에서 요청 받은 자신이 수신한 시퀀스 번호에 따른 공지 이벤트를 RUIC(100)에 전송한다. 이어서, 공지 이벤트를 수신한 RUIC(100)는 S305 단계에서 공지 이벤트의 주소(URL)를 참조하여 공지 페이지를 수신한다.
상술한 바와 같이, 본 발명에서는 기존의 공지 이벤트(3rd party notification event)의 저장 및 재전송에 대한 방법을 개선하기 위해 제안되었다. 이러한 본 발명에서는 앞서 설명한 세 가지의 새로운 방법을 제안한다.
첫째, 본 발명의 실시 예에서는 RUIC(100)에서 RUIS(200)로 저장된 공지 이벤트(notification event)를 요청하는 방법을 제시한다. 기존의 홈 네트워크내에 RUIC(100)가 진입함을 공지(UPnP Discovery mechanism 사용)하는 방법과 달리 새롭게 제시하는 방법은 RUIC(100)에서 RUIS(200)로 저장된 공지 이벤트(notification event) 요청 시 http-get 방식을 사용하도록 제안한다. 이러한 http-get 방식은, 도 3에서 설명한 바와 같이. 특정 파라미터를 통해 자신이 수신하지 못한 공지 이벤트를 질의하거나, 요청할 수 있다.
즉, http-get 방식을 통해 RUIC(100)는 저장되어 있는 모든 공지 이벤트를 요청할 수 있을 뿐만 아니라 조건을 제시하여 필요한 공지 이벤트만을 선별적으로 요청할 수 있다.
둘째, RUIS(200)에서 저장된 공지 이벤트를 재전송하는 새로운 방법 제시한다. 기존 방식을 "Push-mode model"로 정의하였다면, 새롭게 제안하는 방식은 "Pull-mode model"로 구분할 수 있다.
이러한 본 발명의 실시 예에 따른 공지 이벤트 재전송 방법은, 도 3에서 설명한 것과 같이, RUIC(100)에서 http-get으로 공지 이벤트의 재전송을 요청하면 RUIS(200)에서는 특정한 RUIC(100)의 요청을 판단할 수 있고, RUIC(100)에서 요청한 조건에 맞는 공지 이벤트만을 선별하여 해당 RUIC(100)에게만 개별적으로 공지 이벤트를 전송할 수 있다.
셋째, 본 발명의 실시 예에 따른 공지 이벤트를 재전송하기 위해서는 RUIC(100)는 정확한 RUIS(200)의 위치를 알아야 한다. 이를 위해 디바이스 발견(device discovery) 과정에서 RUIS(200)에서 해당 정보(위치 정보)를 제공한다.
다음으로 상술한 바와 같은 이벤트 처리를 수행하기 위한 본 발명의 실시 예에 따른 홈 네트워크의 구성에 대해서 살펴보기로 한다. 도 4는 본 발명의 실시 예에 따른 홈 네트워크의 구성을 설명하기 위한 도면이다.
도 4를 참조하면, 홈 네트워크 내에서 디바이스는 원격 유저 인터페이스(Remote UI, 이하, "RUI"로 칭함) 및 공지 이벤트(3rd party notification event)를 보내는RUIS(200)와 공지 이벤트(notification event)를 수신하여처리하고 사용자에게 RUI를 제공하는RUIC(100)를 포함한다.
홈 네트워크 내에 존재하는 디바이스들을 발견(discovery)하고 RUIC(100)와 RUIS(200)간의 연결(connection)을 설정해주는 유저 인터페이스 제어 포인트(UI Control Point, 이하, "UICP"로 표기)(300)는 그림과 같이 RUIC(100)내에 존재할 수도 있고, RUIC(100)의 외부에 존재할 수 도 있다.
RUIS(200)는 RUI를 전송하는 웹 서버(Web Server)(210), 공지 이벤트(3rd party notification event)를 처리하기 위한 공지 처리부(3rd party Notification Handler)(220), 및 공지 이벤트(Notification event)가 저장되는저장부(230)를 포함한다.
저장된 공지 이벤트(Notification event)는 공지 처리부(3rd party Notification Handler)(220)를 통해 RUIC(100)로 재전송 되게 되며 이를 통해 RUIC(100)로부터 요청되는 공지 페이지(Notification page)의 요청은 웹 서버(Web Server)(210)가 처리하게 된다.
RUIS(200)는 장치 기술 파일(Device Description file)(240)을 저장하며, 저장된 장치 기술 파일(Device Description file)(240)에는 저장된 공지의 요청 주소(saved Notification의 URL 요청 주소)가 기술된다.
RUIC(100) 또는 UICP(300)는 저장된 공지의 요청 주소(saved Notification의 URL 요청 주소)를 통해 RUIS(200)에 저장된 공지 이벤트(Notification event)의 전송을 요청할 수 있다.
다음으로, RUIC(100)는 RUI를 처리하여 사용자에게 보여 주는 브라우저(XHTML Browser)(110), RUIS(200)에서 전송되는 공지 이벤트(3rd party notification event)를 처리하는 공지 처리(3rd party Notification Handler)(120)로 구성되어 있다.
공지 처리 모듈(3rd Party Notification Handler)(120)는 UICP(300)로부터 RUIS(200)의 저장된 공지의 요청 주소(saved Notification 요청 URL 주소)를 전달 받은 후 이를 통해 저장된 공지(notification)의 요청을 수행한다.
그러면, 상술한 본 발명의 실시 예에 따른 RUIS(200)가RUIC(100)에 공지 이벤트를 재전송하는 방법에 대해서 설명하기로 한다. 도 5는 본 발명의 실시 예에 따른 홈 네트워크에서 이벤트 처리 방법을 설명하기 위한 흐름도이다.
도 5에 제1 및 제2 RUIC(101, 102) 및 RUIS(200)가 도시되었다.
먼저, RUIC1(101)은 S501 단계에서 디바이스 발견(Device Discovery)을 통해 RUIS(200)를 발견하고, S503 단계에서 RUIS(200)의 저장된 공지의 요청 주소(saved Notification 요청 URL 주소)를 얻어 온다.
그런 다음, RUIC1(201)는 S505 단계에서 자신이 받지 못한 공지 이벤트(Notification event)가 있는지http-get request을 통해 RUIS(200)에게 확인을 요청한다.
다음의 <표 1>은 본 발명의 실시 예에 따른 http-get request를 설명하기 위한 것이다.
http://<savedNotifURL>?GetPreservedSEQ&time
http-get request는 앞선 단계(S503)에서 얻어 온 RUIS(200)의 저장된 공지의 요청 주소(saved Notification URL)를 이용하며, <표 1>에 개시된 바와 같이, 그 파라미터로 시간 정보를 포함하여 전송한다.
시간(time) 정보는 그 파라미터 값인 지정된 시간(time) 이후에 저장된 공지 이벤트(Notification event)가 있는지 질의하기 위한 것이다. 시간(time) 정보가 생략될 경우 RUIS(200)는 저장되어 있는 모든 공지 이벤트(notification event)의 정보를 전달하면 된다. 한편, 시간 정보는 RUIC1(101)이 홈 네트워크로부터 접속을 종료한 시점을 나타내는 파리미터가 될 수 있다.
S505 단계의 요청에 대한 응답으로 RUIS(200)는 S507 단계에서 저장되어 있는 공지 이벤트(Notification Event)의 시퀀스 번호(Sequence Number)를 RUIC1(101)에 전달한다. 앞서 설명한 바와 같이, RUIC1(101)가 요청한 조건(시간 정보)에 따라 전달되는 시퀀스 번호(Sequence Number)는 그 값이 달라 질 수 있다.
RUIC1(101)는 S509 단계에서 전달받은 시퀀스 번호(Sequence Number)에 따라 실제 저장된 공지 이벤트(Notification Event)의 재전송을 RUIS(200)에게 요청한다. 이때 저장되어 있는 공지 이벤트(Notification Event)가 여러 개라면 이 과정을 반복적으로 시행하면 된다.
다음의 <표 2>는 RUIC1(101)가 공지 이벤트를 요청하기 위해 사용되는 http-get request의 일 예를 나타낸 것이다.
http://<savedNotifURL>?GetPreservedNotification&SEQ_NO
<표 2>에 나타난 바와 같이, RUIC1(101)는 공지 이벤트를 요청하기 위해 http-get request에 그 파라미터로 원하는 시퀀스 번호(SEQ_NO)를 포함하여 전송한다.
상술한 바와 같은 요청을 수신한 RUIS(200)는 S511 단계에서 공지 이벤트를 요청하는 파라미터인 시퀀스 번호(SEQ_NO)에 해당되는공지 이벤트(Notification event)가 존재할 경우, HTTP/1.1 200 OK로 응답을 보냄과 동시에 HTTP/1.1 200 OK 메시지의 바디(body)에 공지 이벤트(Notification event)를 실어 보낸다.
한편, 공지 이벤트를 요청하는 파라미터인 시퀀스 번호(SEQ_NO)에 해당되는공지 이벤트(Notification event)가 존재하지않으면, RUIS는 S511 단계에서 404 Not Found로 응답한다.
RUIC1(101)은 S513 단계에서 공지 이벤트(Notification Event)를 받은 후 공지 이벤트(Notification event) 안에 기술되어 있는 URL 정보에 따라 해당되는 공지 페이지(Notification page)를 RUIS(200)에게 요청한다.
그러면, RUIS(200)는 S515 단계에서 해당 공지 페이지(Notification page)를 RUIC1(101)에 전달한다. 그러면, RUIC1(101)은 수신한 공지 페이지를 렌더링하여 브라우저(XHTML Browser)(110)를 통해 사용자에게 보여 준다.
S517 부터 S529 단계는 홈 네트워크 내에 존재하는 RUIC2(102)가 저장된 공지 이벤트(notification event)의 요청을 처리하는 과정을 나타낸다.
기본적으로, RUIC2(102)는 RUIC1(101)가 실행하는 S505 부터 S515 단계와 동일한 과정을 S517 부터 S527 단계를 통해 수행한다.
다만, RUIC1(102)는 S517 단계에서 RUIC1(101)과 비교하여 RUIC1(101)이 요청한 시간(time) 정보와 다른 정보를 RUIS(200)로 전송한다 따라서, S519 단계에서 RUIS(200)가 리턴하는시퀀스 번호(Sequence Number)의 응답은 달라질 수 있다.
상술한 바와 같은 수행 후, 기 설정된 시간이 경과 하면, RUIS(200)는 저장되어 있는 공지 이벤트에 대한 정보를 삭제할 수 있다. 이때 기 설정된 시간은 RUIS(200)의 구현에 따라 달라질 수 있으며, 사용자에 의해 그 시간이 설정된다.
다음으로, 홈 네트워크에 서로 다른 RUIC들(101, 102)이 존재할 경우, 실제로 저장된 공지 이벤트의 처리 방법에 대해서 설명하기로 한다. 도 6은 본 발명의 실시 예에 따른 홈 네트워크에서 서로 다른 RUIC가 존재하는 경우 이벤트 처리 방법을 설명하기 위한 흐름도이다.
도 6에서, RUIS(200)에 저장되어 있는 공지 이벤트(Notification event)의 시퀀스 번호(Sequence number)가 100 부터 105까지 라고 가정한다.
또한, RUIC1(101)은 공지 이벤트(notification event)를 SEQ 99까지 받았고, RUIC2(102)는 SEQ 103까지 받은 상태에서, 홈 네트워크로부터 벗어 난 상태라고 가정한다.
이때, RUIC1(101)가 홈 네트워크에 진입하면RUIC1(101)는 S601 단계에서 자신이 마지막으로 수신한 공지 이벤트의 시간(time) 정보를 바탕으로 RUIS(100)에게 시간 정보의 파라미터가 지시하는 그 시간 이후 저장되어 있는 공지 이벤트(notification event)가 존재하는지 여부를 질의한다.
RUIS(200)는 S603 단계에서 SEQ 100부터 전달해주면 될 것을 판단하고 그 응답으로 SEQ 100 부터 105의 범위를 RUIC1(101)에 리턴한다.
시퀀스 번호 100 부터 105를 수신한 RUIC1(101)은 S605 단계에서 SEQ 100부터 공지 이벤트(Notification event)의 재전송을 RUIS(200)에게 요청한다. 그러면, RUIS(200)는 S607 단계에서 해당하는 공지 이벤트(Notification event)( SEQ 100 부터 105)를 RUIC1(101)에게 전송한다. 이 과정은 SEQ 105까지 반복된다.
한편, RUIC2(102)는 S611 단계에서 RUIC1(101)과 마찬가지로, 시간 파라미터를 통해 자신이 수신하지 못한 공지 이벤트를 요청한다. RUIC2(102)가 수신한 공지 이벤트가 SEQ 103 받은 상태이므로, RUIS(200)은S613 단계에서 시퀀스 번호로 104 및 105를 RUIC2(102)에 리턴한다.
그러면, RUIC2(102)는 S615 단계에서 시퀀스 번호 104부터의 전송을 RUIS(200)에게 요청한다. 그러면, RUIS(200)는 S617 단계에서 해당하는 공지 이벤트(Notification event)( SEQ 104 부터 105)를 RUIC2(102)에게 전송한다.
이상에서 살펴본 것과 같이 홈 네트워크에서 저장되어 있는 공지 이벤트(3rd party notification event)를 처리 하는 방법에 있어 기존의 방식보다 효율적인 방법을 제시하였다.
첫째, 본 발명에 의하면 복수개의 RUIC가 홈 네트워크 내에 존재할 경우 각 RUIC의 조건에 따라, 서로 다르게 저장된 공지 이벤트(Notification event)를 전달 받을 수 있게 된다. 이는 서로 다른 RUIC 사이에서만 가능한 것은 아니며 RUIC에서 요청(request)하는 조건을 달리하면 이에 따른 공지 이벤트(Notification event)를 재전송 받을 수 있게 된다.
둘째, 기존의 공지 이벤트(notification event) 재전송 방식은 멀티캐스트(Multicast) 방식에 의해 타 RUIC 장치에서 해당 공지 이벤트(notification event)를 처리하였을 경우 해당 공지 페이지(notification page)가 삭제되어다른 RUIC에서 공지 이벤트(notification event)를 처리할 수 없는 문제가 있었다.
본 발명에 의하면 공지 이벤트(notification event)의 재전송 과정에 http-get 방식을 도입함으로써 해당 공지 이벤트를 요청한 RUIC에서 처리 할 수 있는 방법을 제공하였다. 또한 RUIS는 공지 이벤트(notification event)를 일정 시간 보관해 둠으로써 저장된 공지 이벤트(notification event)를 한번만 읽을 수 있었던 제약을 벗어나 필요할 경우 몇 번이고 재전송이 가능하게 되었다.
셋째, 공지 이벤트(Notification event)의 전송을 SEQ 번호(sequence number)에 따라 단계적으로 처리할 수 있게 함으로써 복수의 notification event가 RUIS에서 저장되어 있었을 경우, RUIC에서는 이를 순차적으로 처리할 수 있다.
이상과 같이 예시된 도면을 참조로 하여, 본 발명의 실시 예들을 설명하였지만, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시 예들은 모든 면에서 예시적인 것이며, 한정적이 아닌 것으로 이해해야만 한다.
도 1은 종래 기술에 따른 제3의 장치에서 공지 이벤트의 재전송 방법을 설명하기 위한 도면.
도 2는 종래 기술의 문제점을 설명하기 위한 도면.
도 3은 본 발명의 실시 예에 따른 이벤트 처리 방법을 설명하기 위한 도면.
도 4는 본 발명의 실시 예에 따른 홈 네트워크의 구성을 설명하기 위한 도면.
도 5는 본 발명의 실시 예에 따른 홈 네트워크의 이벤트 처리 방법을 설명하기 위한 흐름도.
도 6은 본 발명의 실시 예에 따른 홈 네트워크에서 서로 다른 RUIC가 존재하는 경우 이벤트 처리 방법을 설명하기 위한 흐름도.

Claims (20)

  1. 원격 유저 인터페이스 서버를 포함하는 네트워크에서 원격 유저 인터페이스 클라이언트의 공지 이벤트 처리 방법에 있어서,
    공지 이벤트 정보 요청을 상기 원격 유저 인터페이스 클라이언트로부터 상기 원격 유저 인터페이스 서버에게 전송하는 과정;
    상기 공지 이벤트 정보 요청에 대응하는 공지 이벤트 정보를 상기 원격 유저 인터페이스 서버로부터 수신하는 과정;
    상기 수신한 공지 이벤트 정보에 근거하여 공지 메시지 요청을 상기 원격 유저 인터페이스 서버에게 전송하는 과정;및
    상기 원격 유저 인터페이스 서버로부터 상기 공지 메시지 요청에 대응하는 적어도 하나의 공지 메시지를 수신하는 과정;을 포함하는 것을 특징으로 하는 원격 유저 인터페이스 클라이언트의 공지 이벤트 처리 방법.
  2. 제1항에 있어서,
    상기 적어도 하나의 공지 메시지에 포함된 URL(Uniform Resource Locator)을 이용하여 공지 페이지를 가져오는 과정;및
    공지 페이지를 렌더링하고 표시하는 과정;을 더 포함하며,
    상기 공지 메시지는,
    XML(eXtensible Markup Language)의 형태인 것을 특징으로 하는 원격 유저 인터페이스 클라이언트의 공지 이벤트 처리 방법.
  3. 제1항에 있어서,
    상기 원격 유저 인터페이스 클라이언트가 상기 원격 유저 인터페이스 서버에 접속하기 위해, 디바이스 발견 동작을 수행하는 과정;및
    저장된 공지 메시지를 위한 저장된 공지 URL (savedNotifURL: saved notification URL)을 상기 디바이스 발견 동작에 의해 발견된 원격 유저 인터페이스 서버로부터 수신하는 과정;을 더 포함하는 것을 특징으로 하는 원격 유저 인터페이스 클라이언트의 공지 이벤트 처리 방법.
  4. 제1항에 있어서,
    상기 공지 이벤트 정보는 시퀀스 번호와 시간 정보로 구성되며,
    상기 시간 정보는 상기 공지 메시지가 상기 원격 유저 클라이언트에 저장되기 시작할 때의 시간을 나타내며,
    상기 공지이벤트 정보의 요청은,
    http://<savedNotifURL>?GetPreservedSEQ&time의 형식으로 된 http-get 요청을 포함하는 것을 특징으로 하는 원격 유저 인터페이스 클라이언트의 공지 이벤트 처리 방법.
  5. 제4항에 있어서,
    상기 공지 메지시는 시퀀스 번호를 포함하며,
    상기 공지 이벤트 정보는,
    http://<savedNotifURL>?GetPreservedNotificaion&SEQ_NO의 형식으로 된 http-get 요청을 포함하는 것을 특징으로 하는 원격 유저 인터페이스 클라이언트의 공지 이벤트 처리 방법.
  6. 원격 유저 인터페이스 서버와 적어도 하나의 원격 유저 인터페이스 클라이언트로 구성되는 네트워크에서 상기 원격 유저 서버의 공지 이벤트 처리 방법에 있어서,
    상기 적어도 하나의 클라이언트 중 하나의 원격 유저 인터페이스 클라이언트로부터 공지 이벤트 정보 요청을 수신하는 과정;
    상기 요청에 따라 저장된 공지 메시지의 상기 공지 이벤트 정보를 상기 원격 유저 인터페이스 클라이언트에게 전송하는 과정;
    상기 저장된 공지 메시지 중 적어도 하나의 공지 메시지 요청을 상기 원격 유저 인터페이스 클라이언트로부터 수신하는 과정;및
    상기 원격 유저 인터페이스 클라이언트가 요구한 상기 적어도 하나의 공지 메시지에 대응하는 적어도 하나의 저장된 공지 메시지를 전송하는 과정;을 포함하는 것을 특징으로 하는 원격 유저 인터페이스 서버의 공지 이벤트 처리 방법.
  7. 제6항에 있어서,
    URL(Uniform Resource Locator) 형식을 사용하는 공지 페이지의 요청을 상기 원격 유저 인터페이스 클라이언트로부터 수신하는 과정;및
    상기 공지 페이지를 상기 원격 유저 인터페이스 클라이언트에게 전송하는 과정;을 더 포함하는 것을 특징으로 하는 원격 유저 인터페이스 서버의 공지 이벤트 처리 방법.
  8. 제6항에 있어서,
    상기 원격 유저 인터페이스 클라이언트가 상기 서버에 접속하면, 디바이스 발견 동작을 수행하는 과정;및
    상기 공지 메시지를 저장하고 있는 저장된 공지URL(savedNotifURL: saved Notification URL)을 상기 클라이언트에 전송하는 과정;을 더 포함하는 것을 특징으로 하는 원격 유저 인터페이스 서버의 공지이벤트 처리 방법.
  9. 제6항에 있어서,
    상기 공지 이벤트 정보의 요청은 시퀀스 번호와 시간 정보를 포함하는 http-get 요청을 포함하며,
    상기 시간 정보는 상기 공지 메시지가 상기 원격 유저 인터페이스 클라이언트에 저장되기 시작한 시간을 나타내며,
    상기 http-get 요청은 http://<savedNotifURL>?GetPreservedSEQ&time의 형식인 것을 특징으로 하는 원격 유저 인터페이스 서버의 공지 이벤트 처리 방법.
  10. 제9항에 있어서,
    상기 공지 이벤트 정보는,
    상기 시간 정보에서부터 현재 시간까지 저장된 공지 메시지의 시작 시퀀스번호와 마지막 시퀀스번호로 제한된 시퀀스번호의 범위를 포함하는 것을 특징으로 하는 원격 유저 인터페이스 서버의 공지 이벤트 처리 방법.
  11. 제10항에 있어서,
    상기 공지이벤트 정보는,
    시작 시퀀스번호와 마지막 시퀀스번호를 포함하는 것을 특징으로 하는 원격 유저 인터페이스 서버의 공지 이벤트 처리 방법.
  12. 제6항에 있어서,
    상기 원격 유저 인터페이스 서버는,
    적어도 하나의 공지 메시지 각각에 대한 개인적인 다수의 요청을 수신하며, 상기 다수의 요청은 각각 http://<savedNotifURL>?GetPreservedNotificaion&SEQ_NO 형식의 http-get 요청을 포함하는 것을 특징으로 하는 원격 유저 인터페이스 서버의 공지 이벤트 처리 방법.
  13. 제6항에 있어서,
    상기 원격 유저 인터페이스 서버는,
    미리 지정된 시간이 지나면 저장된 공지 메시지를 삭제하는 과정;을 더 포함하는 것을 특징으로 하는 원격 유저 인터페이스 서버의 공지 이벤트 처리 방법.
  14. 공지 메시지를 처리하는 시스템에 있어서,
    공지이벤트 정보를 요청하고 획득한 공지이벤트 정보를 참고하여 적어도 하나의 저장된 공지 메시지를 요청하는 원격 유저 인터페이스 클라이언트;및
    공지메시지를 저장하고, 상기 클라이언트가 요청한 상기 공지 이벤트 정보를 상기 원격 유저 인터페이스 클라이언트에게 전송하고, 상기 요청된 것을 적어도 하나의 저장된 공지 메시지에서 검색하고, 적어도 하나의 저장된 공지 메시지에서 검색한 것을 원격 유저 인터페이스 클라이언트에게 전송하는 원격 유저 인터페이스 서버;를 포함하는 것을 특징으로 하는 공지 메시지 처리 시스템
  15. 제14항에 있어서,
    상기 원격 유저 인터페이스 클라이언트는,
    수신한 공지 메시지에 포함된 URL(Uniform Resource Locator)을 이용한 공지페이지를 요청하고 공지 페이지를 렌더링하고 보여주는 브라우저(XHTML browser);를 포함하며,
    상기 원격 유저 인터페이스 서버는,
    상기 공지페이지에 억세스하여 상기 공지 페이지를 상기 원격 유저 인터페이스 클라이언트에게 전송하는 웹서버;를 포함하는 것을 특징으로 하는 공지 메시지 처리 시스템.
  16. 제15항에 있어서,
    상기 원격 유저 인터페이스 클라이언트가 상기 서버에 접속하면, 상기 원격 유저 인터페이스 클라이언트와 상기 원격 유저 인터페이스 서버 간에 디바이스 발견을 제어하는 인터페이스 제어포인트(UI Control Point, 이하 UICP);를 더 포함하며,
    상기 원격 유저 인터페이스 클라이언트는,
    상기 디바이스 발견 수행 완료 후, 상기 원격 유저 인터페이스 서버에서 전송된 공지 메시지에 포함된 저장된 공지 요청 주소 (saved Notification URL)을 수신하는 것을 특징으로 하는 공지 메시지 처리 시스템.
  17. 제 14항에 있어서,
    상기 적어도 하나의 저장된 이벤트 요청은,
    시퀀스 번호;
    시간정보;및
    http-get 요청;을 포함하며,
    상기 시간 정보는,
    상기 공지이벤트가 상기 클라이언트에 저장되기 시작한 시간을 나타내며,
    상기 http-get 요청은 http://<savedNotifURL>?GetPreservedSEQ&time 형식인 것을 특징으로 하는 공지 메시지 처리 시스템.
  18. 제17항에 있어서
    상기 원격 유저 인터페이스 서버가 상기 원격 유저 인터페이스 클라이언트로부터 공지 이벤트 정보 요청을 받은 경우,
    상기 시간 정보에서부터 현재 시간까지 저장된 공지 메시지의 시작 시퀀스번호와 마지막 시퀀스번호로 제한된 시퀀스 번호의 범위를 전송하는 것을 특징으로 하는 공지 메시지 처리 시스템.
  19. 제18항에 있어서,
    상기 원격 유저 인터페이스 클라이언트는, http;//<savedNotifURL>?GetPreservedNotificaion&SEQ_NO 형식의 http-get 요청을 전송함으로써 원격 유저 인터페이스 서버에 다수의 공지 메시지를 하나씩 반복적으로 요청하는 것을 특징으로 하는 공지 메시지 처리 시스템.
  20. 제19항에 있어서,
    상기 원격 유저 인터페이스 서버는,
    미리 지정된 시간이 지나면 저장된 공지 메시지를 삭제하는 과정;을 더 포함하는 것을 특징으로 하는 공지 메시지 처리 시스템.
KR20090046736A 2009-05-28 2009-05-28 원격 유저 인터페이스를 지원하는 홈 네트워크에서 이벤트 처리 방법 및 이를 위한 장치 KR101485806B1 (ko)

Priority Applications (6)

Application Number Priority Date Filing Date Title
KR20090046736A KR101485806B1 (ko) 2009-05-28 2009-05-28 원격 유저 인터페이스를 지원하는 홈 네트워크에서 이벤트 처리 방법 및 이를 위한 장치
PCT/KR2010/003311 WO2010137861A2 (en) 2009-05-28 2010-05-26 Event-processing method and system for a home network supporting a remote user interface
EP10780772.9A EP2436149A4 (en) 2009-05-28 2010-05-26 EVENT PROCESSING SYSTEM AND SYSTEM FOR A HOME NETWORK FOR SUPPORTING A REMOTE USER INTERFACE
CN201080033088.7A CN102484605B (zh) 2009-05-28 2010-05-26 用于支持远程用户界面的家庭网络的事件处理方法和系统
US12/788,824 US8583726B2 (en) 2009-05-28 2010-05-27 Event-processing method and system for a home network supporting a remote user interface
TW099117175A TWI501587B (zh) 2009-05-28 2010-05-28 事件處理方法及用於家用網路支援遠端使用者介面的系統

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR20090046736A KR101485806B1 (ko) 2009-05-28 2009-05-28 원격 유저 인터페이스를 지원하는 홈 네트워크에서 이벤트 처리 방법 및 이를 위한 장치

Publications (2)

Publication Number Publication Date
KR20100128370A KR20100128370A (ko) 2010-12-08
KR101485806B1 true KR101485806B1 (ko) 2015-01-23

Family

ID=43221481

Family Applications (1)

Application Number Title Priority Date Filing Date
KR20090046736A KR101485806B1 (ko) 2009-05-28 2009-05-28 원격 유저 인터페이스를 지원하는 홈 네트워크에서 이벤트 처리 방법 및 이를 위한 장치

Country Status (6)

Country Link
US (1) US8583726B2 (ko)
EP (1) EP2436149A4 (ko)
KR (1) KR101485806B1 (ko)
CN (1) CN102484605B (ko)
TW (1) TWI501587B (ko)
WO (1) WO2010137861A2 (ko)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101612553B1 (ko) * 2009-10-09 2016-04-27 삼성전자주식회사 리모트 사용자 인터페이스 서버와 리모트 사용자 인터페이스 클라이언트간의 인터페이스를 위한 장치 및 방법
US8990704B2 (en) * 2011-03-04 2015-03-24 Sony Corporation Remote user interface media adapter in network bridge
US8769110B2 (en) * 2011-05-27 2014-07-01 Sony Corporation Transferring RUI from one device to another
US9524198B2 (en) * 2012-07-27 2016-12-20 Google Inc. Messaging between web applications
US10303345B2 (en) 2015-08-28 2019-05-28 Google Llc Transferring notifications between devices
CN105933380A (zh) * 2016-04-01 2016-09-07 宇龙计算机通信科技(深圳)有限公司 一种数据传输的方法、装置及终端
CN106713506A (zh) * 2017-02-22 2017-05-24 郑州云海信息技术有限公司 一种数据获取方法及系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007188507A (ja) 2006-01-12 2007-07-26 Samsung Electronics Co Ltd 遠隔ユーザインターフェースの状態情報を保存して復旧する方法及び装置
JP2007193802A (ja) 2006-01-18 2007-08-02 Samsung Electronics Co Ltd 遠隔ユーザインターフェースの状態情報を保存して復旧する方法及び装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6216152B1 (en) 1997-10-27 2001-04-10 Sun Microsystems, Inc. Method and apparatus for providing plug in media decoders
US6654786B1 (en) 1998-04-30 2003-11-25 Openwave Systems Inc. Method and apparatus for informing wireless clients about updated information
US6292825B1 (en) * 1998-11-12 2001-09-18 International Business Machines Corporation Service application with pull notification
US6725281B1 (en) * 1999-06-11 2004-04-20 Microsoft Corporation Synchronization of controlled device state using state table and eventing in data-driven remote device control model
US20020042830A1 (en) * 2000-03-31 2002-04-11 Subhra Bose System, method and applications real-time messaging over HTTP-based protocols
KR100736090B1 (ko) * 2005-09-28 2007-07-06 삼성전자주식회사 홈 네트워크에서 제 3의 장치의 이벤트를 처리하는 방법 및장치
CN100514968C (zh) * 2005-10-11 2009-07-15 华为技术有限公司 离线消息的处理方法和即时消息服务器
CN100542172C (zh) * 2005-10-11 2009-09-16 华为技术有限公司 一种离线消息发送和接收方法
KR100803610B1 (ko) * 2006-11-21 2008-02-15 삼성전자주식회사 인터넷을 통해 ＵＰｎＰ 홈 네트워크에 접속된 디바이스를제어하는 방법 및 이를 위한 시스템 및 장치
KR101125847B1 (ko) * 2007-07-11 2012-03-28 삼성전자주식회사 ＵＰｎＰ 디바이스와 ＲＵＩ 클라이언트를 중계하는 방법및 이를 위한 장치
CN101106543A (zh) * 2007-08-20 2008-01-16 北京亿企通信息技术有限公司 一种在即时通信工具中处理离线数据的方法
KR101395058B1 (ko) 2008-01-17 2014-05-13 삼성전자주식회사 ＵＰｎＰ 원격 프로토콜을 지원하는 홈 네트워크에서 제3의장치의 이벤트를 처리하는 방법 및 장치

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007188507A (ja) 2006-01-12 2007-07-26 Samsung Electronics Co Ltd 遠隔ユーザインターフェースの状態情報を保存して復旧する方法及び装置
JP2007193802A (ja) 2006-01-18 2007-08-02 Samsung Electronics Co Ltd 遠隔ユーザインターフェースの状態情報を保存して復旧する方法及び装置

Also Published As

Publication number Publication date
US20100306312A1 (en) 2010-12-02
WO2010137861A3 (en) 2011-03-03
WO2010137861A2 (en) 2010-12-02
KR20100128370A (ko) 2010-12-08
EP2436149A2 (en) 2012-04-04
EP2436149A4 (en) 2013-10-09
US8583726B2 (en) 2013-11-12
CN102484605A (zh) 2012-05-30
TWI501587B (zh) 2015-09-21
CN102484605B (zh) 2016-04-20
TW201129017A (en) 2011-08-16

Similar Documents

Publication Publication Date Title
KR101485806B1 (ko) 원격 유저 인터페이스를 지원하는 홈 네트워크에서 이벤트 처리 방법 및 이를 위한 장치
US7779030B2 (en) Method and apparatus for managing content using remote user interface
JP4759641B2 (ja) ネットワーク上で遠隔で装置にアクセスする方法及びシステム
JP5574544B2 (ja) 単一化されたデバイス管理方法及びシステム
EP2840741B1 (en) Method and apparatus for using service of home network device based on remote access
EP2564550B1 (en) Method for providing message and device therefor
JP2007115253A (ja) ホームネットワークでデバイスを独占的に制御するための方法及び装置
JP5937005B2 (ja) 近距離ネットワークにおける遠隔制御のための装置及び方法とこれをサポートするシステム
KR101656882B1 (ko) 네트워크에서 원격 유저 인터페이스 목록을 제공하는 방법 및 장치
JP2010028812A (ja) 通信制御装置及び通信制御方法
JP3877738B2 (ja) 個別に独立して存在するネットワークを接続する装置及び方法
US9002927B2 (en) Apparatus and method for managing remote user interface and system for the same
US10567183B2 (en) System and method for conference messaging between telephony devices in a first network and devices connected to a second network
TWI599207B (zh) 推播訊息傳遞方法與訊息傳遞系統
KR20120008401A (ko) 홈 네트워크에서 멀티캐스트 메시지를 이용하여 복수 개의 원격 사용자 인터페이스 서버들을 제어하기 위한 장치 및 방법
TW201216645A (en) Access control method, access control apparatus, and access control program
JPWO2006043411A1 (ja) 通信装置および端末存在確認方法
CN103119892B (zh) 在通用型即插即用使能的电话装置和广域网装置之间进行会议消息传递的系统和方法
KR101708499B1 (ko) 홈 네트워크에서 디바이스 디스크립션 정보를 제공하기 위한 장치 및 방법
KR100972477B1 (ko) Ｈｔｔｐ에 기반한 실시간 양방향 서비스 제공 방법,양방향 연결 유지 방법 및 그를 위한 서버
KR20040039043A (ko) ＵＰｎＰ 네트워크 시스템의 제어 메시지 전송 방법
KR20040066953A (ko) 홈 네트웍 기기 상호간의 서비스 인식 처리 방법
WO2015118589A1 (ja) 情報処理装置、情報処理方法及びプログラム
KR20110039142A (ko) 범용 플러그 앤 플레이 네트워크에서의 원격 접속 방법
KR20040068761A (ko) ＵＰｎＰ 네트워크 시스템의 이벤트 메시지 전송 방법

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E90F Notification of reason for final refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20171228

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20181227

Year of fee payment: 5