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

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

Info

Publication number
KR20100128370A
KR20100128370A KR1020090046736A KR20090046736A KR20100128370A KR 20100128370 A KR20100128370 A KR 20100128370A KR 1020090046736 A KR1020090046736 A KR 1020090046736A KR 20090046736 A KR20090046736 A KR 20090046736A KR 20100128370 A KR20100128370 A KR 20100128370A
Authority
KR
South Korea
Prior art keywords
notification
notification event
event
ruic
home network
Prior art date
Application number
KR1020090046736A
Other languages
English (en)
Other versions
KR101485806B1 (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 EP10780772.9A priority patent/EP2436149A4/en
Priority to CN201080033088.7A priority patent/CN102484605B/zh
Priority to PCT/KR2010/003311 priority patent/WO2010137861A2/en
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

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Multimedia (AREA)
  • Automation & Control Theory (AREA)
  • Information Transfer Between Computers (AREA)
  • Small-Scale Networks (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)

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 (2)

  1. 원격 유저 인터페이스 클라이언트 및 서버로 이루어진 홈 네트워크에서 이벤트 처리 방법에 있어서,
    상기 서버가 공지 이벤트를 시퀀스 번호 별로 저장하는 과정과,
    상기 클라이언트가 상기 홈 네트워크에 접속하면, 홈 네트워크 접속 전 수신하지 못한 공지 이벤트의 시퀀스 번호를 상기 서버에 요청하는 과정과,
    상기 서버가 상기 수신하지 못한 공지 이벤트의 시퀀스 번호를 상기 클라이언트에 전송하는 과정과,
    상기 클라이언트가 상기 서버에 상기 수신하지 못한 공지 이벤트의 시퀀스 번호가 지시하는 공지 이벤트를 요청하는 과정과,
    상기 서버가 상기 요청한 공지 이벤트를 상기 클라이언트에 전송하는 과정과,
    상기 클라이언트가 상기 공지 이벤트에 포함된 주소를 이용하여 공지 페이지를 수신하는 과정을 포함하는 것을 특징으로 하는 홈 네트워크에서 이벤트 처리 방법.
  2. 홈 네트워크에서 이벤트 처리를 위한 장치에 있어서,
    공지 이벤트를 시퀀스 번호 별로 저장하는 원격 유저 인터페이스 서버 및
    상기 홈 네트워크에 접속하면 홈 네트워크 접속 전 수신하지 못한 공지 이벤 트의 시퀀스 번호를 상기 서버로부터 획득하여, 획득한 시퀀스 번호에 따른 공지 이벤트를 요청하여 수신하며, 수신한 공지 이벤트에 포함된 주소를 이용하여 공지 페이지를 수신하는 원격 유저 인터페이스 클라이언트를 포함하는 것을 특징으로 하는 홈 네트워크에서 이벤트 처리를 위한 장치.
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 원격 유저 인터페이스를 지원하는 홈 네트워크에서 이벤트 처리 방법 및 이를 위한 장치
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 用于支持远程用户界面的家庭网络的事件处理方法和系统
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
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 true KR20100128370A (ko) 2010-12-08
KR101485806B1 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 郑州云海信息技术有限公司 一种数据获取方法及系统

Family Cites Families (14)

* 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 华为技术有限公司 一种离线消息发送和接收方法
KR100788693B1 (ko) 2006-01-12 2007-12-26 삼성전자주식회사 원격 사용자 인터페이스의 상태 정보를 저장하고 복구하는방법 및 장치
KR100813969B1 (ko) * 2006-01-18 2008-03-14 삼성전자주식회사 원격 사용자 인터페이스의 상태 정보를 저장하고 복구하는방법 및 장치
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의장치의 이벤트를 처리하는 방법 및 장치

Also Published As

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

Similar Documents

Publication Publication Date Title
KR20100128370A (ko) 원격 유저 인터페이스를 지원하는 홈 네트워크에서 이벤트 처리 방법 및 이를 위한 장치
KR100782854B1 (ko) 원격 사용자 인터페이스를 이용한 콘텐트 관리 방법 및장치
US20140006562A1 (en) Information processing apparatus, information processing method, computer program, and information communication system
TW200405691A (en) System for efficient recovery of node-b buffered data following MAC layer reset
CN101507183B (zh) 去耦连接
US20090316573A1 (en) System and method for transmitting messages using a redundancy mechanism
EP2564550B1 (en) Method for providing message and device therefor
JP2010028812A (ja) 通信制御装置及び通信制御方法
KR101656882B1 (ko) 네트워크에서 원격 유저 인터페이스 목록을 제공하는 방법 및 장치
EP2645688A1 (en) Conference system
JP2013502146A (ja) 近距離ネットワークにおける遠隔制御のための装置及び方法とこれをサポートするシステム
US9161287B2 (en) Technique for efficient message delivery in Ad Hoc, mesh, wireless computer networks
TWI599207B (zh) 推播訊息傳遞方法與訊息傳遞系統
JP2010508686A (ja) 通信システムにおける配信レポート
WO2013118621A1 (ja) センサネットワーク、センサ管理サーバ、鍵更新方法および鍵更新プログラム
JP2010287958A (ja) 無線通信システム
JP2013196699A (ja) 送信側装置、受信側装置、及びメッセージ送受信システム
JP2018516478A5 (ko)
CN105119805A (zh) 一种即时通信数据传输方法及即时通信数据传输系统
TWI479863B (zh) 通訊終端以及通訊方法
JP2011135305A (ja) データ修復方法、データ修復システム、マッチングサーバ及び装置グループ化プログラム
KR100585677B1 (ko) ＬｎＣＰ 라이브러리에서의 메시지 처리 방법
JP2008072466A (ja) 通信システムおよび端末
JP3306022B2 (ja) １対多通信装置及び方法
WO2015118589A1 (ja) 情報処理装置、情報処理方法及びプログラム

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