KR20020035644A - 유아이-기반 홈 네트워크 브릿지 - Google Patents

Abstract

홈 네트워크는 UPnP 클러스터와 HAVi 클러스터를 포함한다. UPnP는 이 장치들 사이에 보내지는 표준화된 메시지들에 기초하는 프로그램적인 장치 인터페이스들을 사용한다. 또한 HAVi는 프로그램적인 인터페이스를 사용하지만 미리 FCM들과 적절한 장치 형식을 알아야 한다. 또한, 현재 UPnP 및 HAVi 표준들은 의미론적 차이들 때문에 서로 쉽게 맵핑될 수 있는 장치들을 정의하지 않는다. 이 문제를 극복하기 위해 클러스터들은 HAVi 클러스터 상에 UPnP 장치를 나타내어 브릿지되며, 여기서 UPnP 장치의 설명 문서는 HAVi UI를 통해 UPnP 장치들의 UI-기반 제어를 가능하게 하는 HAVi DDI 타켓을 발생하는데 사용된다.

Description

유아이-기반 홈 네트워크 브릿지{UI-based home network bridging}

배경기술

가정에 있는 각 장치들에 대해 단일 보편적으로 적용가능한 네트워킹 표준은 존재하지 않을 것으로 보인다. 소프트웨어 아키텍처들에 대한 다중 표준들이 공존하고 있으며 새로운 표준들이 생겨날 것이다. 새로운 표준 인터페이스들은 이들 표준들에 의해 특정적으로 타켓이 되는 장치들의 새로운 형식에 대해 개발될 것이다. 가정용 응용들은 가정에서 활용 가능한 모든 장치들의 현명한 사용을 목적으로 설계되지만, 사용되거나 앞으로 활용 가능하게 될 각각의 및 모든 네트워크 표준을 다룰 수 없다. 비슷하게, 이들 장치 자신들은 모든 현존 홈 네트워킹 표준(home network standard)을 서포트할 수도 없을 것이다. 이러한 이유들로 인해, 브릿지들이 각각의 개별적인 하나가 특정 개개의 표준을 따르는 다른 서브네트워크들 또는 클러스터들 사이에 필요하다. 브릿지는 제 2 형식의 네트워크 클러스터의 제 2 표준을 따르는 장치로서, 제 1 형식의 네트워크 클러스터의 제 1 표준을 따르는 장치를 명확히 나타내도록 역할을 한다. 이 결과는 제 1 표준뿐만 아니라 제 2 표준에 대해 작성된 소프트웨어 응용들에 활용 가능한 홈 네트워크의 단일 통일된 뷰(view)이다.

홈 네트워킹 표준들은 프로토콜 스텍의 낮은 레벨들(예를 들어 홈PNA, 홈RF와 같은 전송 레벨까지) 또는 높은 레벨들(전송 레벨부터 응용 레벨까지)을 일반적으로 다룬다. 이 설명의 나머지 설명에서 일반적으로 홈 네트워킹 표준들의 제 2 형식에 참조가 이루어진다. 이들 표준들의 예들은 HAVi, UPnP 및 Jini 이다.

전형적으로, 홈 네트워킹 표준은 장치들(또는 서버들)을 제어하기 위해 응용들(또는 클라이언트들)을 위한 프로그램적인 제어와 UI(사용자 인터페이스) 기반 제어인 두 방법들 중 하나를 제공한다.

프로그램적인 제어는 표준화된 메시지들을 장치에 보내는 것에 기초하는 제어 또는 장치에 보내진 메시지들이 되는 표준화된 API를 호출하는 것에 기초하는 제어를 말한다. 이런 종류의 제어는 요구되는 어떠한 직접 사용자 상호동작도 없이 장치들을 제어하는 응용들에 유용하다. 이 경우에, 제어기 및 제어 가능한 장치 둘은 교환될 수 있는 메시지들의 미리 정해진 세트를 사용한다. 즉, 제어기는 제어 가능한 장치의 형식을 미리 알아야 한다.

UI 기반 제어는 제어하는 장치에서 제어 가능한 장치로 사용자 상호동작들을 전달하는 것을 사용하는 제어를 말한다. 여기서, 사용자는 UI 클라이언트 또는 브라우저와 상호 동작하고, 사용자 동작들은 제어 가능한 장치 상의 UI 서버로 보내지는 메시지들로 인도한다. 메시지들은 예를 들어 HTML(UPnP에 사용됨) 및 DDI(HAVi에 사용됨)와 같은 예들의 특별한 UI 프로토콜을 사용하여 교환된다. 약어 "DDI"는 데이터 구동 상호 동작(Data Driven Interaction)을 나타내며, 사용자 인터페이스가 디스플레이될 필요가 있는 한쪽 측 상의 응용들 또는 DCMs 와 다른 측의 디스플레이 장치 사이에서 수행되는 프로토콜을 말한다. DDI 타켓은 장치의 DCM의 부분이다. 약어 "DCM"은 장치 제어 모듈(Device control module)을 나타낸다. DCM은 HAVi 네트워크 상의 단일 장치 또는 기능성을 나타내는 소프트웨어 요소이다. DCM은 이 장치에 대해 API들이 정의되는 HAVi를 드러낸다. DCM들은 본질적으로 동적이다 : 즉, 네트워크로부터 장치가 삽입 또는 제거되면 이 장치를 위한 DCM은 네트워크에 각각 설치 또는 제거될 필요가 있다. DCM들은 HAVi 개념과 새로운 장치들과 특성들을 HAVi 네트워크에 수용하는 데에 유동성을 갖는 소스의 중심이다. DDI는 응용과의 사용자 상호 동작을 서포트한다.

UI프로토콜은 그것에 의해 전달되는 정보 또는 제어 종류를 정의하지 않는 것이 기본이며, 이것은 단지 어떻게 사용자 동작들을 켑슐화(encapsulate)하고 이들을 클라이언트로부터 서버로 보낼 것인지를 정의한다. 부가적으로, 이것은 어떻게 사용자 인터페이스 요소들(또는 소형장치라 불림 ; widget)이 설명되고 디스플레이 목적들을 위해 서버로부터 클라이언트로 되돌려 보내는지를 정의한다. 이것은 제어기 응용이 제거 가능한 장치의 형식을 모를 때도 UI 기반 제어가 가능함을 암시한다.

제어기와 제어 가능한 장치가 UI 프로토콜을 사용하여 통신하고 사용자가 존재하는 한, 제어 가능한 장치는 제어될 수 있다. 부가적으로 UI 프로토콜은, 장치가 표준화된 장치 형식 능력들을 초과하는 현재 특성들을 나타내도록 한다. 다시 말해, 이것은 표준화된 장치가 자신을 경쟁물로부터 구별하도록 한다.

발명의 분야

본 발명은 홈 네트워크들에 관한 것이며, 특히, 다른 소프트웨어 아키텍처(architecture)들과의 클러스터(cluster)들을 갖는 네트워크들을 브릿지(bridging)하는 것에 관한 것이다.

본 발명은 첨부된 도면을 참조하여 예시적인 방식으로 더욱 상세히 설명된다.

도 1은 브릿지를 위한 옵션들을 도시하는 블록 다이어그램이다.

도 2a 및 2b는 아래의 설명 전체를 참조하는 UPnP 및 HAVi 정보 아이템들을 갖는 테이블이다.

도 3은 홈 네트워크의 부분을 갖는 다이어그램이다.

도 4 내지 도 6은 홈 네트워크 내의 UPnP 및 HAVi 클러스터들 사이의 상호 동작들을 도시하는 다이어그램들이다.

전체 도면들에서 동일한 참조 번호들은 유사한 또는 대응하는 특성들을 나타낸다.

발명의 요약

홈 네트워킹 표준들 사이의 제어를 브릿지 할 때, 근본적인 접근은, 표준 A의 제 1 소프트웨어 아키텍처의 장치 형식의 프로그램적인 인터페이스와 표준 A와 다른 표준 B의 제 2 소프트웨어 아키텍처의 장치 타입의 프로그램적인 인터페이스 사이에서 변환을 하는 것이며, 역으로도 마찬가지이다. 유사하게, 자연적인 접근은 표준 A의 장치 형식의 UI 인터페이스를 표준 B의 장치 형식의 UI 인터페이스로 변환하는 것이며, 역으로도 성립한다. 본원의 발명자는 특정 문제들이 이 접근과 관련된 것을 인식했으며, 해답을 제공하기 위해 브릿지를 더욱 상세히 분석하였다.

도 1은 이들 옵션들 보다 많이 있다는 것을 명시하는 다이어그램이다. 도 1의 다이어그램은 홈 네트워크(100)의 부분을 보여주며, 이는 표준 A에 따르는 소프트웨어 아키텍처와 클러스터(102) 및 표준 B의 소프트웨어 아키텍처와 클러스터(104)를 포함한다. 네트워크(100)는 클러스터(102) 내에 네트워크(100) 상에 상주하는 특정 형식 X의 장치(106)를 갖는다. 클러스터들(102 및 104)은 브릿지되어 장치(106)가 소프트웨어 표현(108)을 통해 클러스터(104)로부터 제어될 수 있다. 원칙적으로 클러스터(104)내의 장치(106)와 그 표현(108)은 UI 기반 제어 인터페이스들(110 및 112) 각각과 프로그램적인 제어 인터페이스들(114 및 116)을 각각을 가질 수 있다고 가정하라. 이 다이어그램은 4개의 브릿지 옵션들(118,120,122, 및 124)을 나열한다.

브릿지(118)는 UI 인터페이스(110)로부터 프로그램적인 인터페이스(116)로의 변환을 제공한다. 앞서 설명한 바와 같이, UI 인터페이스는 프로그램적인 인터페이스보다 훨씬 더 유동적이므로(또는 덜 표준적임), UI표준에서 프로그램적인 인터페이스로 변환은 매우 어려우며, 현존하는 HAVi 및 UPnP와 같은 홈 네트워킹 표준들에 대해서도 불가능하다. 이것은 다른 3개의 옵션들을 남긴다:

- 표준 A의 UI인터페이스(110)를 표준 B의 UI인터페이스(112)로 변환하기 위한 브릿지(120). 이것의 실현 여부는 표준들 A 및 B의 유사함에 달려있다. UPnP 장치 UI를 HAVi장치 UI로 변환은 UPnP가 HTML이 장치 UI의 어떤 종류의 스크립트들도 더하도록 허용하기 때문에 매우 어렵다. HAVi가 장치 UI에 대한 DDI 프로토콜을 사용하고, 아마, HTML이 DDI로 변환 가능한 반면, HTML 더하기 스크립트는 실현가능하지 않을 것이다.

- 표준 A의 프로그램적인 인터페이스(114)를 표준 B의 프로그램적인 인터페이스(116)로 변환하기 위한 브릿지(122). 이것의 가능 여부는 표준들 A 및 B에 의해 커버되는 도메인들에 크게 의존한다. 예를 들어, 만약 UPnP가 전구(light bulb)의 프로그램적인 인터페이스를 정의하고 HAVi는 전구의 '의미론적인 균등' 프로그램적인 인터페이스를 정의하지 않는다면, 이 장치 타입은 프로그램적인 방식으로 브릿지될 수 없다.

- 표준 A의 프로그램적인 인터페이스(114)를 표준 B의 UI 인터페이스(112)로변환하기 위한 브릿지(124). 이 변환 형식은 표준 A의 장치들의 프로그램적인 인터페이스를 변환 목적들을 위한 데이터로서 실시간에서 활용 가능해야 함을 요구한다. 이것은 '화이트 박스(white-box)' 장치 설명 메커니즘을 요구하며, 여기서 응용이 실시간에 장치의 인터페이스에 관한 모든 정보를 검색할 수 있다. 다시 말해, 응용은 장치 형식의 인터페이스에 관한 완성된 지식에 의존할 필요가 없으며, 이 지식을 실시간으로 검색할 수 있다. 또한 이 변환 형식은 프로그램적인 인터페이스에 사용되는 데이터 형식들이 '형식상 호환 가능한' GUI 요소들로서 맵핑(map)될 것을 더 요구한다. 이런 문맥 내에서, 발명의 명칭이 "CONTROL PROPERTY IS MAPPED ONTO MODALLY COMPATIBLE GUI ELEMENT"인 쉬테닌 지니(Eugene Shteyn)의 1998년 10월 2일에 출원된 공동 계류중인 미국 제 09/165,682(대리인 명부 PHA 23,484)호를 보라. 표준 A의 프로그램적인 인터페이스를 표준 B의 UI로 변환하는 것은, 형식상 호환가능한 GUI 요소들의 세트가 표준 B의 UI 메커니즘에 의해 서포트될 것을 요구한다. 또한 이것은 프로그램적인 인터페이스의 추상화 레벨(abstraction level)이 사용자 레벨 상호 동작에 적합할 것을 더 요구한다.

모든 위의 변환들은 브릿지 구현에 같이 존재할 수 있다. 사실 브릿지는 가능한한 많은 방법들로 다른 네트워크 내의 장치를 나타내어야하며, 이것은 어떤 인터페이스가 브릿지의 다른 측 상의 응용들/사용자들에 가장 적합할지를 모르기 때문이다.

본 발명은 표준 A의 프로그램적인 인터페이스를 표준 B의 UI로 변환하는 것이 브릿지로서 사용될 수 있다는 관찰에 기초한다. 아래는, 이 브릿지를 동작하도록 하기 위해 포함되는 두 표준들에 대해 요구사항들이 논의된다. 아래에 실시예들은 UPnP 프로그램적인 인터페이스를 HAVi 장치 UI(DDI 타켓)으로 변환하는 스킴의 형식에서 브릿지 옵션에 대해 주어진다.

본 발명은 홈 네트워크 내의 제 1 기능성들의 제 1 클러스터와 제 2 기능성들의 제 2 클러스터를 브릿지 가능하게 하는 방법에 관한 것이다. 제 1 클러스터는 제 1 소프트웨어 아키텍처를 가지며 이는 프로그램적인 인터페이스를 통해 제 1 기능성들의 제어를 제공한다. UPnP은 그러한 아키텍처의 예이다. 제 2 클러스터는 제 2 소프트웨어 아키텍처를 가지며 이는 UI 기반 인터페이스를 통해 제 2 기능성들의 제어를 제공한다. HAVi는 후자의 아키텍처의 예이다. 본 발명의 방법은 프로그램적인 인터페이스를 UI 기반 인터페이스로 변환을 제공하는 단계를 포함한다. UPnP-HAVi예에서, 이 방법은 UPnP 장치 설명 문서로부터 HAVi DDI 타켓 소프트웨어 요소를 발생하는 단계를 포함한다.

본 발명의 방법은 서비스 제공자에 의해 구현될 수 있다. 사용자는 서비스 제공자에게 그의/그녀의 네트워크에 부가된 새로운 장치들을 통지하고, 여기서 제공자는 브릿지의 부분으로서 사용자의 네트워크 상에 설치될 변환 모듈을 발생할 수 있다.

또한, 본 발명은 다른 소프트웨어 아키텍처들을 사용하는 이들 클러스터들을 갖는 홈 네트워크에 관한 것이다. 제 1 클러스터는 제 1 소프트웨어 아키텍처를 가지며 이는 프로그램적인 인터페이스를 통해 제 1 기능성들의 제어를 제공하고, 제 2 클러스터는 제 2 소프트웨어 아키텍처를 가지며 이는 UI 기반 인터페이스를 통해제 2 기능성들의 제어를 제공한다. 이 네트워크는 프로그램적인 인터페이스를 UI 기반 인터페이스로 변환하기 위해 제 1 및 제 2 클러스터들 사이에 브릿지를 갖는다. 이 네트워크는 UPnP 장치 설명 문서로부터 HAVi DDI 타켓을 발생하기 위한 발생기를 양호하게 포함한다.

본 발명의 관점은 홈 네트워크 상에서 사용하기 위한 브릿지 소프트웨어에 있으며, 여기서, 이 네트워크는 제 1 기능성들의 제 1 클러스터와 제 2 기능성들의 제 2 클러스터를 포함한다. 제 1 클러스터는 제 1 소프트웨어 아키텍처를 가지며 이는 프로그램적인 인터페이스를 통해 제 1 기능성들의 제어를 제공하고, 제 2 클러스터는 제 2 소프트웨어 아키텍처를 가지며 이는 UI 기반 인터페이스를 통해 제 2 기능성들의 제어를 제공한다. 이 브릿지 소프트웨어는 프로그램적인 인터페이스를 UI 기반 인터페이스로 변환하는 것에 기초하는 제 1 및 제 2 클러스터들을 결합하도록 동작한다. 이 소프트웨어는 UPnP - HAVi 네트워크 내의 UPnP 장치 설명 문서로부터 HAVi DDI 타켓을 발생하기 위한 발생기를 포함한다.

UPnP 표준은 "설명 문서"라고 불리는 XML 문서를 통하여 장치의 프로그램적인 인터페이스를 정의한다. 어떤 응용은 실시간으로 HTTP를 통하여 이 문서를 검색할 수 있어서, UPnP는 '화이트-박스'기준을 만족한다.

HAVi는 IDL 내에 표현된 API의 발행을 통하여 장치의 프로그램적인 인터페이스를 정의한다. API 정의는 FCM 형식으로 불리는 독특한 식별자에 묶인다. 약어 "FCM"는 기능적인 구성요소 모듈(Functional Component Module)을 말한다. DCM(위를 보라)은 나타난 장치 내의 각각의 제어 가능한 기능을 위한 FCM을 포함한다. 현재, HAVi는 튜너, VCR, HDD-기반 저장기, AV 디스플레이, 카메라들 및 모뎀들과 같은 기능들을 위한 FCM 및 대응 API를 정의한다. 실시간에 HAVi 응용은 제어되는 장치로부터 이 FCM 형식을 검색할 수 있고, FCM 형식에 링크된 인터페이스에 관한 그것의 완성된 지식에 프로그램적으로 기초되는 장치를 제어할 수 있다. HAVi 응용이 미리 FCM 형식에 링크된 인터페이스를 알 필요가 있어서 HAVi는 '화이트-박스'기준을 만족하지 못한다.

지니(Jini)에서, 응용은 원격(RMI) 참조를 장치의 자바 객체 표현(java object representation)으로 돌려주는 락업 서비스(lookup service)를 사용하여 장치의 프로그램적인 인터페이스를 검색한다. 자바 RMI(원격 방법 주문 ; Remote Method Invocation)는 제어 명령들을 제어되는 장치에 발행하도록 사용된다. 자바가 '반사 ; reflection'에 편리함들을 갖기 때문에, 실시간에 원격 객체(장치) 참조의 인터페이스(자바 멤버 변수들 및 방법들의 견지에서)를 결정할 수 있다. 그러므로, 자바는 '화이트-박스'기준을 만족한다.

UPnP 장치의 프로그램적인 인터페이스는 다음의 어떠한 형식들도 사용할 수 있다: 논리연산, 정수(i4로 불림), 부동 소수점(r8로 불림), 스트링, 데이트 타임(데이터 및 시간 정보) 또는 HEX-인코딩 2진 데이터(bin.hex 또는 bin.bin64로 불림). 이들 형식들은 DDI(HAVi에서 사용됨) 및 HTML(UPnP에서 사용됨)을 포함하는 대부분의 UI 프로토콜들에서 발견되는 공통 GUI 요소들로 직접적인 방식으로 맵핑될 수 있다. 도 2a 및 2b를 보라. 지니는 특정 장치 UI 프로토콜을 정의하지 않는다.

지니 장치의 프로그램적인 인터페이스는 어떤 자바 객체를 사용 할 수 있다. HAVi 장치의 프로그램적인 인터페이스는 어떤 IDL 형식을 사용할 수 있다. 그래서, HAVi 및 지니 장치 인터페이스들 둘 다는 일반적으로 UI에 쉽게 맵핑될 수 없다. 물론, 사람들은 IDL 또는 자바의 풍부한 데이터 형식 특성들의 서브세트를 사용하는 특정 장치에 대해 UI 맵핑이 가능하다고 생각할 수 있다. 예를 들어, 기본 자바 형식들(자바 객체들 아님) 만을 사용하는 지니 인터페이스에 대해서 UI 맵핑이 실현 가능하다.

요약하면, UPnP 장치의 프로그램적인 인터페이스를 HAVi의 DDI UI로 일반적인 변환을 정의하는 것이 가장 가치있는 것으로 보인다.

UPnP 프로그램적인 인터페이스를 HAVi DDI UI로 변환

UPnP 장치의 프로그램적인 인터페이스는 설명 문서에 설명된다. 이 문서는 0 또는 더 많은 (서브) 장치들을 갖는 루트(root) 장치를 명세한다. 각 장치는 서브 장치들 등의 다른 리스트들을 가질 수 있다. 어떤 서브 장치들 없는 장치(트리의 '잎')는 단일 서비스를 포함한다. 서비스는 상태 변수들과 액션들의 리스트를 포함한다. 서비스들은 서브 서비스들을 갖지 않는다. 상태 변수들은 '이름'필드, '형식'필드, 및 형식의 범위를 제한하기 위한 선택적 필드들을 갖는다. 액션들은 '이름'필드와 파라메터들의 리스트를 갖는다. 각 파라메터는 '이름'필드와 '관련 상태 변수'로 불리는 필드에 의해 설명된다. 이 필드는 상태 변수 이름을 참조해야 하고, 이것은 액션 파라메터의 형식을 간접적으로 정의한다.

본 발명의 양상은 UPnP 장치 설명 문서로부터 HAVi DDI 타켓을 발생하는 것이다. 변환은 DDI 타켓의 상태 측면들 뿐만 아니라 동적 측면들 둘 다를 관계한다.

상태 측면들에 관하여 : DDI 요소들 또는 소형 장치는 UPnP 데이터 형식에 대해 정의되는 것이 필요하다; UPnP 서비스에 대응하는 모든 DDI 요소들의 구조는 정의될 필요가 있다.; UPnP 장치에 대응하는 모든 DDI 요소들의 구조는 정의될 필요가 있다.

동적 측면들에 관하여 : 장치들 및 서비스들 사이의 DDI 항법은 정의될 필요가 있다; 응용과 장치 사이의 '세션 ; session'의 시작 및 종료는 정의될 필요가 있다; 제어되는 UPnP 장치에서 비동기 변경들의 효과는 정의될 필요가 있다; 발생된 DDI 타켓으로 향하는 사용자 액션들의 효과는 정의될 필요가 있다.

이들 측면들은 아래에서 더욱 상세히 설명된다.

정적: UPnP 데이터 형식들을 HAVi DDI 요소들로 변환

UPnP 데이터 형식들은, 서비스 설명에서 두 방식들로 즉, 직접적 - 상태 변수의 형식과 같은 그리고, 간접적 - 액션 파라메터에 대한 <관련 상태 변수>의 참조를 통하여,로 발생한다.

일부 DDI 요소들은 '상호 동작적'이다 : 이들은 사용자가 이들과 상호 동작하도록 허락한다. 예를 들어, 버튼이 상호 동작적인 동안, 텍스트 라벨은 상호 동작적이지 않다. 이 문맥에 의존하여, 일부 상호동작적인 DDI 요소들은 '일시적으로' 비-상호 동작적 또는 불가능하게 될 수 있다. 이것을 표현하기 위해, 상호 동작적인 DDI 요소들은 '상호 동작성'필드를 갖는다. UPnP이 액션들 만을 통하여 상태 변경들을 허용하기 때문에, 액션 파라메터들을 나타내는 DDI 요소들은 이 필드를 ENABLED로 설정할 것이다. 장치의 상태 변수의 현재 값을 나타내는 DDI 요소들은, 그러나 이 필드를 DISABLED로 설정할 것이다.

일부 UPnP 데이터 타입들은 그것이 보유할 수 있는 값의 범위에 특정 제한을 나타내는 부가적 명세서들을 가질 수 있다. 이것은 어떤 경우들에서 더욱 적절한 DDI 요소들을 발생하는데 사용될 수 있다.

정적 : UPnP 서비스를 DDI 구조로 변환

서비스는 상태 변수들의 리스트와 액션들의 리스트로 구성된다. 상태 변수들은 형식의 범위를 제한하기 위한 선택적인 필드들, '형식'필드, 및 '이름'필드를갖는다. 액션들은 '이름'필드와 파라메터들의 리스트를 갖는다. 각 파라메터는 '이름'필드와 '관련 상태 변수'라 불리는 필드에 의해 설명된다. 이 필드는 상태 변수 이름을 참조해야 하고, 이것은 액션 파라메터의 형식을 간접적으로 정의한다.

DDI에서, 요소들은 DDI 디스플레이 엔진(Ddi 제어기로 불림)에 결합하는 일부 정렬을 제안하기 위해 그룹 내에 구성될 수 있다. 이 결합은 스크린 상에 요소들의 구성을 결정하거나 항법을 결정하기 위해 사용될 수 있다. UPnP 서비스는 다음의 DDI 구조로 변환될 수 있다:

- 서비스의 <서비스 형식>필드에 설정된 패널이름을 갖는 Ddi패널. Ddi패널은 두 Ddi그룹 요소들과 Ddi패널링크 요소를 포함한다:

- "상태 변수들"에 설정된 그룹이름을 갖는 Ddi그룹 요소. 이 그룹의 '요소들'은 앞서 설명한 맵핑 형식에 따라 모든 UPnP 상태 변수들을 변환하여 얻어지는 DDI 요소들을 포함해야 한다. 모든 이들 Ddi 요소들은 DISABLED로 설정된 그들의 상호 동작적인 속성을 가져야 한다.

- "액션들"로 설정된 그룹이름을 갖는 Ddi그룹 요소. 이 그룹의 "요소들"의 필드는 각 개개의 UPnP 액션을 위한 Ddi그룹 요소들을 포함한다. 각 이들 Ddi그룹 요소들은 다음을 포함한다:

- 액션의 <이름>필드에 설정된 '눌러진 라벨' 및 '풀려진 라벨'인 두 필드를 갖는 Ddi버튼 요소. 이 요소는 UPnP 장치 상의 액션을 야기하는 것을 나타낸다.

- 액션 파라메터의 <관련 상태 변수>필드에 인가되는 맵핑 형식에 따라 액션의 각 입력 파라메터를 위한 Ddi 요소들. 모든 이들 Ddi 요소들은 그들의 상호동작성 속성을 DISABLED로 설정해야 한다.

- 액션 파라메터의 <관련 상태 변수>필드에 인가되는 맵핑 형식에 따라 액션의 각 출력 파라메터를 위한 Ddi 요소들. 모든 이들 Ddi 요소들은 그들의 상호동작성 속성을 ENABLED로 설정해야 한다.

- '부모(parent)'장치를 나타내는 Ddi패널링크 요소는 그 링크이름 필드를 부모 장치의 <장치 형식> 또는 <친한 이름>필드로 설정할 것이다. 선택적으로, 이것은 링크비트맵 필드를 부모 장치 설명내의 활용가능하고 HAVi-호환가능한 <아이콘>값들 중 하나로 설정할 수 있을 것이다.

정적 : UPnP 장치를 DDI구조로 변환

UPnP 내의 장치 설명 문서는 0 또는 더많은 (서브) 장치들을 갖는 루트 장치를 명세한다. 각 장치는 서브 장치들 등의 다른 리스트를 가질 수 있다. 부가적으로, 각 장치는 장치 아이콘, 제조자 이름, 등과 같은 것과 관련된 특정 필드들을 갖는다. (루트 또는 서브)장치는 다음의 DDI 구조로 변환될 수 있다:

- 장치의 <장치 형식> 또는 <친한 이름>필드로 설정된 패널이름을 갖는 Ddi패널 요소. Ddi패널은 Ddi패널링크 요소들을 포함하며, 하나는 자신이 포함하는 각 서브 장치 또는 서비스를 위한 것이다.

- 서브장치를 나타내는 Ddi패널링크 요소는 그 링크이름 필드를 서브 장치의 <장치 형식> 또는 <친한 이름>필드로 설정해야 한다. 선택적으로, 이것은 링크비트맵 필드를 부모 장치 설명내의 활용가능하고 HAVi-호환가능한 <아이콘>값들 중 하나로 설정할 수 있을 것이다.

- 서비스를 나타내는 Ddi패널링크 요소는 그 링크이름 필드를 서비스의 <서비스 형식>필드로 설정해야 한다.

각 비-루트 서브 장치는 다음을 가져야 한다:

- '부모'장치를 나타내는 Ddi패널링크 요소는 그 링크이름 필드를 부모 장치의 <장치 형식> 또는 <친한 이름>필드로 설정할 것이다. 선택적으로, 이것은 링크비트맵 필드를 장치 설명내의 활용가능하고 호환가능한 <아이콘>값들 중 하나로 설정할 수 있을 것이다.

모든 Ddi패널링크들은 ENABLED로 설정된 상호동작성 필드를 가져야 한다. 선택적으로, 이 패널은 상호 동작성 필드를 DISABLED로 설정하고 텍스트컨텐츠 필드가 다음의 UPnP 장치 설명 필드들의 어떤 것에 대한 스트링 값을 보유하면서, Ddi텍스트 요소들을 포함할 수 있다:

<장치 형식>;

<친한 이름>;

<모델 설명>;

<모델 이름>;

<모델 번호>;

<모델 URL>;

<제조자>;

<제조자 URL>;

<일련 번호>;

<UDN>.

최종적으로, Ddi아이콘을 장치 설명 내의 활용가능하고 호환가능한<아이콘> 값들 중 하나로 설정할 수 있을 것이다.

이 방법으로 구성된 DDI 타켓으로부터 DDI 제어기에 의해 렌더링되어야 할 예제 UI가 도 3에 도시된다.

도 3은 홈 네트워크(100)의 부분(300)의 다이어그램이다. 네트워크(100)는 루트 장치(302)를 갖는다: TV/VCR 콤보, 및 TV(304) 및 VCR(306)인 두 서브 장치들을 갖는다. TV(304)는 3 서비스들을 갖는다: 오디오 서비스(308), 비디오 서비스(310) 및 튜너 서비스(312)이다. VCR(306)은 또한 3 서비스들을 갖는다: 시계 서비스(314), 튜너 서비스(316) 및 테이프 서비스(318)이다. 예제는 <친한 이름>필드("나의 침실 놀이"), <제조자>필드("필립스"),<모델 이름>("AZ1010"),<모델 설명>필드("19"TV/VCR 콤보") 및 <아이콘>필드(TV 화상)의 사용을 보여준다. 테이프 서비스(318)는 <허용된 값 리스트> 명세서{"재생중","정지됨","기록중"}을 갖는 "전달"로 이름된 스트링 상태 값(320)을 보여준다. 또한, 이것은 3 액션들을 보여 준다: "재생","정지", 및 "기록", 여기서, "기록" 액션은 <허용된 값 리스트>명세서:{"표준","긴","연장됨"}을 갖는 상태 변수(여기서는 도시 않음)에 관련된 단일 스트링 파라메터를 갖는다.

동적 : 장치 UI를 항해

위에서 설명된 바와 같이, 각 (루트 또는 서브)장치와 각 서비스는 분리된 Ddi패널 요소에 맵핑된다. Ddi패널링크 요소들은 루트 장치로부터 0또는 더 많은중간 서브 장치들을 통해 서비스들 아래로 가로지르는데 사용된다. 부가적으로, 루트 장치 레벨 상을 제외한 각 레벨 상에서, Ddi패널링크는 장치 계층 내에서 위로 여행하기 위해 사용된다. DDI 제어기 장치 상에서 사용자가 패널 상을 체크할 때, 형식 ACT_SELECTED 의 사용자 액션은 DDI 타켓에 보내질 것이다. DDI 타켓은 부모 장치(계층위로 항해하는 경우) 또는 서브 장치/서비스(계층 아래로 항해하는 경우)를 나타내는 타켓패널을 반환하여 이것에 응답한다. DDI 타켓은 그것이 나타내는 UPnP 장치와 통신할 필요가 없다.

동적 : 시작/종료 세션

DDI 제어기와 발생된 DDI 타켓 사이의 세션은 도 4에 도시된다. DDI 타켓이 단계(402) 내의 DDI 서명(subscription)을 수신한 후, 이것은 단계(404)에서 UPnP 설명 문서를 검색한다. 설명 문서에 기초하여, DDI 타켓은 단계(406)에서 Ddi패널 구조 뿐만 아니라 이것이 갖는 모든 Ddi요소들을 구성할 수 있다. 부가적으로, 단계(408)에서 UPnP 장치 상태에 DDI 타켓은 변경들을 GENA 메커니즘을 사용하여 서명한다. "GENA"는 UPnP 문맥 내의 일반 이벤트 알림(Generic Eventing Notification)을 나타낸다. 이벤트는 소스 장치로부터 이벤트들을 수신하고자 하는 하나 또는 그 이상의 다른 장치들로 어떤 시간에든 연결을 시작하도록 하는 소스 장치의 능력이다. 이벤트들은 다중 장치들 사이에 동기화를 개설하도록 사용된다. UPnP 내에서, 이벤트들은 주로 상태 변경들의 비동기 알림에 대해 주로 사용된다. TCP/IP는 이벤트 정보를 나르기 위한 연결들에 대해 서포트를 제공한다. GENA는 이벤트 메시지들의 분배를 허용하도록 관심 장치들과 어드레싱 스킴 사이의 관계들을개설하기 위한 협약들을 부가한다. GENA는 HTTP 어드레싱과 켑슐화(encapsulation)를 사용한다. 단계(410) 내의 분리된 서명들은 각 서비스에 대해 필요하다. GENA SUBSCRIBE 가 모든 상태 변수들의 현재 값들을 반환하기 때문에, DDI 타켓은 UPnP 장치와 '동기화'되고, DDI 제어기가 이들을 요청할 때 모든 DDI 요소들에 대한 정확한 값들을 반환할 수 있다. DDI 타켓은, 설명 문서가 검색되거나(위에서 보였음) '져스트-인-타임 ; just-in-time)'방식으로, DDI 제어기가 상태 변수 값들을 포함하는 패널을 요청하기 바로 전에 상태 변경들을 즉시 기명할 수 있을 것이다. DDI 타켓이 단계(412)에서 DDI 비-기명을 수신한 후에 이것은 자신을 단계(414)에서 상태 변수 변경들로부터 자신을 비-기명한다.

동적 : UPnP 장치에서 비동기 변경들

세션이 DDI제어기와 DDI 타켓 사이에 개설되었을 때, 장치 상태가 일부 다른 제어를 통해 비동기 방식으로 변경하는 것이 여전히 가능하다. 이것은 다른 HAVi 또는 UPnP 응용이거나 물리적 장치의 수동 제어 패널 상의 일부 물리적 버튼을 누르는 사용자 일 것이다. 이 시나리오는 도 5에 개략적으로 도시된다.

동적 : DDI 제어기에서 사용자 동작들

도 6은 DDI 제어기를 운용하는 장치의 디스플레이를 통하여 UPnP 장치와 사용자가 상호 동작을 할 때의 결과인 메시지를 도시한다. 동작 모드는, 사용자는 먼저 액션 파라메터들에 대응하는 소형 장치들을 변경하고, 사용자가 이것을 했을 때 이 액션을 장치상에 유발하는 버튼을 누른다. 어떠한 출력 파라메터도 포함하는 이 액션의 결과는 'disabled' 또는 '비-상호 동작' 모드에 있는 소형 장치들을 사용하여 도시된다.

도 6은, 전형적으로 사용자가 먼저 액션 파라메터들에 대응하는 소형 장치들을 변경하는 것을 도시한다. 이들은 "사용자 액션" 메시지들을 DDI 타켓으로 인도한다. 타켓은 이들 상호 동작들을 UPnP 장치로 보내지 않을 것이지만 오히려 소형 장치들에 의해 나타난 파라메터 값들을 국부적으로 업데이트하는 데 이들을 사용한다. 사용자가 이를 했을 때, 그/그녀는 장치 상의 액션을 나타내는 버튼을 누른다. Ddi버튼의 "RELEASE" 이벤트 상에서, DDI 타켓은 현재 파라메터 값들을 사용하여 SOAP(간단한 객체 엑세스 프로토콜 ; Simple Object Access Protocol) 요청을 구성할 수 있고, 이것을 UPnP 장치에 보낸다. 이 SOPA 액션은 동기적으로 수행되고, 액션이 성공적으로 수행될 때, DDI 타켓은 어떤 것이 있다면 출력 파라메터 소형 장치들에 대한 DDI"변경 리포트"를 반환하여 사용자 액션을 완성할 것이다. 출력 파라메터 값들은 SOAP 응답 메시지로부터 축출된다.

SOAP에 관하여, 이것은 많은 산업 파터너들로부터의 공헌들로 생성되는 프로토콜이고, 이는 응용들이 예를 들어 웹 서비스들을 생성하기 위해 웹 사이트들과 응용들을 연결하기 위한 프레임워크(framework)를 제공하는 인터넷상에서 서로서로 통신하도록 허용한다. 웹 서버들은 사이트들과 응용들을 같이 링크하여 개별 구성요소들 혼자는 수행할 수 없는 기능들을 수행한다.

일반적으로, 제어되는 장치에서 유발하는 액션은 장치의 상태를 또한 변경할 것이며 GENA NOTIFICATION 메시지는 모든 변경된 상태 변수들에 대한 새로운 값들을 나타내는 DDI 타켓으로 잠시 후 보내질 것이다. 이것은 차례로 위세서 설명한바와 같이 Ddi변경알림 메시지들로 인도될 것이며 DDI 제어기 장치의 디스플레이 상에 일부 시각적인 변경으로 궁극적으로 인도될 것이다.

도 6은 에러가 없는 상태를 도시한다. 즉, UPnP 장치에 의해 결국 유발되는 SOAP 응답이 코드 OK를 반환했다는 것이다. 에러의 경우에, Ddi타켓은 사용자에게 실패를 나타내는 DDI내의 경보패널 설비를 사용할 수 있다. 이 '경보패널'은 SOAP 응답<실패스트링>필드를 보유하는 Ddi텍스트 요소를 포함할 수 있다. 이것은 도 7에 도시된다.

발명의 명칭이"CONTROL PROPERTY IS MAPPED ONTO MODALLY COMPATIBLE GUI ELEMENT"인 쉬테닌 지니(Eugene Shteyn)의 1998년 10월 2일에 출원된 미국 제 09/165,682(대리인 명부 PHA 23,484)호는 전자 장치와 이 전자 장치에 결합되는 제어기를 포함하는 홈 네트워크 시스템에 관한 것이다. 이 장치는 제어기에 그 기능성의 추상적인 표현을 내놓는다. 제어기는 추상적인 표현과 상호 동작을 통하여 장치의 기능성을 제어할 수 있도록 한다. 추상적인 표현은 기능성을 제어하는 것의 변경을 명세한다. 명세된 변경의 제어하에, 시스템은 기능성의 제어를 제어기의 형식상 호환가능한 제어 능력과 연관한다. 노출된 형식성은 예를 들어 "논리 연산","부동","정수 어레이"일 수 있다.

용어 "형식성(modality)"은 기능성의 제어가능성의 특성을 기술하는 속성을 말한다. 본 발명에서, 기능성의 형식성은, 장치의 기능성이 모두 무엇에 관한 것인지 실제로 제어기가 알아야할 필요 없이 제어기의 형식성 호환가능한 능력상에 맵핑된다. 예를 들어, 형식성이 의미론적인 논리 연산이라고 가정하라. 논리 연산 제어 특성은 그후 논리 연산 특성을 갖고 "on/off"스위치 또는 "하이/로우" 레벨과 같은 두 상태들 중 하나를 가정하는 UI 요소 상으로 맵핑될 수 있다. 그후 사용자가 이 요소와 상호 동작할 때, 이 위에 맵핑된 기능성은 이 두 상태들 중 하나에 넣어진다. HAVi 시스템에서, 추상적인 표현은 양호하게 UI(예를 들어 음성 제어를 위한) 또는 GUI를 포함하여 업로드되고, 사용자는 UI로 그의/그녀의 상호동작들의 결과들을 결정하는 문맥을 수신한다. 형식성이 이산 값들의 세트일 경우, 제어 특성은 장치상에서 채널 선택을 위한, 다중 장치들 사이의 선택을 위한, 등의 다이얼링(dial)과 같은 3 또는 그 이상의 이산 상태들 중 하나를 가정할 수 있는 GUI 요소 상에 맵핑될 수 있다. 명세된 형식성이 의미론적인 부동 소수점 값들의 범위라면, 맵핑은 예를 들어 소리 볼륨 또는 디스플레이 상의 이미지의 밝기와 같은 연속적인 변수 제어 특성상에 실현된다. 다른 예에서, 명세된 형식성은 의미론적인 어레이 이다. 어레이는 단일 구성요소 이상을 포함한다. 예를 들어, 논리 연산들의 어레이는 그러므로 예를 들어 다른 장치들 또는 체크 박스 리스트 사이의 메뉴 선택과 같은 구현에 GUI 요소들의 클러스터 상에 맵핑될 수 있다. 부동 소수점 형식성들의 어레이는 예를 들어, 홈 네트워크를 통해 제어되는 홈 보안 시스템내의 카메라의 줌 계수들 및 카메라의 각도들을 조정하기 위한 슬라이더들을 나타내는 GUI 요소들의 클러스터 상에 맵핑될 수 있다. 이 제어기가 제어되는 장치의 기능성들 또는 기능성에 관한 단서를 가질 필요가 없음을 주목하라. 이것이 필요로 하는 전부는 기능성을 그 형식성의 의미론들 상에 기초하는 제어 응용으로 보내는 것이다.

1999년 6월 25일 출원된 미국 제 09/340,272 호(대리인 명부 PHA 23,634)인쉬테닌 지니의 "BRIDGING MULTIPLE HOME NETWORK SOFTWARE ARCHITECTURES"는 다른 소프트웨어 아키텍처들의 홈 네트워크들의 브릿지에 관한 것이다. 네트워크들의 제 1 하나 상의 장치들 및 서비스들의 소프트웨어 표현들의 참조들은 자동으로 생성된다. 참조들은 네트워크들의 제 2 하나에 대한 적어도 부분적 기능적으로 균등한 소프트웨어 표현들의 자동적인 생성을 가능하게 하는데 의미론적으로 충분하므로 제 1 네트워크의 장치들 및 서비스들이 제 2 네트워크로부터 엑세스 가능하게 만들 수 있다. 또한 이 문서는 HAVi, 홈 API 및 지니 소프트웨어 아키텍처들도 다룬다.

발명의 명칭이 " CUSTOMIZED UPGRADING OF INTERNET-ENABLED DEVICES BASED ON USER-PROFILE"인 튜너 아드리안(Adrian Turner)등의 1998년 9월 25일 출원된 미국 제 09/160,490 호(대리인 명부 PHA 23,500)는 고객 전자제품들 네트워크-가능한 장비의 특정 최종 사용자의 사용자 측면과 이 형식의 장비에 대한 새로운 기술적 특성들의 데이터 베이스를 유지보수하는 서버 시스템에 관한 것이다. 만약 사용자 측면과 새로운 기술적 특성 사이에 일치가 있고, 사용자가 업데이트들 또는 구매제안들에 관한 정보를 수신하도록 나타내면, 사용자는 이 특성을 얻는 옵션의 네트워크를 경유하여 통지 받는다.

발명의 명칭이 "UPGRADING OF SYNERGETIC ASPECTS OF HOME NETWORKS"인 쉬테닌 지니의 1998년 11월 10일 출원된 미국 제 09/189,535 호(대리인 명부 PHA 23,527)는 사용자의 홈 네트워크 상의 능력들과 장치들의 목록에 엑세스하는 서버에 관한 것이다. 목록은 예를 들어 HAVi 또는 지니 아키텍처에 의해 제공되는 것과 같은 락업 서비스이다. 서버는 또한 네트워크에 대한 특성들의 정보를 갖는 데이터베이스에 엑세스한다. 서버는 사용자의 네트워크 상에 나타나는 장치의 시너지가 사용자의 측면 상에 그리고 목록의 리스트 상에 기초하여 향상될 수 있는 지를 결정한다. 만약 이들 기준에 기초하는 이 시너지에 관련된 특성들이 있다면, 사용자는 통보 받는다.

발명의 명칭이 "TASK-DRIVEN DISTRIBUTED MULTIMEDIA CONSUMER SYSTEM"인 쳄버스 폴(Paul Chambers) 및 스리바스타바 사우라브(Saurabh Srivastava)에 부여된 미국 특허 제 5,959,536(대리인 명부 PHA 23,169)호는 다중 소비자 전자제품 장치들과 장치들 사이의 상호 동작을 제어하기 위한 장치들에 결합된 임무-구동 제어 수단을 포함하는 제어 시스템에 관한 것이다. 제어 수단은 소비자 장치들 중 각 하나의 개개의 개별적인 소프트웨어 표현들상에 동작한다. 소프트웨어 표현 내의 임무의 가변 복잡성을 켑슐화하여, 이것은 능력들을 일반 수준으로 올리는 데 필요한 만큼 간단히 또는 정교하게 만들어 질 수 있다. 인터페이스의 레벨이 장치들에 공통이기 때문에, 응용들은 정교화의 매우 다른 레벨들을 구현하는 장치들을 통일적으로 조작할 수 있다.

Claims (9)

1. 홈 네트워크 내의 제 1 기능성(functionality)들의 제 1 클러스터와 제 2 기능성들의 제 2 클러스터를 브릿지(bridge) 가능하게 하는 방법에 있어서,

   - 상기 제 1 클러스터는 프로그램적인 인터페이스를 통하여 상기 제 1 기능성들의 제어를 제공하는 제 1 소프트웨어 아키텍처(architecture)를 갖고;

   - 상기 제 2 클러스터는 UI-기반 인터페이스를 통하여 상기 제 2 기능성들의 제어를 제공하는 제 2 소프트웨어 아키텍처를 가지며;

   - 상기 방법은 상기 프로그램적인 인터페이스를 상기 UI-기반 인터페이스로의 변환을 제공하는 단계를 포함하는, 브릿지 방법.
2. 제 1 항에 있어서,

   상기 제 1 소프트웨어 아키텍처는 UPnP를 따르고, 상기 제 2 소프트웨어 아키텍처는 HAVi를 따르는, 브릿지 방법.
3. 제 2 항에 있어서,

   상기 제공하는 단계는 UPnP 장치 설명 문서로부터 HAVi DDI 타켓 소프트웨어 구성요소를 발생하는 단계를 포함하는, 브릿지 방법.
4. 홈 네트워크로서,

   - 제 1 기능성들의 제 1 클러스터; 및

   - 제 2 기능성들의 제 2 클러스터를 포함하는, 홈 네트워크에 있어서,

   - 상기 제 1 클러스터는 프로그램적인 인터페이스를 통하여 상기 제 1 기능성들의 제어를 제공하는 제 1 소프트웨어 아키텍처를 갖고;

   - 상기 제 2 클러스터는 UI-기반 인터페이스를 통하여 상기 제 2 기능성들의 제어를 제공하는 제 2 소프트웨어 아키텍처를 가지며;

   - 상기 네트워크는 상기 프로그램적인 인터페이스를 상기 UI-기반 인터페이스로 변환하기 위해 상기 제 1 및 제 2 클러스터들 사이에 브릿지를 갖는, 홈 네트워크.
5. 제 4 항에 있어서,

   상기 제 1 소프트웨어 아키텍처는 UPnP를 따르고, 상기 제 2 소프트웨어 아키텍처는 HAVi를 따르는, 홈 네트워크.
6. 제 5 항에 있어서,

   UPnP 장치 설명 문서로부터 HAVi DDI 타켓 소프트웨어 구성요소를 발생하기 위한 발생기를 포함하는, 홈 네트워크.
7. 홈 네트워크 상에서 사용하기 위한 브릿지 소프트웨어에 있어서,

   - 상기 네트워크는 제 1 기능성들의 제 1 클러스터 및 제 2 기능성들의 제 2클러스터와;

   - 상기 제 1 클러스터는 프로그램적인 인터페이스를 통하여 상기 제 1 기능성들의 제어를 제공하는 제 1 소프트웨어 아키텍처를 갖고;

   - 상기 제 2 클러스터는 UI-기반 인터페이스를 통하여 상기 제 2 기능성들의 제어를 제공하는 제 2 소프트웨어 아키텍처를 가지며;

   - 상기 브릿지 소프트웨어는 상기 프로그램적인 인터페이스를 상기 UI-기반 인터페이스로 변환하는 것에 기초하여 상기 제 1 및 제 2 클러스터들을 결합하도록 동작하는, 홈 네트워크 상에 사용하기 위한 브릿지 소프트웨어.
8. 제 7 항에 있어서,

   상기 소프트웨어는 UPnP를 따르는 상기 제 1 소프트웨어 아키텍처와 HAVi를 따르는 상기 제 2 소프트웨어 아키텍처를 결합하기 위한 것인, 홈 네트워크 상에 사용하기 위한 브릿지 소프트웨어.
9. 제 8 항에 있어서,

   UPnP 장치 설명 문서로부터 HAVi DDI 타켓 소프트웨어 구성요소를 발생하기 위한 발생기를 포함하는, 홈 네트워크 상에 사용하기 위한 브릿지 소프트웨어.