KR20070111449A

KR20070111449A - 네트워크 장치 제어 시스템 및 방법

Info

Publication number: KR20070111449A
Application number: KR1020077012056A
Authority: KR
Inventors: 아리에 발디; 이란 갬펠; 티머시 식스터스; 오데드 발디
Original assignee: 슈페르나 리미티드
Priority date: 2004-10-27
Filing date: 2005-10-27
Publication date: 2007-11-21
Also published as: WO2006046247A3; ZA200704347B; AU2005298253A1; CA2589065A1; US20080288618A1; EP1820118A2; CN101223515A; WO2006046247A2

Abstract

네트워크 된 장치 제어 시스템은 자동 장치 찾기 및 제어의 프로토콜을 구현하도록 동작하는 다수의 네트워크된 장치 콘트롤러를 포함하며,이 콘트롤러 중 임의의 것에 연결되며 상기 콘트롤러에 연결되기 전에 상기 프로토콜과 같이 사용하도록 구성되지 않은 적어도 하나의 비-프로토콜-순종장치를 포함하며, 또한 인터페이스 및 상기 장치들 중 임의의 것과 결합 된 제어요소 중 어떤 것을 발생시키도록 동작하며, 상기 프로토콜과 같이 사용하도록 구성되며 상기 비-프로토콜-순종 장치를 제어하도록 동작하는 프록시를 설정하도록 동작하며, 그리고 상기 인터페이스와 상기 콘트롤러에 연결된 상기 장치에 대해 발생된 상기 제어 요소를 갖는 상기 콘트롤러들 중 임의의 것을 구성하도록 동작하는, 관리 유닛을 포함한다.

통신 프로토콜, 비프로토콜, 인터페이스, 제어장치, 관리유닛, 네트워크

Description

네트워크 장치 제어 시스템 및 방법{NETWORKED DEVICE CONTROL ARCHITECTURE}

본 출원은 발명의 명칭이 "네트워킹 아키텍쳐"이고, 2004년 10월 27일에 바르디 등에 의해 제출되고, 본 명세서에 완전히 참고로 편입되어진 미국 임시 특허출원 제60/622,008호의 우선권 주장에 관한 것이다.

본 발명은 가정과 같은 환경에서 다중 장치와 어플라이언스들을 제어하기 위한, 빠른 설치, 용이한 셋업, 및 유지를 허용하는 시스템을 제공한다. 본 발명에서는 무선 연결성을 제공하는 TCP/IP 및 UPnP^TM과 같은 산업 표준 프로토콜, 및 각각 개별적으로 기능할 수 있는 다중 컨트롤러를 구비하는 범위성(scalablity)을 위한 분산 시스템을 사용하고 있다. 또한, 본 발명은 UPnP^TM 어플라이언스가 UPnP^TM 기반 홈 네트워크 내에 통합되는 것처럼 네트워크 준비 장치와 비-네트워크 준비 장치 사이의 통합 및 브리징을 제공한다.

홈 오토메이션 시스템과 같이 다중 장치(device)와 어플라이언스(appliance)를 제어하는 시스템은 전형적으로 서로 다른 제조업체로부터 장치와 어플라이언스 사이의 제한된 상호 운용성(interoperability)을 제공하고 제어 시스템 내의 이드 의 통합을 위한 주문 프로그램(custom program)을 요구한다. 이런 시스템은 종종 산업 표준 프로토콜 보다는 사유 프로토콜을 사용하고 중앙 프로세서에 장치와 어플라이언스를 연결하기 위하여 물리적 인-월(in-wall) 배선을 요구한다.

본 발명의 일특징에 따르면, 자동화 장치 발견과 제어의 프로토콜을 수행하는 복수의 네트워크 장치 컨트롤러, 임의 컨트롤러에 연결되고 상기 컨트롤러에 연결되어지기 이전에 상기 프로토콜과 사용되도록 구성되지않은 적어도 하나의 비-프로토콜 호환 장치, 및 임의 장치와 연관된 임의 인터페이스와 임의 제어 엘리먼트를 발생하고, 상기 프로토콜과 사용되도록 구성되고 비-프로토콜 호환 장치를 제어하는데 효과적인 프록시를 형성하며, 상기 컨트롤러에 연결된 장치에 대해 발생된 인터페이스와 제어 엘리먼트로 임의의 컨트롤러를 구성하는 관리 유니트를 포함하는 네트워크 장치 제어 시스템이 제공된다.

본 발명의 다른 특징에 따르면, 상기 관리 유니트는 비-프로토콜 호환 장치가 프록시로서 기능하도록 부착되는 임의 컨트롤러를 구성한다.

본 발명의 또다른 특징에 따르면, 상기 프로토콜은 UPnP^TM 프로토콜이다.

본 발명의 또다른 특징에 따르면, 자동화 장치 발견과 제어의 프로토콜을 수행하는 복수의 네트워크 장치 컨트롤러, 임의 컨트롤러에 연결되고 상기 컨트롤러에 연결되어지기 이전에 상기 프로토콜과 사용되도록 구성되는 적어도 하나의 프로토콜 호환 장치, 임의 컨트롤러에 연결되고 상기 컨트롤러에 연결되어지기 이전에 상기 프로토콜과 사용되도록 구성되지않은 적어도 하나의 비-프로토콜 호환 장치, 및 임의 장치와 연관된 임의 인터페이스와 임의 제어 엘리먼트를 발생하고, 프로토콜로 사용되도록 구성되고 비-프로토콜 호환 장치를 제어하는데 효과적인 프록시를 형성하며, 상기 컨트롤러에 연결된 장치에 대해 발생된 인터페이스와 제어 엘리먼트로 임의의 컨트롤러를 구성하는 관리 유니트를 포함하는 네트워크 장치 제어 시스템이 제공된다.

본 발명의 또다른 특징에 따르면, 상기 관리 유니트는 비-프로토콜 호환 장치가 프록시로서 기능하도록 부착되는 임의 컨트롤러를 구성한다.

본 발명의 또다른 특징에 따르면, 상기 프록시는 프로토콜 호환 명령을 비-프로토콜 호환 장치를 제어하기 위한 명령으로 번역하며, 번역된 명령을 비-프로토콜 호환 장치로 전송한다.

본 발명의 또다른 특징에 따르면, 자동화 장치 발견과 제어의 프로토콜을 수행하는 복수의 네트워크 장치 컨트롤러를 배치하는 단계, 상기 컨트롤러에 연결되어지기 이전에 상기 프로토콜과 사용되도록 구성되지않은 적어도 하나의 비-프로토콜 호환 장치를 임의 컨트롤러에 연결하는 단계, 임의 장치와 연관된 임의 인터페이스와 임의 제어 엘리먼트를 발생하는 단계, 프로토콜로 사용되도록 구성되고 비-프로토콜 호환 장치를 제어하는데 효과적인 프록시를 형성하는 단계, 및 상기 컨트롤러에 연결된 장치에 대해 발생된 인터페이스와 제어 엘리먼트로 임의의 컨트롤러를 구성하는 단계를 포함하는 네트워크 장치 제어 방법이 제공된다.

본 발명의 또다른 특징에 따르면, 상기 방법은 비-프로토콜 호환 장치가 상기 프록시로서 기능하도록 부착되는 임의 컨트롤러를 구성하는 단계를 더 포함한다.

본 발명의 또다른 특징에 따르면, 상기 발생 단계는 명령 세트, 통신 프로토콜, 및 인터페이스를 포함하는 비-프로토콜 호환 장치 타입을 정의하는 단계, 및 상기 정의로부터 프록시를 발생시키는 단계를 포함한다.

본 발명의 또다른 특징에 따르면, 상기 방법은 상기 프로토콜 호환 명령을 비-프로토콜 호환 장치를 제어하기 위한 명령으로 번역하는 단계, 및 번역된 명령을 비-프로토콜 호환 장치로 전송하는 단계를 더 포함한다.

본 발명의 또다른 특징에 따르면, 자동화 장치 발견과 제어의 프로토콜을 수행하는 복수의 네트워크 장치 컨트롤러를 배치하는 단계, 상기 컨트롤러에 연결되어지기 이전에 상기 프로토콜과 사용되도록 구성되는 적어도 하나의 프로토콜 호환 장치를 임의 컨트롤러에 연결하는 단계, 상기 컨트롤러에 연결되어지기 이전에 상기 프로토콜과 사용되도록 구성되지않은 적어도 하나의 비-프로토콜 호환 장치를 임의 컨트롤러에 연결하는 단계, 임의 장치와 연관된 임의 인터페이스와 임의 제어 엘리먼트를 발생하는 단계, 프로토콜로 사용되도록 구성되고 비-프로토콜 호환 장치를 제어하는데 효과적인 프록시를 형성하는 단계, 및 상기 컨트롤러에 연결된 장치에 대해 발생된 인터페이스와 제어 엘리먼트로 임의의 컨트롤러를 구성하는 단계를 포함하는 네트워크 장치 제어 방법이 제공된다.

본 발명의 또다른 특징에 따르면, UPnP^TM 명령을 비-UPnP^TM 호환 장치로 전달하기 위한 방법이 제공되는데, 상기 방법은 비-UPnP^TM 호환 장치의 제어 상세(specification)를 적어도 하나의 비-UPnP^TM 명령과 적어도 하나의 UPnP^TM 명령 사이의 매핑으로 변환하는 단계, UPnP^TM 명령을 수신하고 비-UPnP^TM 호환 장치로 대응하는 명령을 출력하도록 UPnP^TM 장치의 인스턴스를 형성하는 단계, 상기 매핑에서 UPnP^TM명령을 탐색하는 단계, 및 비-UPnP^TM 호환 장치로 대응하는 명령을 전송하는 단계를 포함한다.

본 발명의 또다른 특징에 따르면, 상기 명령 상세는 시리얼, IR, 릴레이, I/O, 또는 USB 장치 중 어느 하나로 이루어진다.

본 발명의 또다른 특징에 따르면, 상기 변환 단계는 xml 기반 포맷으로 변환하는 단계를 포함한다.

본 발명의 또다른 특징에 따르면, 상기 방법은 비-UPnP^TM 호환 장치로부터 명령을 수신하는 단계, 상기 매핑에서 상기 수신된 명령에 대응하는 UPnP^TM 명령을 탐색하는 단계, 및 상기 UPnP^TM 명령을 UPnP^TM 컨트롤러로 전송하는 단계를 더 포함한다.

본 발명의 또다른 특징에 따르면, 상기 형성 단계는 다중 서브-어플라이언스가 연결되는 서브시스템을 위한 UPnP^TM 장치를 형성하는 단계를 포함하는데, 상기 UPnP^TM 장치는 각각의 서부-어플라이언스 타입을 위한 하나의 UPnP^TM 서비스를 가지고 각각의 UPnP^TM 서비스는 각각의 서브-어플라이언스를 위한 개별 참조를 가진다.

본 발명의 또다른 특징에 따르면, 상기 방법은 상기 UPnP^TM 명령을 특정 명령으로 번역하는 단계, 및 상기 명령이 송신되는 임의 서브-어플라이언스의 식별자와 함께 서브시스템으로 상기 명령을 전송하는 단계를 더 포함한다.

본 발명의 또다른 특징에 따르면, 상기 방법은 임의 명령으로 인터페이스 엘리먼트를 자동으로 할당하는 단계, 및 상기 인터페이스 엘리먼트가 활성화될 때 상기 인터페이스 엘리먼트와 연관된 명령과 관련하여 탐색 및 전송을 수행하는 단계를 더 포함한다.

명세서와 특허청구범위에 걸쳐서 UPnP^TM에 대한 참조는 컴퓨터 네트워크 환경 내의 장치 및 어플라이언스의 발견, 통신, 및 제어 기능을 제공하는 UPnP^TM 프로토콜 또는 임의의 다른 프로토콜로 참조하게 된다.

명세서와 특허청구범위에 걸쳐서 추가적인 제한없이 "장치" 및 "어플라이언스"에 대한 참조는 호환가능하고 전기 장치로 참조하게 되는 반면, UPnP^TM 장치는 UPnP^TM 프로토콜 용어로 참조된다.

본 발명은 하기의 도면을 참고로 하여 상세히 설명된다.

도 1a는 본 발명의 바람직한 실시예에 따라 구성된 네트워크 장치 제어 시스템의 간략화된 개념도이고,

도 1b는 본 발명의 바람직한 실시예에 따라 구성된 도 1a의 네트워크 장치 제어 시스템의 여러가지 기능적 특징에 대한 간략화된 개념도이고,

도 2a는 본 발명의 바람직한 실시예에 따라 구성된 도 1a의 시스템의 모범적 구현예이고,

도 2b는 본 발명의 바람직한 실시예에 따라 구성된 도 2a의 동작에 대한 모범적 방법을 설명하는 간략화된 순서도이고,

도 3은 본 발명의 바람직한 실시예에 따라 구성된 제어 박스 물리적 인터페 이스의 모범적 구현예이고,

도 4는 본 발명의 바람직한 실시예에 따라 구성된 미니 제어 박스 물리적 인터페이스의 모범적 구현예이고,

도 5는 본 발명의 바람직한 실시예에 따라 구성된 터치 컨트롤러의 모범적 구현예이고,

도 6a는 본 발명의 바람직한 실시예에 따라 구성된 제어 박스의 모범적 구현예의 간략화된 블록도이고,

도 6b는 도 6a의 이더넷 장치를 상세히 도시하는 도면이고,

도 6c는 도 6a의 시리얼 장치를 상세히 도시하는 도면이고,

도 6d는 도 6a의 USB 장치를 상세히 도시하는 도면이고,

도 6e는 도 6a의 카드버스 인터페이스를 상세히 도시하는 도면이고,

도 6f는 도 6a의 선택사양 PCI 슬롯을 상세히 도시하는 도면이고,

도 6g는 도 6a의 X10 장치를 상세히 도시하는 도면이고,

도 6h는 도 6a의 드라이 콘택(dry contact)을 상세히 도시하는 도면이고,

도 7은 본 발명의 바람직한 실시예에 따라 구성된 미니 제어 박스의 모범적 구현예의 간략화된 블록도이고,

도 8은 본 발명의 바람직한 실시예에 따라 구성된 터치 컨트롤러의 모범적 구현예의 간략화된 블록도이고,

도 9a는 본 발명의 바람직한 실시예에 따라 구성된 본 발명의 아키텍쳐 및 시스템과 사용하기 위한 소프트웨어의 모범적 모듈 디자인의 간략화된 개념도이고,

도 9b는 본 발명의 바람직한 실시예에 따라 구성된 본 발명의 아키텍쳐 및 시스템과 사용하기 위한 그래픽 인터페이스 스크린 발생을 위한 모범적 방법의 간략화된 순서도이고,

도 9c와 도 9d는 본 발명의 구성에 사용하기 위한 모범적 프로젝트 특성 다이얼로그를 도시하는 도면이고,

도 9e와 도 9f는 본 발명의 구성에 사용하기 위한 모범적 프로젝트 구조 다이얼로그를 도시하는 도면이고,

도 9g 내지 도 9i는 본 발명의 구성에 사용하기 위한 모범적 추가 장치 마법사를 도시하는 도면이고,

도 9j는 본 발명의 구성에 사용하기 위한 오브젝트 액션 다이얼로그를 도시하는 도면이고,

도 9k는 본 발명의 구성에 사용하기 위한 템플릿 섹션 다이얼로그를 도시하는 도면이고,

도 9l은 본 발명의 구성에 사용하기 위한 오브젝트 통지 다이얼로그를 도시하는 도면이고,

도 9m은 본 발명의 구성에 사용하기 위한 태스크 정의 다이얼로그를 도시하는 도면이고,

도 9n은 본 발명의 구성에 사용하기 위한 컨디션 관리 다이얼로그를 도시하는 도면이고,

도 9o와 도 9p는 본 발명의 구성에 사용하기 위한 장치 컨디션 선택 다이얼 로그를 도시하는 도면이고,

도 9q 내지 도 9s는 본 발명의 구성에 사용하기 위한 장치 태스크 다이얼로그를 도시하는 도면이고,

도 9t는 본 발명의 구성에 사용하기 위한 자동화 관리 다이얼로그를 도시하는 도면이고,

도 10은 본 발명의 바람직한 실시예에 따라 구성된, 간략화된 제어 포인트 순서도이고,

도 11a와 도 11b는 본 발명의 다이얼-업 원격 액세스 제어를 도시하는 간략화된 개념도이고,

도 12는 본 발명의 바람직한 실시예에 따라 구성된, 시리얼 장치와 통신하기 위한 방법에 대한 간략화된 순서도이고,

도 13은 본 발명의 바람직한 실시예에 따라 구성된, 서브시스템과 통신하기 위한 방법에 대한 간략화된 순서도이며,

도 14는 본 발명의 바람직한 실시예에 따라 구성된, 미디어 서버 아키텍쳐의 간략화된 블록도이다.

이하, 본 발명의 바람직한 실시예에 따라 구성된 네트워크 장치 제어 시스템의 간략화된 개념도인 도 1a를 참조하면 다음과 같다. 도 1a에서, 하나 이상의 네트워크 장치 컨트롤러, 이를테면 제어 박스(100)와 미니 제어 박스(102)는 Wi-Fi 네트워크가 될 수 있는 근거리 네트워크(LAN)(104)와 같은 네트워크를 통해 서로 통신하고. 터치 컨트롤러(106)와 같은 하나 이상의 컨트롤러와 통신하며, 대형 터치 패널 인터페이스(108), 소형 터치 패널 인터페이스(110), PC 인터페이스(112), TV 인터페이스(114), 및 PDA 인터페이스(116)와 같은 하나 이상의 인터페이스와 통신한다. 임의의 제어 박스, 컨트롤러, 및 인터페이스와의 통신은 네트워크(120), 이를테면 인터넷을 통해 LAN(104)에 연결될 수 있는 개인용 컴퓨터와 같은 하나 이상의 원격 액세스 터미널(118)을 통해 제공된다. 도 1a의 아키텍쳐는 a) PC, 텔레비젼, 스테레오, 케이블 박스 및 다른 미디어 포인트 사이에서와 같은 오디오와 비디오 컨텐트 스트림, b) 컴퓨팅 장치, c) 인터넷을 통해 접속가능한 것과 같은 네트워크 기반 리소스, d) 네트워킹 환경에서 유니버설 플러그 앤 플레이(UPnP^TM)과 같은 표준화된 네트워크 통신 프로토콜을 사용하는 어플라이언스, 조명, 및 서모스탯과 같은 전기 장치에 대한 액세스 및 제어를 제공한다.

UPnP^TM 또는 랑데부(Rendezvous)^TM와 같은 유사 프로토콜은 바람직하게 네트워크 환경에서 가전제품, 및 컴퓨팅 장치를 포함하는 전기 장치들 간의 상호 운영성을 제공하는데 사용된다. UPnP^TM 네트워킹에 포함된 5개의 기본 단계에는 어드레싱(addressing), 발견(discovery), 설명(description), 제어 및 이벤팅(eventing)이 있다. 이런 단계들은 장치가 로컬 IP기반 네트워크에 동적으로 연결되도록 하고, 그것의 기능성을 통지하거나 또는 네트워크 상의 다른 엘리먼트(예를들면, 제어 포인트)에 의해 발견될 수 있도록 한다. 제어 포인트가 장치의 특성을 인식하게 되어 상응하는 액세스 허용을 획득한 후, 하나 이상의 상태 변수와 상기 변수의 현 재 값의 네임을 포함하는 적당한 이벤트 메시지로 응답할 수 있는, 장치로 실행 요구를 전송함으로써 장치를 제어할 수 있을 것이다. 도 1a의 아키텍쳐의 구현 및 다른 특징은 이하에서 도 1b 내지 도 8을 참조하여 더욱 상세히 설명된다.

도 1a의 아키텍쳐에 기반한 시스템은 다양한 환경, 이를테면 가정 환경에서 설치될 수 있으며, 도 9a 내지 도 14을 참조하여 이하에서 더욱 상세히 기술되는 것과 같은 관리 소프트웨어로 제어될 수 있다. 그런 소프트웨어는 프로젝트 구성과 관리 및 개인화된 인터페이스 생성을 제공하는데 사용될 수 있다. 시스템 인터페이스는 PC, TV 스크린, PDA, 터치 패널 및 이동전화/휴대폰을 포함하는, 브라우저 능력을 갖는 임의의 장치를 통해 표시될 수 있다.

이제, 본 발명의 바람직한 실시예에 따라 구성된 도 1a의 네트워크 장치 제어 시스템의 여러가지 기능적 특징에 대한 간략화된 개념도인 도 1b를 참조하여 설명한다. 도 1b는 도면부호 130으로 지정된 하드웨어 엘리먼트, 및 도면부호 150으로 지정된 관리 소프트웨어의 관점에서 도 1a의 아키텍쳐를 묘사한다. 하드웨어 엘리먼트(130)는 바람직하게 차례로 UPnP^TM 장치 드라이버(136), 및 미디어 렌더러(renderer)(138)을 제어하는, 리눅스와 같은 운영 시스템(134)에 의해 제어되는 임베디드 시스템을 포함한 하드웨어 레퍼런스 디자인(132)을 포함한다. 하드웨어 엘리먼트(130)는 바람직하게 관리 장치 컴포넌트(140)를 통해 웹브라우저와 같은 인터페이스(142)을 통해 액세스된다. 관리 소프트웨어(150)는 바람직하게 제어 스크린 빌더(builder)(154), 홈 오토메이션을 위해 사용될 수 있는 자동화 매니 저(156), 및 프로젝트 매니저 모듈(158)을 포함하는 데스크톱 관리 애플리케이션(152)을 포함한다.

하드웨어 엘리먼트(103)와 관리 소프트웨어(150)는 동시에 고려할 때 바람직하게 이후에 상세히 설명되는 바와 같이 유니버설 원격 제어 능력, 디지털 오디오/비디오 분배, 홈 환경에서와 같은 환경 자동화, 프로젝트 구성과 관리, 및 구성 마법사를 제공한다.

이제, 본 발명의 바람직한 실시예에 따라 구성된 도 1a의 시스템의 모범적 구현예인, 도 2a를 참조하여 설명한다. 도 2a에서, 제어 박스(200)는 예를들어 USB 접속을 통해 카메라(202)와, 예를들어 적외선(IR) 접속을 통해 DVD 플레이어(204)와, X10 접속을 통해 램프(206)와, 예를들어 전기 스위치를 통해 팬(208)와 연결된 것으로 도시되어 있다. 제어 박스(200)는 또한 시리얼 접속을 통해 텔레비젼(210)에 연결된 것으로 도시되어 있다. 제어 박스(200)는 1차 도는 백업 오토메이션 서버로 기능할 수 있는 오토메이션 서버(212), 웹서버(214), 미디어 렌더러(216), 및 관리 장치(218)를 제공하는 온보드 하드웨어와 소프트웨어 능력으로 구성될 수 있으며, 이들 중 어떤 것은 텔레비젼(210)에 제공되는 인터페이스를 통해 액세스될 수 있다. 미니 제어 박스(220)는 또한 플라즈마 텔레비젼(222)(시리얼을 통해), 스테레오(IR를 통해), 및 비디오 카메라(226)(파이어와이어 1394a를 통해)와 연결된 것으로 도시되어 있다. 제어 박스(200)와 미니 제어 박스(220)는 둘다 UPnP^TM 네트워크(228)에 연결된 반면, 제어 박스(200)는 또한 IP 네트워크(230), 이를테면 제 어 박스(200)에 대한 원격 액세스, 확대하면 도 2a의 전체 시스템에 대한 액세스가 제공될 수 있는 인터넷에 연결된 것으로 도시되어 있다. 터치 패널 인터페이스(232)는 램프(234)(X10을 통해), 스테레오(236)(IR를 통해), 및 팬(238)(전기 스위치를 통해)에 연결된 것으로 도시되어 있고, 네트워크(228)와 무선 통신중에 있다. PC 인터페이스(240)는 또한 네트워크(288)와 통신하는 것으로 도시되어 있고, 관리 장치(242), 미디어 서버(244), 제어 포인트(246), 및 관리 소프트웨어(248)로 구성된 것으로 도시되어 있다. 관리 소프트웨어(248)는 바람직하게 프로젝트 매니저(250), 오토메이션 매니저(252), 및 스크린 빌더(254)를 포함한다. PDA 인터페이스(260)는 또한 네트워크(228)와 무선 통신하고 있는 것으로 도시되어 있다.

관리 장치(218와 242)는 장치 컨트롤러(예를들면, 제어 박스, pc)를 위한 UPnP^TM 장치로 구현될 수 있다. 그것의 주목적은 장치 컨트롤러 능력(예를들면, 포트의 수, 이용가능한 디스크 공간 등)에 관련한 정보 서비스를 제공하고 관리 능력(예를들면, 구성 파일 업데이팅, 인터페이스 스크린 등)을 제공하는, 장치 컨트롤러에 대한 게이트웨이로서 기능하도록 하는 것이다. 부가적으로, 상기 관리 장치는 특정 장치 컨트롤러의 하드웨어와 소프트웨어 환경(예를들면,터치 패널에 대한 밝기, 제어 박스에 대한 스위치 알파-벤딩 등)에 대한 액세스를 제공하는, 유틸리티 서비스를 사용할 수 있다.

도시된 예에서, 제어 박스(200와 220)는 가전제품과 어플라이언스의 사용을 관리하는 호스트 소프트웨어에 대한 물리적 연결을 제공한다. 제어 박스(200과 220)는 타깃 장치에서 발견된 여러가지 타입의 커넥터에 대한 물리적 인터페이스, UPnP^TM 호환 네트워크와 비-UPnP^TM 호환, 레가시(legacy) 시스템 및 어플라이언스 사이의 브리지로서 기능을 가진다. 제어 박스(200과 220)는 다음과 같은 상업적으로 이용가능한 하드웨어 컴포넌트를 사용하여 구현될 수 있다.

● 히다찌 SH4 - 소형화된 프로세싱 장치 내에 통합하기 위해 최적화된 CPU.

주요 속성은 높은 MTBF(mean time between failure), 낮은 전력소모, 및 동등한 인텔 X86보다 상당히 낮은 가격을 포함한다;

● 시그마 디자인 8621L - 뛰어난 오디오와 비디오 성능을 위한 부수적 지원을 제공하는, 메인 프로세서를 지원하는 컴패니온 칩;

● 낸드 플래시 64mb 메모리(온보드)- 확장이 플래시 MMC 슬록을 통해 실현될 수 있고 상업적으로 이용가능한 MMC 카드 사이즈를 수용할 수 있다.

제어 박스(200과 220)는 다음과 같은 임의의 커넥터들을 포함할 수 있다.

● 802.11 a/b/g 업그레이드가능한 WiFi 컴포넌트;

● 고속 USB 2.0 포트;

● 전력 관리 지원을 포함한, 파이어와이어 1394a 인터페이스;

● 고속 이더넷(100 Mbps);

● 시리얼 인터페이스 RS232/422/485;

● X10 인터페이스;

● IR 인터페이스 - 트랜스미터와 리시버;

● 범용 I/O.

이제, 본 발명의 바람직한 실시예에 따라 구성된 도 2a의 동작에 대한 모범적 방법을 설명하는 간략화된 순서도인, 도 2b를 참조하여 설명한다. 도 2b의 방법에서, 홈 환경과 같은 환경은 UPnP^TM 작동 및 비-UPnP^TM 작동 장치 및 어플라이언스를 포함하며, 다중 제어 박스와 인터페이스(예를들면, 터치 패널)을 설치하고 그들을 무선 접속 또는 무선 액세스 포인트로서 라우터 서버가 있는 곳에서 무선으로 라우터에 연결함으로써 구성된다. 데스크톱 기반 개인용 컴퓨터와 같은 컴퓨터는 도한 상기 라우터에 연결되고 이후에 더욱 상세히 기술된 관리 소프트웨어로 구성된다. 다음에, 상기 관리 소프트웨어는 환경 관리 프로젝트를 정의하는데 사용되는데, 상기 환경은 하나 이상의 존(zone)으로 분할되고, 존이 하나의 제어 박스 보다 많더라도 각각의 제어 박스는 존에 할당된다. 다음에, 비-UPnP^TM 작동 어플라이언스는 여러가지 제어 박스에 연결될 수 있다. 다음에, 상기 관리 소프트웨어는 제어 박스에 연결된 각각의 비-UPnP^TM 어플라이언스를 위한 프록시로서 기능하도록 UPnP^TM 장치를 정의하는데 사용된다. 또한 UPnP^TM 작동 장치는 이를테면 무선 액세스를 통해 상기 라우터에 접속될 수 있다. 다음에, 인터페이스와 다른 제어 엘리먼트, 이를테면 명령은 각각의 부착된 장치를 제어하기 위해 자동으로 정의되거나, 여기서 관리 소프트웨어는 미리 정의된 템플릿과 장치 정의(예를들면, lirc 적외선 포맷)로부터 인터페이스 스크린과 다른 제어 엘리먼트를 자동으로 발생시킨다, 또는 그 렇지 않으면 사용자에 의해 정의되고 제공될 수 있다. 다음에, 상기 장치 인터페이스와 다른 제어 엘리먼트는 장치가 연결되는 제어 박스에 업로드된다.

도 2b의 방법의 단계들은 예를들어 여러가지 장치가 프로젝트, 존, 인터페이스 및 제어 엘리먼트가 정의된 이후에만 제어 박스에 연결되는 경우에 도시된 이외의 다른 순서로 수행될 수 있다고 이해되어져야 할 것이다. 추가로 여기서 "제어 박스"에 대한 참조는 제어 박스와 미니 제어 박스와 같은 제어 박스의 임의 기능 서브셋 , 터치 컨트롤러, 또는 PC가 접속된 시리얼 어플라이언스를 위한 제어 박스로서 기능하는 경우와 같이 제어 박스로서 구성되는 다른 컴퓨팅 장치를 포함하는 어떤 것에 적용할 수 있다고 이해되어져야 할 것이다.

이제, 본 발명의 바람직한 실시예에 따라 구성된 제어 박스 물리적 인터페이스의 모범적 구현예인, 도 3을 참조하여 설명한다. 도 3에서, 제어 박스 물리적 인터페이스(300)는 이를테면 가전제품을 포함하는 여러가지 전기 장치에 연결하기 위한, 이더넷, WiFi, IR, 시리얼, I/O, USB, 오디오, 비디오 및 PCI 인터페이스를 포함하는 다중 커넥터와 인터페이스를 가지는 것으로 도시되어 있다. 이런 물리적으로 접속된 장치는 PC, LCD, 터치 패널, PDA, 도는 원격 제어 장치, 뿐만 아니라 이동전화, 원격 pc, 및 랜드라인 기반 전화와 같은 원격 제어 포인트를 통해 홈 네트워크 환경 내에서 서로 다른 제어 포인트로부터 동작하고 제어될 수 있다. 상기 제어 박스는 홈 네트워크 상의 제어 포인트로부터 명령을 수신하고, 타깃 장치가 이해하거나 또는 마찬가지로 액션이 타깃 장치상에서 수행될 수 있는 명령으로 번역하며, 타깃 장치로 상기 명령을 보내거나 도는 타깃 장치상에서 상기 액션을 수행 한다.

이제, 본 발명의 바람직한 실시예에 따라 구성된 미니 제어 박스 물리적 인터페이스의 모범적 구현예인, 도 4를 참조하여 설명한다. 도 4에서, 미니 제어 박스 물리적 인터페이스(400)는 다중 커넥터와 인터페이스를 가지는, 전형적으로 도 3의 제어 박스 보다 더 적은 커넥터를 가지는 것으로 도시되어 있다.

이제, 본 발명의 바람직한 실시예에 따라 구성된 터치 컨트롤러의 모범적 구현예인, 도 5를 참조하여 설명한다. 도 5에서, 터치 컨트롤러(500)는 LCD 터치 패널이 될 수 있는 터치 스크린 인터페이스(502)를 가지는 것으로 도시되어 있다. 컨트롤러(500)는 전형적으로 외부 장치에 연결하기 위한 물리적 커넥터를 포함하는, 상기 미니 제어 박스의 내부 하드웨어와 동일한 내부 하드웨어를 가질 수 있다. 컨트롤러(500)는 바람직하게 상기 터치 컨트롤러의 샤시 내에 통합된 파워 서플라이를 포함하고, 바람직하게 벽에 장착가능하다.

이제, 도 2 내지 도 5를 참조하면, 본 발명은 각각의 제어 박스가 그것에 연결된 장치에 관련된 제어 및 자동화 태스크 처리를 담당하는 분산 처리 아키텍쳐를 제공한다. 이런 시도는 부가적인 제어 박스가 전체 시스템에 대한 과부하 없이 현존하는 시스템에 부가되도록 허용한다.

각각의 제어 박스는 바람직하게 상기 하드웨어 및 상기 소프트웨어 애플리케이션과 서비스 사이의 브로커로서 작용하는 운영 시스템과 유사한 크로스플랫폼, 포터블 시스템 소프트웨어가 되는 제어 운영 시스템(제어 OS)에 의해 제어된다. 상기 제어 OS는 바람직하게 다음의 특성을 포함한다.

● 전체 프로젝트에 대한 새로운 구성과 사용자 인터페이스 데이터의 분배를 포함하는, 새로운 장치 발견 및 부착;

● 크로스플랫폼 사용자 인터페이스 발생기;

● 오디오/비디오 장치에 대한 디지털 컨텐츠의 분배를 허용하는, 마이크로소프트 윈도우즈^TM와 리눅스 운영 시스템을 위한 표준 UPnP^TM 미디어 서버와 미디어 렌더러;

● 리눅스 운영 시스템을 위한 소형 포터블 스택을 포함하는, UPnP^TM 제어 포인트;

● 시리얼 RS232/422/485, USB, 및 IR의 지원을 포함하는 UPnP^TM 장치 템플릿.

다시 도 2a를 참조하면, 관리 소프트웨어(248)는 장치 제어 인터페이스와 프로파일의 형성, 유지 및 관리를 용이하게 하는 마이크로소프트 윈도우즈^TM 기반 소프트웨어 애플리케이션으로서 구현될 수 있다. 관리 소프트웨어(248)는 바람직하게 다음과 같은 것들을 제공한다.

● 사용자가 특정 비-UPnP^TM 어플라이언스와 서브시스템 뿐만 아니라 UPnP^TM 어플라이언스에 따라 상기 프로젝트를 구성하도록 하는, 예를들어 자동화된 홈 환경에서 네트워크 장치 제어 프로젝트의 정의 및 설치;

● 인터페이스 스크린 발생 - 상기 프로젝트에 참여하는 모든 장치는 제어가 능해야할 필요가 있다. 상기 스크린 발생기는 각 제어 포인트의 사이즈, 해상도 및 다른 속성에 맞추는 식으로, 사용자가 옥내에 걸친 제어 포인트 상에 나타나는 제어 인터페이스를 형성하도록 한다.

● 라이브 소프트웨어 업데이트, 온라인 지원 및 고장수리.

미디어 서버(Media Server)(244)는 네트웍 상에서 다른 UPnP^TM 디바이스에 오디오/비디오 콘텐츠(예컨대, 미디어)를 제공하는 UPnP^TM디바^이스로 구현하는 것이 바람직하다. 이는 UPnP^TM AV 구조 프레임웍에 기초하여 콘텐츠 디렉토리 서비스(Content Directory service)를 통해 UPnP^TM의 콘텐츠에 공개한다. 이와 같이 미디어 서버(244)는 바람직하게는 어떤 특정 형태의 미디어, 데이터 포맷 및 전송 프로토콜을 제어하여 MPEG-1, MPEG-2, MPEG-4 비디오, CD 오디오, MP3 및/또는 WMA 오디오, JPEG 이미지 및 다른 미디어와 같은 다양한 유형의 콘텐츠를 단일의 일관된 방법으로 네트웍에 공개한다.

사용자들은 예컨대, TV 인터페이스(TV Interface)(210), 터치 패널 인터페이스(touch panel interface)(232), PDA 인터페이스(PDA interface)(260), PC 인터페이스(PC interface)(240)에 의해 제공되는 인터페이스를 통해 시스템과 상호작용한다. 이 사용자 인터페이스는 사용자가 바람직하게는 웹브라우저를 통해 시스템과 상호작용하도록 하며, 이 웹브라우저는 콘트롤 박스(200, 220) 및/또는 인터페이스 디바이스 그 자체에서 구동한다. 이 인터페이스 자원은 소정의 하드웨어 부품에 저 장되어 웹서버(Web server)(214)에 의해 제공될 수 있다.

자동화 관리자(Automation manager)(252)는 계획된 자동화 프로젝트 작업을 생성하고 관리한다. 자동화 서버(Automation server)(212)는 제어 박스, 연결된 PC 또는 터치 패널에 의해 호스트되어 서비스/데몬으로 구현된다. 계획된 자동화 작업은 Microsoft Window^TM 명령들, 스크립트들, UPnP^TM명령들 및 다른 작업들과 같은 명령을 포함한다. 계획된 일은 날짜/시간 이벤트와도 연관이 있다.

자동화 관리자(252)는 모든 양상의 자동화 프로젝트를 생성하고 관리하도록 설계된 가지적인 도구(visual tool)이다. 자동화 관리자(252)는 관리 소프트웨어(magement software)(248)로 완벽하게 통합되어 메인자동화 관리자 인터페이스로 작용한다. 또는 제한된 자동화 관리자는 사용자 인터페이스(예컨대, TV, 터치 패널, PDA 등)를 통해 제공될 수 있다.

전형적으로 UPnP^TM 네트웍(UPnP^TMnetwork)(228)은 서비스 및 중첩 디바이스들(nested device)의 컨테이너인 하나 이상의 UPnP^TM 디바이스를 포함한다. 예컨대, VCR 디바이스는 테이프 이송 서비스, 튜너 서비스 및 시계 서비스를 포함할 수 있다. TV/VCR 콤보 디바이스는 서비스들 뿐만 아니라, 중첩 디바이스들도 포함할 수 있다. 다른 카테고리인 UPnP^TM

디바이스는 다른 서비스들의 세트 및 구현된 디바이스들과 관련될 수 있다. 예컨대, VCR 내의 서비스들은 프린터 내의 서비스들과는 상이하다. 전형적으로 특 정 디바이스 형태가 제공하는 서비스의 세트는 UPnP^TM 디바이스가 호스트하는 XML-기반의 디바이스 서술 문서(XML-based device description document)로 캡쳐된다. 이 서비스의 세트에 덧붙여 디바이스 서술도 디바이스 이름 관련된 아이콘들과 같은 디바이스와 관련된 특성들도 리스트한다.

UPnP^TM

네트워크에서의 가장 작은 제어 유닛이면, 서비스는 상태 변수를 갖는 액션들을 노출시키고, 모델들은 이를 상태 변수로 기술한다. 예컨대, 시간 서비스는 상태 변수, 시간의 상태를 한정하는 현재 시간 및 이를 통해 서비스를 제어하는 2개의 액션들, 설정 시간, 획득 시간을 갖도록 모델링될 수 있다. 디바이스 설명과 유사하게 이 정보는 전형적으로 XML-기반 서비스 설명의 일부분이다. URL과 같은 이들 서비스 기술들의 포인터는 디바이스 기술 문서에 포함된다.

UPnP^TM 디바이스 내의 서비스는 전형적으로 상태 테이블, 제어 서버 및 이벤트 서버와 관련 있다. 이 상태 테이블은 상태 변수를 통해 서비스의 상태를 모델링하여 상태가 변하면 상태 변수들을 업데이트시킨다. 제어 서버는 이들을 실행시키는 설정 시간과 같은 액션 요청을 상태 테이블을 업데이트시키고, 응답을 리턴시킨다. 이벤트 서버는 관심있는 서브스크라이버에게 언제든지 서비스의 변화 상태를 공표한다. 예컨대, 화재 알람서비스는 서비스의 변화 상태가 "링잉(ringing)"으로 변경되면 관심있는 서브스크라이버에게 이벤트를 전송할 수 있다.

제어 포인트(control point)(246)와 같은 UPnP^TM 네트웍 내의 제어 포인트는 다른 디바이스들을 발견하고 제어할 수 있는 콘트롤러이다. 발견한 이후에 제어 포인트는 다음과 같은 동작을 할 수 있다.

● 디바이스 기술을 재생하여 관련된 서비스 리스트를 가져오고;

● 각각의 서비스에 대한 서비스 기술을 재생하며;

● 제어 서비스로 액션들을 호출하고;

● 서비스의 이벤트 소스를 구독한다. 서비스 변경 상태인 경우면 항상, 이벤트 서버는 이벤트를 제어포인트로 전송할 수 있다.

본 발명의 구성요소를 구현한 구현예가 설명되었다. 한편, 본 발명의 특정 하드웨에 구성요소가 제조자에의해 참조될 수 있으며, 도시만을 위해 제공된 참조물인 모델과 본 발명이 언급된 특정 하드웨어 구성요소에 한정되지 않는다고 이해되어야 할 것이다.

도 6A를 참조하여 보면, 본 발명의 바람직한 실시예에 따라 구성되어 동작하는 제어 박스의 예시적인 실시예의 블록 다이어그램이 도시되어 있다. 도 6A에서 330Mhz의 코어 클록과 590MIPS의 처리능력을 가지는 Hitachi SH4 SH77521R 프로세서인 CPU가 도시되어 있다. 바람직하게는 브릿지 없이 4개의 디바이스를 지원하는 표준 33비트 33MHz PCI의 메인 주변 버스가 도시되어 있다. 제어 박스는 적어도 하나의 표준 PCI 보드를 지원하며, 이 표준 OPI 보드는 표준 PCI 슬롯을 통해 제어 박스에 더해질 수 있다. 도시된 바와 같이 오디오 및 비디오 프로세서는 MPEG-1/2/4 성능을 갖는 Sigma Design 모델 8621L이다.

전형적으로 도 6A의 구현예는 특징을 갖는다.

● 802.11b/a/g 표준 카드 버스 지원 가능;

● 비디오용 S-Video 및 합성 입출력;

● 오디오용 RCA Left/Right 및 SPDIF

● 패스트 이더넷 802.3(10/100Mbps) 및 802.11 a/b/g;

● 2개의 USB 커넥터;

● 1개의 IR 수신기 및 8개의 IR 송신기들;

● 외부 디바이스로부터의 6개의 선택적인 입력 및 4개의 접점 신호 릴레이(dry contact relay) 연결;

● RS-232, RS-422 및 RS-485 시리얼 프로토콜을 지원하는 콘넥터들;

이하, 6B-6H를 참조하여 도 6A의 구성에 대하여 보다 상세하게 설명한다.

도 6B에서 도 6A의 이더넷 디바이스는 보다 상세하게 도시된다. 이더넷 디바이스는 Davicom Semiconductor Inc.에서 상업적으로 사용하는 LAN91C111일 수 있으며, ISA버스에 연결된 것으로 도시되며, 바람직하게는 CPU에 의해 제공되는 동기 모드로 동작한다.

이더넷 인터페이스는 802.3 표준에 따라 10/100MBPS의 동작 속도로 동작하는 것이 바람직하다.

도 6A의 제어 박스는 하나의 RS-232 콘솔, 2개의 RS-232 포트들, 하나의 RS-232/RS-422 포트들로 도시된 다중 시리얼 인터페이스이며, 이 모두는 하나의 디 바이스에 의해 발생된다. 이 디바이스는 시리얼 프로토콜과 로컬 버스 간의 브릿지로서 작용하며, SH-4 ISA 로컬 버스 일 수 있다. 이 장치는 MAC 어드레스를 제공하며, 물리적인 시그널링 레벨을 발생시키기 위하여 각각의 시리얼 연결에 대하여 추가적인 PHY를 발생시킨다.

인지 지시(recognition instruction) 및 인터럽트가 인터페이스에 의해 지원받기 위해서 하나의 RS-232 콘솔 드라이버가 제공되는 것이 바람직하다.

RS-232 포트는 바람직하게는 시리얼 포트 드라이버에 의해 지원되며, 표준 데이터 전송율을 제공한다. 2개의 RS-232 시리얼 포트는 RS-232 프로토콜과 완벽하게 호환한다.

RS-485 포트는 시리얼 포트 드라이버에 의해 지원되는 것이 바람직하며, RS485 프로토콜과 완벽하게 호환한다. RS-232로서의 이의 기능은 부트시에 설정될 수 있다.

RS-422 포트는 시리얼 포트 드라이버에 의해 지원되는 것이 바람직하며, RS422 프로토콜과 완벽하게 호환한다. RS-232로서의 이의 기능은 부트시에 설정될 수 있다.

운영체제는 바람직하게는 ISA 버스를 통해 디바이스와 인터페이스할 수 있다. 발생된 인터럽트 신호는 모든 시리얼 포트들에 의해 공유되어 인터럽트를 발생시키는 INT_UART 신호를 로우에서 하이로 강압시키는 전압 변이를 발생시킨다. UART 인터럽트는 PCI 슬롯 인터페이스와 공유되고 운영 체제가 어떤 디바이스가 인터럽트를 발생시켰는지 결정한다. 이 운영체제는 모든 디바이스의 내부 레지스터에 접근할 수 있다.

바람직하게는 nCSA 내지 nCSD의 4개의 추가적인 제어 신호가 있으며, 여기서 각각의 신호는 시리얼 인터페이스에 대한 칩 선택에 작용한다. 운영체제는 이 시리얼 인터페이스 디바이스에 대하여 바람직하게는 CS 신호 및 Reset 신호를 발생시킨다.

또한, GPIO로부터 발생된 2개의 실렉터들은 2개의 라인 표준 RS-232/RS-422 및 RS-232/RS-422를 설정하는 시리얼 PHY 실렉터이다. 이 설정은 소프트웨어를 통해 결정되는 것이 바람직하다.

피지컬 시리얼 커넥터에 부착된 회로는 선택 라인을 갖는 PHY의 회로 중 하나이다. Texas Instruments Inc.에서 상업적으로 얻을 수 있는 TL16C554A가 하기에 도 6A에 도시된 바와 같이 상부로부터 하부까지 연결될 수 있다.

● RS232/RS-285

● RS232/RS-244

● RS232

이 콘솔은 도 6A에 도신된 SH-4 UART 포트에 연결된다.

도 6A의 콘솔 박스의 USB 디바이스는 도 6D에 도시된 바와 같이, USB 디바이스를 PCI 버스에 연결하고 4개의 마스터 포트들을 USB 2.0 연결을 제공할 수 있도록 제공한다. USB 디바이스는 VIA Technologies, Inc.에서 상업적으로 얻을 수 있는 VT6202/VT6212일 수 있다. 각각의 USB 포트는 인터럽트를 발생시킬 수 있다. USB 콘트롤러는 커넥터에 제공되는 전압과 절류를 모니터링하고 과전류인 경우에는 전력을 끊어버리는 전력 모니터링 디바이스를 포함한다.

USB 드라이버는 480Mbit/sec의 속도를 갖는 USB1.1 alc USB2.0을 지원하는 것이 바람직하다.

도 6A의 제어 박스의 인터페이스는 Texas Instruments Inc.로부터 상업적으로 얻을 수 있는 TI PCI1510일 수 있으며, 이는 32bit, 33MHz Wi-Fi 인터페이스 지원 902.11a/b/g 전용의 다일 슬롯 카드 버스를 지원하며, 도 6E와 같이 구현된다. 다른 기업의 Wi-Fi 카드가 슬롯에 삽입될 수도 있다. 지원 카드 버스(32bit) 및 PC 카드(16bit)는 핫 스와핑을 지원하는 PC 카드 및 카드 버스 명세서와 완벽하게 호환된다.

선택적인 PCI 슬롯은 도 6A의 제어 박스에 제공되며 하나의 32bit, 33MHz 단일 슬롯 표준 PCI 보드를 지원하며 도 6F에 도시된 바와 같이 구현된다. 다른 기업의 카드도 슬롯에 삽입될 수 있다. 표준 PCI 슬롯이 제공되어 제1 인터럽트에 연결되고 시리얼 콘트롤러와 공유한다.

X10 디바이스는 도 6A의 제어 박스에 제공될 수 있으며 도 6G와 같이 구현된다. X10 하드웨어는 3개의 신호가 X10 프로토콜을 제어하는 X10 PHY를 지원하는 것이 바람직하다. X10 디바이스에 의해 생성된 인터럽트는 공유되는 것이 바람직하다. X10 디바이스는 X10 프로토콜과 호환되는 것이 바람직하다.

도 6A의 제어 박스는 임계 포인트를 제공하고 TTL 로직 레벨을 실행하는 입력 신호 비교기에 연결된 하나 또는 그 이상의 입력 신호 지시자를 포함한다. 제공 된 접점 신호들(Dry Contacts)은 도 6H에 예시된 방법에 도시된 4개의 접점 신호들인 GPIO에 의해 제어된다. 제공된 드라이버들은 입력 상태를 인지하고 판독할 수 있다. 이는 전용 레지스터로부터 쓰기 및 판독에 의해 릴레이들을 제어한다.

도 6A의 제어 박스는 SH-4 데이터 버스(D0) 또는 인터럽트 인에이블 핀 중 어느 하나에 연결된 IR 수신 장치를 포함하는 것이 바람직하다. 제공된 드라이버는 IR 수신기를 지원하며, 운영 체제는 폴링(polling) 또는 인터럽트 중 어느 하나에 의해 IR 수신기를 샘플링한다. 운영체제는 LIRC와 같은 IR 통신을 제어하는 개방형 소스 디바이스 드라이버를 구현하는 것이 바람직하며, 이 포트로부터 읽기를 허용한다.

도 6A의 제어 박스는 다중 Tx IR 송신기를 지원하며, 다중 Tx IR 송신기들 각각은 하나의 다바이스를 제어할 수 있는 관련된 드라이버를 갖는다. 이 시그널링은 GPIO로부터 추출한다. 전형적으로 하나의 IR 디바이스만이 주어진 시간에 활성화된다. 이 드라이버는 각각의 IR 드라이버에 대하여 접근을 허용한다. 이 소프트웨어는 LILC 커넬 스페이스 드라이버와 묶여져 /dev/lirc 디바이스를 통해 TX 접근을 허용한다.

도 6A의 제어 박스는 MPEG-1, MPEG-2, MP@HL 및 MPEG-4 어드밴스드 심플 프로필 레벨 5(범용 모션 보상이 없는) 용의 Sigma Design EM8621L 단일 칩 오디오/비디오 디코더이다. EM8621L은 통합 TV/PDP A/V 스트리밍, 프로그래시브 DVD 플레이백, 주문자 요청형 비디오(Video-on-demand), 퍼스날 비디오 레코딩(PVR) 및 픽처인픽처와 같은 철저하게 구현된 어플리케이션의 최적화 특징을 포함하는 어드밴 스트 셋탑 장치에 특별하게 디자인 되었다. EM8621L는 공통 구조로부터 추출되어 비디오 및 오디오 디코딩, 스트림 프로세싱, 비디오 프로세싱, 디스플레이, 메모리 및 I/O 지원과 관련된 일련의 공통된 중요한 특징을 공유한다. 게다가, 이 디바이스는 다수의 인기있는 미디어 포맷을 지원을 한다. 지원하는 인기있는 미디어 모맷은 DVD-비디오, 슈퍼비트 DVD, DVD 오디오, SVCD, VCD1.x, VCD2.0, CD/CD-R/CD-RW(오디오, JPEFG, MP3 및 MPEG-4 AVI 파일) 등을 포함한다. 이 디바이스들은 또한 ISMA MPEG-4 스트리밍 포맷 및 MPEG-2 전송 스트리밍 상의 MPEG-4를 지원한다.

EM8621L은 다음과 같은 소스 포맷 및 해상도에 기반한 다중 동시 MPEG 프로그램을 디코딩할 수 있다.

● SD(720x576p 또는 그 이하) : 2개의 MPEG-4 프로그램

● SD(720x576p 또는 그 이하) : 3개의 MPEG-2 프로그램

다중 MPEG 프로그램을 디코딩하는 경우, 각각의 프로그램은 상이하게 취급될 수 있다. 하나가 일반적으로 플레이되면, 두 번째 프로그램은 픽쳐인픽쳐로 사용될 수 있고, 세 번째 프로그램은 제2 TV 또는 VCR에 대한 출력이 될 수 있다.

EM8621L 하드웨어와 동반하는 소프트웨어 지원은 다수의 인기있는 MPEG 기반 비디오 및 오디오 매체를 지원한다. 디바이스 지원 DVD-비디오, 슈퍼비트 DVD, VCD1.x, VCD2.0, SVCD, DVD-오디오, CD/CD-R/CD-RW(오디오, JPEFG, MP3 및 MPEG-4 AVI 파일) 등을 지원한다. EM8621L은 하드웨어 CSS 암호화를 포함하며, DVD-비디오 CSS 절차 명세서를 지원한다. 또한, 16:9 및 4:3 화면 비율, 레터박싱(letterboxing), 팬앤스캔(pan and scan), 다중 각도, 3:2 풀다운(pulldown), 8개까지의 사운드 트랙 및 32개의 하부제목 설정과 같은 DVD-비디오 제어 특징을 완벽하게 지원한다.

EM8621L은 DSP 기반 오디오 디코더를 포함한다. 디코더는 하기의 오디오 포맷을 지원한다.

● 메르디안 로스레스 패킹(Meridian Lossless Pcaking ; MLP)에 따른 DVD-오디오 옵션

● 돌비 디지털 5.1(그룹 A)

● MPEG-1 레이어 1 및 2

● MPEG-1 레이어 Ⅲ(MP3)

● MPEG-4 AAC(저 복잡도, 5.1 채널)

● 윈도우 미디어 오디오

● 16-bit 리니어 PCM

디지털 TV 어플리케이션들을 필요로 하는 오디오 서비스들도 지원된다. 이 오디오 디코더는 5.1 채널 및 S/PDIF를 지원하는 3개의 I2S 디지털 오디오 출력 인터페이스를 사용한다. EM8621L 디바이스는 PCI 버스에 4 번째 장치로서 연결되어 모든 통신이 이 채널을 통해 행해진다. 비디오 입력 신호에 대한 추가적인 장치는 디지털 비디오 포트를 통해 EM8621L를 인터페이스하여 EM8621L 프로세서에 의해 공급되는 I2C 버스에 의해 제어된다.

이 드라이버는 EM8621L 프로세서에 의해 제공되는 모든 특징들을 지원하며, I2C 버스를 통해 비디오 내장 디바이스로 그래픽 디바이스 상의 X-서버를 제공한다. 이 드라이버는 쓰여져 오디오, 비디오 및 이미지 미디어 스트리밍을 제어하는 Sigma Mono Media Player와 함께 동작한다.

도 6A의 제어 박스는 다중 미디어 포맷을 지우너하는 다음의 소프트웨어를 포함하는 것이 바람직하다.

● DVD-비디오, 슈퍼비트 DVD, DVD 오디오, SVCD(IEC 62107-2000), VCD1.x 및 2.0

● DVD-R, DVD-RW, DVD+R, DVD+RW(상대적인, CPRM은 포함않됨)

● 오디오 CD, CD-R, CD-RW, 컴팩트 플래시

● WMA, JPEG, MP3 및 MPEG-41 AVI 파일

● 그림 CD(JPEG 파일)

도 6A의 제어 박스는 다중 오디오 포맷을 지원하는 다음의 소프트웨어를 포함하는 것이 바람직하다.

● MP3 및 MPEG-4 AVI 파일

● 메르디안 로스레스 패킹(MLP)에 따른 DVD 오디오

● 돌비 디지털 5.1(그룹 A)

● MPEG-1 레이어 Ⅰ 및 Ⅱ

● MPEG-1 레이어 Ⅲ(MP3)

● MPEG-4 AAC(저 복잡도, 5.1 채널)

● 윈도우 미디어 오디오

● 16-bit 리니어 PCM

도 6A의 제어 박스는 다중 비디오 포맷을 지원하는 다음의 소프트웨어를 포함하는 것이 바람직하다.

● DVD-비디오,

● 슈퍼비트 DVD

● VCD1.x 및 2.0

● SVCD

● DVD-오디오, CD, CD-R, CD-RW(오디오, JPEG, MP3 및 MPEG-4 AVI 파일)

도 6A의 제어 박스는 다중 스트리밍 포맷을 지원하는 다음의 소프트웨어를 포함하는 것이 바람직하다.

● ISMA(Internet Streaming Media Alliance) MPEG-4

● MPEG-2, MPEG-4, MPEG-2 전송 시의 MPEG-4

● 입력 데이터 비율(각 프로그램 마다)

도 6A의 제어 박스는 다중 비디오 디코딩 표준을 지원하는 다음의 소프트웨어를 포함하는 것이 바람직하다.

● MPEG-1, MPEG-2, MP@ML

● MPEG-4 어드밴스드 심플 프로필 레벨. 직사각형 모양의 비디오 디코딩은 720x576까지 B 그림 및 CIF 해상도로 4 객채 디코딩까지 오류 융통도에 대한 지원에 참가하는 데이터를 을 지원한다.

● DVD-비디오 및 슈퍼비드 DVD

● CSS 암호화

● 16:9, 4:3 플레이백, 레터박스(letterbox), 3:2 풀다운(pulldown)

● 다중 각도 및 하부 그림

● 오차 은폐

● 밝기, 컬러, 각각의 출력 포트에 대한 명암 대비 제어

● 하드웨어 커서,(4096 화소, 픽셀당 4비트, 수평 및 수직으로 255화소

● 2D 그래픽 가속기(최대로 초당 75M 샘플 동작)

● 채우기(Fill) : 단색으로 채워진 직사각형

● 블랜드(Blend) : 알파는 하나의 직사각형을 다른 직사각형에 합침

● 이동(Move) : 직사각형 영역을 다른 영역으로 이동

● 대체(Replace) : 이동의 변형된 버전

● 라인 및 직사각형(Line and Rectangle) : 단일 컬러 라인 또는 직사각형을 생성시킴

● 래스터 옵스(Raster Ops) : 표준 256 불린 동작

● 플리커 필터링 및 스케일일에 따른 32 비트OSD

● 인터레이스된 소스에 대해 선택적인 인터레이스 제거

● 비디오 및 OSD에 대한 1920x1080화소까지의 임의 스케일링

● 비디오, 커서 및 OSD의 알파 믹싱

도 6A의 제어 박스는 다중 이미지 포맷을 지원하는 다음의 소프트웨어를 포 함하는 것이 바람직하다.

● JPEG, PNG, GIF

도 6A의 제어 박스는 알파 블렌딩 특징을 사용을 지원하는 소프트웨어를 포함하는 것이 바람직하다. 이 비디오는 S-비디오에서 Video RCA로 디스플레이 된다.

도 6A의 제어 박스는 2개의 MPEG-2 또는 MPEG-4 표준 정의 프로그램을 지원하고 동시에 픽처인픽처(PIP)를 지원할 수 있도록 하는 소프트웨어를 포함하는 것이 바람직하다.

도 6A의 제어 박스는 풀스크린 그래픽 매뉴 및 이미지들을 비디오 및 하부 그림과 합쳐질 수 있도록 하여 온스크린 디스플레이를 지원하는 소프트웨어를 포함하는 것이 바람직하다. 4개로 구획된 컬러 깊이가 지원된다. 2컬러(화소당 1비트), 4컬러(화소당 2비트), 16컬러(화소당 4비트), 256컬러(화소당 8비트), 256x32 컬러 룩업 테이블(CLUT)은 알파 블랜딩의 256 레벨로 1-, 2-, 4- 또는 8-비트 코드를 24-비트 YCbCr 컬러로 변환하는 데 사용될 수 있다. 화소당 16-비트 포맷은 하기의 포맷을 지원하는 데에 채용하는 것이 바람직하다 그 포맷은 다음은 다음과 같다. 그 포맷은 565RGB, 1555AGRB 및 4444ARGB, 24-비트 888RGB, 32-비트 8888ARGB이 지원되는 것이 바람직하다.

EM8621L은 하드웨어 CSS 암호화 및 DVD-비디오 CSS 절차 명세서를 지원한다. EM8621L은 또한 16:9 및 4:3 화면 비율, 8개까지의 사운드 트랙, 32개의 하부제목 설정,

레터박싱(letterboxing), 팬앤스캔(pan and scan), 다중 각도 및 3:2 풀다운(pulldown)과 같은 DVD-비디오 제어 특징을 완벽하게 지원한다.

도 6A의 제어박스는 128MB의 SDRAM@100MHz를 2개의 뱅크로 구분하고, 각각의 뱅크는 칩 선택(각각 CS2 및 CS3)을 갖는다. 낸드 플래시는 어드레스, 데이터 및 명령 정보아 동일한 핀에서 동작하는 AD 인터페이스를 갖는 저장 장치로 사용될 수 있다.

도 7을 참조하여 보면, 도 7은 본 발명의 바람직한 실시예에 따라 구성되어 동작하는 미니 제어 박스를 구현한 실시예를 개략적으로 나타낸 블록 다이어그램이다. 도 7의 미니 제어 박스는 지금부터 도시된 것에 대하여 설명하는 것을 제외하고는 실질적으로 도 6A의 제어 박스와 유사하다. 도 7의 미니 제어 박스는 하기의 메모리 타입을 지원하는 CPU 코어를 포함한다.

● 부츠 플래시(Boot flash)

● 슈퍼 앤드 플래시, 보드 상의 16/32MB

● 보드 상의 64/128MB.

● 128MB까지의 MMC형 확장 플래시

패스트 이더넷10/100 Mb는 표준 RJ-45 커넥터 타입의 지원을 받는 것이 바람직하다. 송수신기는 CPU에 의해 제공되는 내부 PCI 버스상에 배치하는 것이 바람직하다.

미니 제어 박스는 무선 LAN(802.11b, 802.11b, 802.11g)을 통해 상호 작용할 수 있도록 하는 것이 바람직하다. 디자인은 미니 PCI 표준을 지원하여 다른 회사의 W-LAN을 미니 PCI 상에 지원할 수 있다. 안테나는 2.4G 및 5.8G 대역을 지원하는 것이 바람직하다.

미니 제어 박스 버스는 단독형 어플리케이션을 제어하여 확장 디바이스가 연결될 수 있도록 하는 것이 바람직하다. 이 미니 제어 박스는 CPU에 의해 제공된 내부 PCI 상의 송수신기을 포함하여 외부 디바이스에 대하여 15W의 전력을 구동할 수 있도록 하는 것이 바람직하다. 커넥터는 파이어와이어(Firewire) 드라이버를 구동하는 전력을 공급하는 데에 필요한 6개의 와이어 형일 수 있다.

미니 제어 박스는 4개의 Tx IR 전송기를 지원하고, 각각의 드라이버는 하나의 디바이스를 제어할 수 있다. 시그널링은 RS-232 DTR로부터 추출한다. 오직 하나의 IR 디바이스만이 소정의 시간에 동작한다. 이 커넥터들은 마이크로폰 형태이다.

미니 제어 박스는 RJ-45 표준 커넥터를 갖는 RS-232 프로토콜(UART)에 기반한 하나의 시리얼 포트를 지원한다.

1암페어를 구동할 수 있는 2 접점 신호 릴레이(dry contact relay)가 제공된다.

미니 제어 박스는 단일 단자 와이어(single ended wire)들을 갖는 외부 장치로부터 시그널링을 수신할 수 있도록 하는 것이 바람직하다. 접지 연결은 모든 4개의 입력과 공유된다.

미니 제어 박스가 0-24VDC, 20K 오옴을 넘지않는 입력 임피던스와 1.25V의 로직 임계치 로 설정된다.

미니 제어 박스는 오디오 입출력 시그널링을 지원하는 것이 바람직하다. 마이크로폰 커넥터에 덧붙여 선택적인 헤더가 제공되어 보드 마이크로폰 디바이스의 연결을 제공할 수 있도록 한다. 오디오/마이크로폰 연결은 선택적일 수 있으며, 결과적으로 외부 마이크로폰이 연결된 곳에서 마이크로폰의 단절이 발생한다.

미니 제어 박스 프론트 패널은 다음의 아이템들을 포함하는 것이 바람직하다.

● 표준 핀 출력에 따른 1개의 RJ-45형 시리얼 커넥터.

● 듀얼 USB 커넥터 마스터형.

● 마이크로 커넥터로의 하나의 오디오 출력 .

● 마이크로 커넥터의 하나의 오디오.

● 커넥터에 작동 LED들이 설치된 하나의 RJ-45형 이더넷 커넥터.

● 4개는 시그널링을 위한 것이고, 2개는 전력용인 6개의 핀을 갖는 하나의 파이어와이어 커넥터.

● 외부의 IR 전송 장치용 4개의 IR 커넥터(마이크로폰 커넥터).

● 접점 신호용 2개의 IO 출력 릴레이

마이크로폰 커넥터뿐만 아니라 선택적인 헤터가 부가되어 보드 마이크로폰 디바이스의 연결이 가능하도록 배치될 수 있다. 오디오/마이크로폰 연결은 외부 마이크로폰이 연결되면 결과적으로 마이크로폰의 연결이 단절되도록 선택적으로 구성할 수 있다.

도 8을 참조하여 보면, 도 8은 본 발명의 바람직한 실시예에 따른 터치 콘트롤러의 예시적인 실시예의 개략적인 구성 및 동작을 나타낸 블록 다이어 그램이다. 도 8의 터치 콘트롤러는 하기에 설명하는 것을 제외하고는 도 7의 제어 박스와 실 질적으로 유사하다.

터치 콘트롤러는 추가적ㅇ니 LCD 콘트롤러 및 LCD 디스플레이를 포함하며, 일반적인 미니 제어 박스의 디자인을 포함한다. 바람직하게는 터치 콘트롤러는 800x600(SVGA)까지의 해상도를 갖는 CSTC LCD 또는 활성 TFT LCD 디스플레이를 사용한다.

LCD 디스플레이는 LCD 보드에 연결된 터치 패널 커버를 포함하는 것이 바람직하다. 터치 패널 콘트롤러는 소정의 적적한 수단을 사용하여 LCD 제어 디바이스와 통신한다.

터치 콘트롤러는 벽면 플러그 영역에 일체로 설치되어 이를 85-264V AC 전력선에 직접 연결할 수 있도록 한 AC/DC 모듈을 포함하는 것이 바람직하다. 이 전력 모듈은 표준 전력선용 스위칭 전원인 것이 바람직하다. 이 출력은 DC 5V이며 표준 DC 플러그에서 3A까지이다. 전력 모듈이 DC 5V와 같은 전원에 연결되더라도, 따라서 특별한 전력 배선이 터치 콘트롤러에 전력을 공급할 필요는 없다. 2선 DC 라인 환경이 이미 사용되고 있으며/또는 100-220V AC 전력선을 근방에서 사용할 필요가 없다.

예시적인 동작 방법이 이하 설명되는 구조 및 시스템의 양상에 따라 설명된다. 도시한 목적으로만 설명된 이러한 방법들은 홈 오토메이션 프로젝트에 대하여 설명되었지만, 본 발명이 다른 환경에서 동일하게 적용할 수 있음을 쉽게 알 수 있을 것이다.

도 9A를 참조하여 보면, 도 9A는 본 발명의 바람직한 실시예에 따른 예시적 인 실시예의 구조 및 시스템에 따라 예시적으로 개략적인 모듈러 디자인의 개념도 이며, 거기에 덧붙여, 도 9B를 참조하여 보면, 도 9B는 본 발명의 바람직한 실시예에 따른 간략화된 그래픽 인터페이스 스크린 발생 방생시키는 예시적인 방법을 나타낸 프로우챠트이다. 자기 설명적이지 않은 도 9A 및 도 9B는 하기에 보다 상세하게 설명된다.

통상적으로 자동 프로젝트를 생성하는 것은 환경의 기초적인 레이아웃을 설정하고, 환경을 하나 또는 그 이상의 영역들로 매핑하며, 콘트롤 박스를 덧붙이고, 콘트롤 박스들에 디바이스들을 덧붙이는 것을 포함한다.

도 9c와 도 9d에서, 프로젝트 특성 다이얼로그는 자동화 프로젝트를 형성하는 제1 단계로서 도시되어 있다. 각각의 프로젝트는 바람직하게 프로젝트 구성 파일 내에 저장되는 그것의 특정 타임 존 셋팅에 할당될 수 있다. 다음에, 도 9e에 도시된 바와 같이, 프로젝트 구조는 하나 이상의 존을 부가함으로써 디자인될 수 있다. 이런 프로세스는 이들이 부가될 때 존의 여러가지 장치와 제어 박스에 링크될 그래픽 유저 인터페이스(GUI) 스크린을 형성할 것이다. 다음에 프로젝트 구조는 존 상의 프로젝트 익스플러러 영역상에서 또는 메뉴 또는 마법사로부터 오른쪽 클릭에 의해 그리고 "추가 제어박스^TM"를 선택함으로써 도 9f에 도시된 바와 같은 하나 이상의 제어 박스를 부가함으로써 디자인될 수 있다.

하나 이상의 장치, 이를테면 비-UPnP^TM 어플라이언스는 특정 제어박스상의 프로젝트 익스플러러 영역 상에서 또는 메뉴 또는 마법사로부터 클릭에 의해 그리 고 "추가 장치"를 선택에 의해 프로젝트에 연결될 수 있다. 상기 용어 "어플라이언스"는 이제 임의 종류의 전기 장치 또는 어플라이언스를 기술하는데 사용된다. 이런 프로세스는 부가된 장치의 기능성(예를들어, CD를 재생한다)에 대한 액세스를 제공할 GUI를 형성할 것이다. 바람직하게, 장치가 제어 박스에 부가될 때마다, 상기 제어 박스를 포함하는 존은 부가된 장치에 대한 액세스를 제공하도록 자동적으로 재현될 것이다.

도 9g에 도시된 바와 같은 "추가 장치" 메뉴 아이템의 선택은 추가 장치 마법사를 시작할 것이다. 사용자는 도 9h에 도시된 바와 같이 이들이 각 제어 박스에 연결하기 원하고 홈 네트워크를 통해 동작하기를 원하는 장치의 타입을 선택할 수 있다. 사용자는 제어 박스, IR 장치, 시리얼 장치, X10 장치, 서브시스템, 범용 장치 또는 가시 장치와 같은 엘리먼트에 접속할 수 있다.

장치의 타입이 형성될 때 데이터베이스 윈도우는 바람직하게 도 9i에 도시된 바와 같이 제조업체와 이들의 모델 리스트를 포함하여 열린다. 부가되는 장치가 상기 데이터베이스에서 발견되지 않는다면 사용자는 새로운 모델을 기입하고 장치 컨트롤러를 지정할 수 있다.

모든 요구된 데이터를 제공한 후, 상기 마법사는 모든 요구된 정보를 가질 것이다. 상기 부가된 장치는 다음에 상기 프로젝트 트리, 에 나타날 것이고, 적당한 템플릿 파일이 배치될 것이며, 애플리케이션이 요구된 장치 명령 파일을 검색하여 인터페이스 스크린을 발생시킬 것이다.

"다중 타깃 장치를 위한 자동 GUI 발생" 특징은 바람직하게 홈 오토메이션 프로젝트의 일부가 되는 어플라이언스를 위한 GUI 뿐만 아니라 옥내에 걸친 제어 박스와 존에 대한 엑세스를 제공하는 프로젝트-와이드 GUI 스크린을 제공하기 위해 부여된다. 상기 GUI는 존, 제어 박스, 또는 장치가 부가 또는 변형될 때 홈 오토메이션 프로젝트에 이용가능한 각각의 디스플레이 타입에 대해 자동적으로 업데이트되고 형성된다. 사용자는 변형된 템플릿상의 인터페이스 또는 다른 스킨에서도 요구된 바와 같이 임의의 현존하는 인터페이스를 재현하도록 선택할 수 있다.

디폴트로 제공된 기본 디스플레이 타입들은 TV, PC, 터치 패널 및 PDA를 제공하지만, 제3부분(third-party)를 갖는 통합부(integration)가 Window^TM Media Centera^TM Edition 2005가 제공하는 것과 마찬가지로 생산된다. 시스템은 임의로 그들이 런-타임에 시스템에 추가되어지는 것처럼 추가적인 타겟 디스플레이를 적절하게 보호한다. 사용자는, 자동적으로 생성된 것처럼 그들의 GUI를 필요로 하고 갖는 것처럼, 많은 추가적인 디스플레이 장치들을 추가할 것이다. 다양한 GUI들이 생성된 후에, 사용자는 자신의 구미에 맞게 시각적이고 기능적인 요소들을 변화시키는 것을 선택할 것이다.

런-타임에, 사용자는 특정 디스플레이 타입으로부터 특정 GUI를 가시화시키기 위해 요청할 것이다. 요청된 파일이 주어지고 요청된 GUI 디스플레이를 응답하는 상기 웹서버는 디스플레이 타입을 확인하는 파라미터를 갖고 요청된 "http get"을 수신한다.

적절한 작업을 위한 자동 GUI 처리에 있어, 다음 생성 블록들이 요구된다:

1. 장치 명령 파일(예를 들어, Lirc IR 명령 파일, 연속 명령 파일)

2. 통상적으로 가능한 장치 행위들의 표준화된 명령 이름들(예를 들어, PLAY, STOP, ENTER 등등)

3. 실행 표본화된 장치가 독립적인 장치 타입을 명령하는 템플릿(template)으로 임베디드(embedded) 및/또는 병합(merged)된 일반 함수들

4. 전체 기능적인 GUI 스크린을 생성하기 위한 표본화된 장치 명령 파일을 갖는 템플릿을 병합하는 GUI 생성 메카니즘

상기 GUI 스크린은 템플릿 파일로 정의된 것으로서 독립된 GUI 객체를 심플하고 연속적인 레이아웃을 제공할 것이다. 템플릿의 객체들(그리고, 궁극적으로 GUI 스크린)은 사용된 UI 언어(즉, XUL & HTML)에 의해 정의된 것으로서 제공된 GUI 객체들에 의해 제공되는 고유의 기능성의 사용을 만들 것이다. 사용자은 자동 GUI 생성 후에 에디터(Editor)로 시각적 표현 및/또는 기능성을 변화시키기 위해 임의의 속성 및/또는 이벤트들(events)을 개별적으로 변화시킬 것이다. 선택적으로, 상기 사용자는 자동 GUI 생성전에 그들을 템플릿 파일로 변화를 시킬 것이다.

다음 테이블 리스트는 전형적인 속성들(attributes/properties)

Window

특징명 속성명 가능값들(Possible values)

Skin Style 스크린에 링크된 css 파일로 정의된 것으로서 존재하는 Skin

Height Height 최소 최대 Height 사이의 정수값

Width Width 최소 최대 Width 사이의 정수값

Left Left 0 사이의 정수값

Top Top 0 사이의 정수값

ID id 임의값(요구된)

Description Tooltiptext 임의값(크기 한계)

Font Font 폰트, 크기, 스타일(Bold, Italic, Normal) 언더라인, 칼라

Background

Color Color RGB

Background

Image Image 임의로 제공된 파일 타입(예를 들어, gif, jpg, png)

Button

특징명 속성명 가능값들(Possible values)

Text Label 임의의 특징들(지역화는 브라우저에 의해 제공함)

Height Height 최소 최대 Height 사이의 정수값

Width Width 최소 최대 Width 사이의 정수값

Left Left 0 사이의 정수값

Top Top 0 사이의 정수값

ID id 임의값(요구된)

Description Tooltiptext 임의값(크기 한계)

Font Font 폰트, 크기, 스타일(Bold, Italic, Normal) 언더라인, 칼라

Background

Color Color RGB

Background

Image Image 임의로 제공된 파일 타입(예를 들어, gif, jpg, png)

Frame

특징명 속성명 가능값들(Possible values)

GUI to

Display src 이 콘텐츠의 프레임은 분할 문서임

Height Height 최소 최대 Height 사이의 정수값

Width Width 최소 최대 Width 사이의 정수값

Left Left 0 사이의 정수값

Top Top 0 사이의 정수값

ID id 임의값(요구된)

Description Tooltiptext 임의값(크기 한계)

Font Font 폰트, 크기, 스타일(Bold, Italic, Normal) 언더라인, 칼라

Background

Color Color RGB

Background

Image Image 임의로 제공된 파일 타입(예를 들어, gif, jpg, png)

Label

특징명 속성명 가능값들(Possible values)

Text Label 임의의 특징들(지역화는 브라우저에 의해 제공함)

Height Height 최소 최대 Height 사이의 정수값

Width Width 최소 최대 Width 사이의 정수값

Left Left 0 사이의 정수값

Top Top 0 사이의 정수값

ID id 임의값(요구된)

Description Tooltiptext 임의값(크기 한계)

Font Font 폰트, 크기, 스타일(Bold, Italic, Normal) 언더라인, 칼라

Background

Color Color RGB

Background

Image Image 임의로 제공된 파일 타입(예를 들어, gif, jpg, png)

Image

특징명 속성명 가능값들(Possible values)

Height Height 최소 최대 Height 사이의 정수값

Width Width 최소 최대 Width 사이의 정수값

Left Left 0 사이의 정수값

Top Top 0 사이의 정수값

ID id 임의값(요구된)

Description Tooltiptext 임의값(크기 한계)

Font Font 폰트, 크기, 스타일(Bold, Italic, Normal) 언더라인, 칼라

Background

Color Color RGB

Background

Image Image 임의로 제공된 파일 타입(예를 들어, gif, jpg, png)

이벤트 생성 메카니즘은 사용자가 요구하는 것을 수행하기 위해 GUI(예를 들어, 버튼의 눌림)와 상호작용할 때 "액션(action)"으로 묘사하는 것이 제공되어질 것이다. 상기 자동 GUI이 생성되어진 템플릿이 위에서 기술한 기본 장치 명령들에 대응하는 액션들을 포함할 것이고, 스크립트 실행, 다른 스크린들의 스위칭, 또는 시각적 GUI 조작과 같은 추가적인 액션들을 야기할 것이다. 프로젝트-와이드(project-wide) GUI 스크린들을 위해, 상기 탬플릿은 박스들을 지역으로 나누고 제어하는 링크들을 포함한다. 자동 GUI 생성 후에, 사용자는 객체들의 지정, 선택된 액션들의 오더(order)의 재정렬, 또는 액션 아이템의 삭제하는 존재하는 액션들을 변화시킬 것이다. 예를 들어, 도 9J에 도시된 바와 같이, 만약 프로젝트가 메인 베드룸(Main Bedroom)에 Alias "Yes1"를 갖는 Cable Set Top Box를 포함한다면, 자동 GUI 생성 처리는 자동적으로 기본 명령 "Mute"를 사용하는 메인 베드룸 내의 "Yes1" 상에 "Do "Mute" 액션을 제공할 것이다. 그리고나서, 사용자는 그/그녀 개인적으로 필요에 따라 액션을 변화시킬 것이다.

콜백 핸드링(callback handling) 메카니즘은 런-타임에 인터페이스 스크린에 의해 디스플레이 및/또는 처리되어진 이벤트된 값들(evented-variables)을 위해 허락하는 역시 제공할 것이다. 예를 들면, 프로젝트가 자동온도조절장치(thermostat)를 포함한다면, 온도는 다양한 이벤트값이 존재할 것이다. 사용자는 실시간으로 사 용자 인터페이스를 통해 온도가 변화되어지는 것을 볼 수 있을 것이다.

상기 다양한 이벤트값은 끈, 범위(정수값), 또는 얼라우드 값(allowed value)의 타입일 것이다. 만약 선택된 이벤트 값이 끈 또는 범위 타입이라면, 실제적인 값은 리턴되어진다. 만약 선택된 이벤트 값이 얼라우드 값이라면, 사용자 세팅은 각 가능한 얼라우드 값을 위해 선택적인 데이터를 결정할 것이다. 지도화된 교환 데이터는 텍스트보다 데이터되어질 수 있는 것을 제외하고 위에서 결정된 타켓 선택을 결합시킬 것이다. 예를 들어 만약 탬플릿이 버튼의 아이콘의 변화를 정의한다면, 교환값은 이미지 파일로 통과되어질 수 있다.

통보처리는 스크린 빌더 모듈(screen builder module)에 의해 조작되어질 것이다. 몇몇의 객체들은 윈도우, 버튼, 이미지 및 라벨 객체를 포함하는 컨트롤 포인트로부터 수신된 이벤트된 값들에 통보들을 수신하고 관리할 수 있다. 모든 객체들은 통보 처리를 위해 동일 메카니즘으로 운용하지만, 특정 조건에 다다를 때 실행되어질 수 있는 액션으로 달리한다.

도 9B를 다시 참조하면, 상기 GUI 생성 처리는 다음과 같이 이해되어질 수 있다. 각 콘트롤 박스는 다른 컨트롤 박스들의 하이레벨(high-level) 리스트에 링크된다. "global main"을 참조하면, 사용자가 로컬 프로젝트(local project) 내 다른 컨트롤 박스들에 접근 및 제어하는 것이 가능하다. 각 컨트롤 박스는 역시 그것에 접근된 장치들을 접근 및 제어하는 것이 가능한 "private main" 리스트로 유지할 것이다. 상기 "global main" 리스트 및 그것들에 링크된 모든 파일들은 모든 컨트롤 박스들 상에서 전형적으로 같다. 만약 존(zone) 또는 컨트롤 박스가 프로젝트 에 추가된다면, 상기 "global main"은 모든 컨트롤 박스들에 대해 업데이트되고 분배되어진다.

프로젝트-레벨(project level) GUI는, "net main"을 참조하면, 자동적으로 생성되어 진다. "net main" 인터페이스의 템플릿은 버튼의 2개 타입을 갖는 메인 파일을 포함할 것이다: 홈 오토메틱 프로젝트 내 모든 존들(zones)을 리스트화한 스크린 또는 페이지로 인도되는 "home" 버튼, 그리고 임의의 파일로 인도하는 프레싱(pressing) "zone" 버튼들은 UPMP^TM 부가시스템들에 소속된 부가장치들 모든 숏컷(shortcuts)들 처럼 각 디바이스의 버튼을 나타낸다. 디머(dimmer) 및 스위치와 같은 부가장치들은 라이팅 컨트롤 시스템(Light Control System) 또는 HVAC 시스템들과 같은 구성요소들이다. 부가장치들은 부가시스템에 의존하며, 인스톨 환경을 통해 전형적으로 위치되어져 있다. 상기 부가시스템은 부가장치들을 관리하며 제어하며, 커스텀 인스톨러(custom installer) 및 전기 담당자들(electricians)에 의해 전형적으로 인스톨되어지고 연결(wired)되어진다. 상기 부가시스템은 번갈아 부가장치들을 제어하는 부가시스템을 제어하기 위한 본 발명에 기반한 시스템을 허락하는 시리얼 인터페이스를 통해 컨트롤 박스와 같은 전형적으로 하드웨어 컨트롤러와 인터페이스되어진다.

GUI들은 모든 정의된 장치들을 통해 루핑(looping)에 의해 모든 정의된 존들에 대해 역시 자동적으로 생성되어지고, 각 장치에 대해 속성에 기반한 버튼을 생성하고, 컨트롤 박스 GUI 스크린들에 대한 탬플릿에 정의되어진다. 예를 들어, GUI 객체에 대한 액션 명령을 홀드(hold)하는 버튼의 "onCommand" 속성은, 사용자에 의해 클릭되어질 때, 요구된 장치의 GUI를 개방할 것이다. 이는 존재하는 장치, 버튼 생성 및 UPMP^TM 버튼들의 "onCommand" 이벤트의 장치들을 관리하는 장치 어드레스들의 어드레스 리스트를 사전처리함에 의해 성취되어질 수 있다.

GUI들은 장치의 동일한 이름을 갖는 XML 정의에 대한 검색에 의해 모든 정의된 장치들에 대해 역시 자동적으로 생성되어질 수 있고, 그것(예를 들어, Sony 와이드 스크린 TV 모델 "xyz" 는 "TV" 타입임)으로부터 장치 타입 이름을 추출할 수 있다. 그리고나서, 탬플릿 폴더는, 도 9K에 도시된 바와 같이, 특정 장치에 대한 검색되어진다. 만약 발견된다면, 대응하는 탬플릿이 찾아서 가져올 것이다. 그렇지 않다면 탬플릿이 일반적인 장치 타입이 사용되어질 것이다. 이 경우에 정의되지 않을 경우에 일반적인 탬플릿이 사용되어질 것이다.

장치 이름이 사용된다면, 대응하는 장치 명령 파일(Device Command File)이 가져와질 것이고 장치 명령 리스트를 생성하기 위해 분석되어질 것이다. IR 장치의 경우에, 이 파일은 LIRC 포맷(즉, open-source 프로젝트)에 대응한다. 다른 접속 및 통신 방법들(예를 들어 시리얼 프로토콜(serial protocol))을 사용하는 모든 장치들에 대해, 속성 포맷을 사용하는 장치 명령 파일은 사용되어질 수 있다. 장치 명령 파일들은 탬플릿으로부터 추출된 명령들이 탬플릿 파일들의 명령들과 대응할 수 있도록 하기 위해 사전지정된 표준화된 장치 명령들을 포함할 것이다.

일단 파일들이 분석되어지면, 탬플릿 내의 버튼들은 장치 명령 파일들로부터 추출된 명령리스트에 비교되어진다. 탬플릿 내에 존재하지만 장치 명령 리스트내 대응물을 갖지 않는 임의 버튼이 "onCommand" 액션 지시없이 이동되어진다.

GUI 파일에, 각 표준화된 버튼이 표준화된 이름과 동일한 단일화된 ID를 가지게 될 것이다. 사용자가 버튼을 누를 때 실행되는 일반적인 함수는 시스템의 파라미터 처럼 표준화된 명령 이름을 보낸다. 그리고나서 GUI와 장치의 실행 요청 사이의 루프(loop)를 닫는다.

스크린 빌더는 사용자가 자동적으로 생성된 GUI에 한계되어지지 않는다. 때때로, 상기 사용자는 각 스크린을 시각적으로 기능적으로 모두 변화시키거나 또는 새로운 스크린을 생성시킨다. 새로운 스크린은 프로젝트내 장치들의 임의 숫자를 제어하기 위해 디지인되어질 수 있다. 새로운 스크린이 변화 및 생성되어질 때, 사용자는 백그라운드의 변화, 버튼의 추가, 이미지의 삽입 및 스크린 상의 새로운 아이템들에 대한 이벤트의 지정과 같은 스크린의 디자인을 전적으로 결정할 수 있다.

도 9L에 도시된 바와 같이, 통보 액션들은 각각의 객체와 관련된 "Notification" 탭(tab)을 통해 임의의 스크린 빌더 객체에 지시되어질 수 있다. 장치 통보의 기본 빌딩 블록(basic building block)은 타스크(task)이다. 스크린 빌더 객체는 어떤 이벤트가 홈네트워크 상에 발생되고 타스크의 세트 조건들을 마주칠 때, 하나 또는 그 이상의 타스크를 실행할 것이다.

각 타스크는 네트워크 상의 특정 장치에 소속된 이벤트된 값에 대응하여 테스트된 하나 또는 그 이상의 조건들을 얻는다. 만약, 상기 조건들이 마주칠 때, 선택된 액션들은 실행되어진다.

사용자는 다음에 따른다:

ㆍ도 9M에 도시된 바와 같이, 녹색 "Plus" 아이콘을 누르거나 엠티 로우(empty row)를 더블 클릭하는 것과 같이 새로운 타스크를 추가한다.

ㆍ도 9N에 도시된 바와 같이, 운영 조건(Conditions Management) 다이아로그를 개방하기 위해 타스크 이름을 더블 클릭하는 것에 의해 존재하는 타스크를 편집한다.

ㆍ타스크 이름을 선택하고 붉은색 "x" 아이콘을 선택하는 것에 의해 타스크를 삭제한다.

ㆍ파란색 "Up" 또는 "Down" 화살표를 누름에 의해 타스크 시퀀스를 정렬한다.

타스크 조건은 사용자가 특정 스크린 빌더 객체 상에서 실행되어지기 위한 타스크에 장치 이벤트를 링크하는 것이 가능하다. 상기 사용자는:

ㆍ녹색 "Plus" 아이콘을 누르거나 엠티 로우(empty row)를 더블 클릭하는 것과 같이 새로운 조건을 추가한다. 이는 도 9O 및 도 9P에 도시된 바와 같이, 장치 타입에 의존한 장치 조건 선택 다이아로그를 개방시킬 것이다.

ㆍ도 9P에 도시된 바와 같이, 운영 조건(Conditions Management) 다이아로그를 개방하기 위해 조건 이름을 더블 클릭하는 것에 의해 존재하는 조건을 편집한다.

ㆍ조건 이름을 선택하고 붉은색 "x" 아이콘을 선택하는 것에 의해 조건을 삭제한다.

ㆍ파란색 "Up" 또는 "Down" 화살표를 누름에 의해 조건 시퀀스를 정렬한다.

할 것이다.

타스크 조건은 홈 네트워크 상의 특정 장치에 링크되어질 것이다. 상기 조건과 가능값들은 통보들이 수신되어져 장치가 선택되어지자 마자 결정(즉, 장치 XML 내역으로부터 가져옴)되어질 것이다. 가능한 옵션들은 선택된 장치 타입 및 그것에 연결된 타입에 의존할 것이다. 그래서, 어떤 장치들은 예로서 도 9Q-9S에 도시된 바와 같이 다른 장치들이 가능한 범위의 수치적인 값들을 제공하는 동안에, 가능한 이벤트들의 특정 리스트를 제공한다.

모든 특정된 조건들에 마주칠 때, 하나 또는 그 이상의 액션들이 실행되어진다. 사용자는:

ㆍ도 9M 내의 녹색 "Plus" 아이콘을 누르거나 엠티 로우(empty row)를 더블 클릭하는 것과 같이 새로운 액션을 추가한다. 이는 도 9O 및 도 9P에 도시된 바와 같이, 장치 타입에 의존한 장치 조건 선택 다이아로그를 개방시킬 것이다.

ㆍ도 9P에 도시된 바와 같이, 운영 조건(Conditions Management) 다이아로그를 개방하기 위해 액션 이름을 더블 클릭하는 것에 의해 존재하는 액션을 편집한다.

ㆍ액션 이름을 선택하고 붉은색 "x" 아이콘을 선택하는 것에 의해 액션을 삭제한다.

ㆍ파란색 "Up" 또는 "Down" 화살표를 누름에 의해 액션 시퀀스를 정렬한다.

할 것이다.

가능한 액션들은 아래에 기재된 것처럼 GUI 객체(즉, 라벨, 버튼, 이미지 또는 윈도우)들과 함께 다양할 것이다. 액션이 선택되어지는 것에 의존하며, 세트되어진 요구된 파라미터들을 허용하기 위해 적절한 다이아로그가 개방될 것이다.

다음의 테이블은 통보 타스크 발생(예를 들어, 버튼이 처리되어질 때 통보가 발생될 때, 사용자가 버튼 이미지를 변화시키면, 보더 칼라의 변화, 백그라운드 칼라의 변화를 발생시키는 등등)때 GUI 객체에 실행되어지는 액션을 요약한다.

자동 GUI 생성은 적절한 장치 기능성과 함께 탬플릿을 통합시킨다. 사용된 탬플릿은 장치 인터페이스들에 대해 운용되는 같은 메카니즘을 사용하여 생성되거나 변화되어질 것이다. 사용자의 요구에 따라 일단 탬플릿이 생성되어지면, 그 응용(application)에 따라 "templates folder"에 저장되어진다.

자동 매니저(automation manager)는, 도 9T에 도시된 바와 같이, 자동 타스크를 운영하기 위해 제공되어진다. 자동 매니저는 임의 컨트롤 박스, 미니 컨트롤 박스, 터치 컨트롤러, 또는 연결된 PC에 지시되어 지는 자동 서버에 의해 구현되어질 것이다. 자동 매니저는 타스크 이름, 서술(description), 카테고리(예를 들어, 비밀, 베케이션(vacation), 자동), 상태(예를 들어, Active/Disabled), 그리고 타스크 타입(예를 들어, 재생 타스크 지시, 타임-베이스드 타스크, 또는 시간+UPMP^TM 이벤트 믹스(mix))타스크들을 기록할 것이다.

자동 매니저내 타스크는 콘텐츠, 시간 조건들 및 변화에 대한 타스크의 액션을 나타낸 타스크 에디터(task editor)에서 편집되어질 것이다. 타스크 에디터는 하나 또는 그 이상의 이벤트 또는 날짜/시간 트리거들(triggers)과 함께 액션들의 관계를 보여짐/편집하기 위해 사용되어질 것이다. 상기 타스크 에디터 GUI 역시 날짜/시간 및 운영의 재발생 관리(re-occurrence management)를 제공할 것이다. 타스크 조건은 이벤트된 다양성에 관련되어져 있다. 상기 타스크 에디터는 다음을 제공한다:

a. 프로퍼티 매니지먼트(일반적인 타스크 인포(Task Info)를 포함)

ⅰ. 타스크 ID(편집 불가)

ⅱ. 이름(편집가능)

ⅲ. 날짜 생성(편집 불가)

ⅳ. 서술(편집가능)

ⅴ. 카테고리(편집가능)

ⅵ. 상태(편집가능)

ⅶ. 다음 시간(편집 불가)

b. 스케쥴링 & 재발생 관리

c. 조건 관리는 타스크의 액션 리스트와 연관되어지는 조건 리스트의 설립에 대한 포인트를 입력하는 것을 제공한다. 아마 모든 조건들을 리스화할 것이다.

d. 액션들:

ⅰ. 아이콘이 액션 타입과 연결된다.(UPMP^TM, JavaScript^TM, 등등)

ⅱ. 액션 리스트는 매크로(macro)로 저장될 수 있다.(예를 들어 디스크로)

ⅲ. 매크로는 다른 매크로들을 포함한다.

ⅳ. 매크로들은 Windows^TM 명령어들, 스크립트들 및 UPMP^TM 명령어들을 포함한다.

변화들이 자동 타스크에 만들어질 때, 상기 변화들은 시스템 내 어느곳에서나 유지되는 모든 자동 리스트들과 동조할 것이다.

인터페이스 스크린은 사용자가 시스템에 영향을 끼치고 제어하기 위해 제공되어진다. 상기 인터페이스들은 웹기반이며, 디스플레이들, 터치 패널들, PC들 및 PDA들과 같은 조작 장치들과 처럼 텔레비젼 스크린들이 연결되어져 사용하는 것과 같이 임의의 컨트롤 박스에서 실행되는 브라우저를 통해 접근가능하다. 인터페이스 리소스들(resources)는 컨트롤 박스 또는 다른 적절한 시스템 요소들에 저장되어질 것이며, 임베디드 웹서버(embedded web server)에 의한 요청에 봉사되어질 것이다.

인터페이스 스크린들은 그들의 가시적 표현 및 GUI 요소들의 기능성을 취급하기 위해 커스터마이즈될(customized) 것이다. 부가적으로, 자동 GUI 생성 메카니즘은 엔드 유저(end-user)가 전적으로 기능적 GUI들을 빠르게 생성하는 것을 허락 한다.

도 10에 도시된 바와 같이, UPMP^TM 명령들은 사용자 인터페이스 스크린으로부터 처리를 위한 컨트롤 포인트로 보내어진다. 상기 본 발명의 구조적인 디자인은 컨트롤 포인트와 같은 언더라인닝 백엔드 기능성(underlying backend functionality)으로부터 사용자 인터페이스 스크린 요소들을 분할할 것이다. 그러므로, 상기 인터페이스 스크린 기술은 시스템 구조에 영향을 미치지 않고서 언제든지 대체될 수 있다.

상기 사용자 인터페이스는 컨트롤 포인트와 통신하기 위한 PDA들, Microsoft Windows^TM Media Center^TM, 및 JavaScript^TM 처럼, XUL(XML-based User-interface language) 또는 HTML을 운용할 수 있다. XUL 은 Netscape Mozilla^TM 브라우저내 윈도우 레이아웃을 기술하기 위해 사용된 XML의 응용이다. 임베디드 OS는 리눅스가 기본이며, Netscape/Mozilla^TM 웹브라우저의 버전은 HTML 4.0, CSS, XML, RDF, XUL 및 JavaScript^TM 과 같은 인터넷 스탠다드(internet standard)를 개방하여 지원하는 디자인된 곳에서 운용되어질 것이다.

상기 사용자 인터페이스는 구성원들의 3 분산 세트들로서 전형적으로 정의되어질 것이다:

1. Content: 이는 윈도우를 나타내고, 사용자 인터페이스 요소들은 그들에 관련된다.

2. Skin: 콘텐츠들 스타일이 응용의 표현(the appearance of an application)을 정의하기 위해 쉬트되고 이미지화된다.

3. Locale: 응용 내 디스플레이 가능한 텍스트이 이식성이 용이한 언어에 대한 특정 파일들 장소 내에 분할되어지고, 저장되어진다.

적외선 원격 제어는 콘트롤 박스에 연결된 텔레비젼 상에서 웹 기반 UI가 제어가 사용되어질 것이다. 상기 원격 제어는 사용자가 사진 또는 영상을 줌인 또는 줌아웃하는 것, 홈 네트워크를 거쳐 미디어를 스트리밍하는 것, 또는 네트워크에 연결된 장치들을 작동하는 것과 같은 하드웨어 상에서 특정 작동을 실행하기 위해 허락하는 기능성을 포함할 것이다.

게다가, 상기 원격 제어 컨트롤 상의 다수의 버튼들은 사용자의 요구에 따라 UPMP^TM 액션들을 실행시키기 위해 프로그램되어질 수 있다. 예를 들어, 전원 버튼은 텔레비젼을 턴온, A/V 모드로 스위치, 리시버로 턴온 및 특정 채널로 케이블 박스를 스위치할 수 있는 연속적인 명령들을 실행시키기 위해 프로그램되어질 수 있다.

특정한 컨트롤 박스와 함께 사용자가 원격 제어를 구성하기 위해, 상기 컨트롤 박스는 여기에 기재한 바와 같이 접근되어져야 하며, 원격 제어 속성들 윈도우는 접근되어진다. 그리고나서, 원격 제어 버튼들은 선택되어지고 구성되어진다. 스크린 빌더 객체의 이벤트 지시와 유사하게, 상기 원격 제어의 UPMP^TM 특정 명령에 이벤트들은 지시되어질 수 있다.

모바일 또는 랜드라인 폰(landline phone)을 사용하는 것은 웹이 불가능하 고, 사용자들은 본 발명과 연관되어 구성되어지는 그들 홈을 호출할 수 있으며, Interactive Voice Response(IVR) 메뉴와 상호작용하는 것에 의해 자동 프로젝트를 엑세스한다. 상기 IVR 메카니즘에 대한 메뉴는 전통적인 방법들을 사용하는 사용자 인터페이스에 의해 생성되어지고 커스터마이즈되어진다.

도 11A 및 도 11B에 도시된 바와 같이, 사용자는 2가지 선택적인 방법을 사용하는 원격 액세스 컨트롤 박스로 다이얼링할 수 있다:

1. PSTN 네트워크를 이용하는 Regular landline phone, 이 시나리오에서 원격 액세스 컨트롤 박스는 기존적인 모뎀을 통해 PSTN에 접속되어 있다.

2. 임의 무선 작동자가 이용하는 모바일, 이 시나리오에서 사용자는 2.5G 또는 3G 네트워크 기술들에서 작동하는 것이 가능한 모바일 폰인 WAP 또는 GPRS를 통해 원격 액세스 컨트롤 박스에 액세스한다.

일단 접속되면, 원격 액세스 컨트롤 박스는 IVR 메뉴와 함께 콜러(caller) 및 현재의 그/그녀를 인증할 것이다. 상기 사용자는 메뉴옵션들을 듣게될 것이며, 키패드 상의 버튼들을 누르는 것에 의해 다양한 홈 오토메이션 기능들을 실행할 것이다. 게다가, 사용자 인증과 같은 서비스들은 이메일로 voicemail retrival, SMS 또는 보이스메일(voicemail) 역시 제공되어질 것이다.

본 발명은 웹 페이지 브라우징, integrated 웹 브라우저 사용, Voice over IP와 같은 IP 기반 서비스들과 함께 그 통합을 용이하게 하는 IP 기반 플랫폼을 제공한다. 본 발명의 어떤 방법들은 다음을 포함하는 VoIP와 함께 통합되어진다:

ㆍ시스템 인터페이스들로 메시징의 통합

ㆍ메시지를 주고받는 것에 대한 단일화된 메시지(Unified Messaging) 또는 VoIP 시스템들과 상호 연관되는 인터페이스 장치들 사용

ㆍ비디오 컨퍼런싱(video conferrencing) 제공

ㆍ텔레포니(telephony)를 포함한 홈 장치의 통합. 예를 들어, VoIP가 들어올 때 콜(call)이 감지되고, 스테레오 시스템은 특정 사운드 파일을 음소거하거나 실행한다.

미디어 매니저(media manager) 응용(application)은 여기 도 2A에서 참조로 기재된 미디어 서버에 프론트-엔드(front-end)와 같은 기능이 제공되어 진다. 상기 미디어 매니저는 XUL, HTML 및 JavaScript^TM 를 이용하여 구성되어지며, 네트워크 상에서 실행가능한 미디어 파일을 운영한다.

상기 미디어 매니저 응용은 사용자가 그들의 미디어 폴더들 및 위치를 보는 것을 허락하기 위해 디자인되어져 있으며, 그들이 홈 네트워크에 접근하는 것을 결정한다. 미디어 매니저에서 실행 가능한 상기 미디어 파일들은 폴더들 및 시스템-제공된 미디어 파일들을 포함한다. 만약 홈 네트워크가 가능하다면, 상기 사용자는 임의의 폴더들 및 부폴더들(subfolders)을 통해 운행되어질 수 있다. 폴더 뷰 패인(folder view pane)들 내 파일을 선택은 파일들의 속성이 파일 정보 패인(pane)에 디스플레이되어지는 원인이 될 것이다.

하나 또는 그 이상의 가상 디렉토리들은 다음과 같이 제공되어질 것이다. 긴 안목에서 엔드 유저들(end user's)로부터 가능 디렉토리는 네트워크 상의 미디어 컨트롤러 또는 다른 미디어 처리 장치들로 접근이 가능한 미디어를 포함하는 폴더로서 나타날 것이다. 상기 미디어 컨트롤러는 네트워크 상에서 가능한 다양한 미디어 서버들로 프론트-엔드(front-end)와 같은 기능이 제공되어진다. 미디어 매니저와 반대로, 미디어 컨트롤러는 네트워크 상에서 사용자가 특정 미디어 파일에 접근하는 것을 허락할 의향이 있으며, 그들을 네트워크 상에서 가능한 요구된 미디어 랜더러(renderer)에게 스트리밍한다. 상기 미디어 컨트롤러는 XUL, HTML 및 JavaScript^TM 를 이용하는 것으로 구성되어져 있으며, 모든 기본 디스플레이 타입들에서 가능하다. 상기 가상 디렉토리는 사용자 하드 드라이버 상의 원래 위치의 미디어 파일의 변화없이 생성된다. 상기 미디어 서버는 이전에 사용된 가상 디렉토리들을 포함하는 가능한 가상 디렉토리들을 신뢰성있게 유지할 수 있다. 인스톨 후에 언제든지 사용자는 폴더에 브라우징하고, 그들을 가상 디렉토리 리스트에 추가하고, 또는 그들로부터 디렉토리들을 제거하는 디렉토리들을 추가할 수 있다. 이 특징이 더 나은 세팅들을 통해 사용되지 않는다면, 모든 디렉토리들은 이 "root" 디렉토리 아래에 디폴트로서 접근 가능하다. 디폴트 폴더들은 가상 디렉토리 리스트로부터 제거되어지지 않도록 설립되어질 수 있다.

사용자는 언제든지 미디어 파일들이 지원되어지는 존재에 대해 시스템을 스캔할 것이다. 이 처리는 연결된 장치들에 저장된 모든 지원되는 미디어 파일들 상에서 정보를 선택하고, 네트워크 상에서 가능한 그들을 만든다. 일단 미디어 파일이 가상 디렉토리 트리 뷰(tree view)에 나타나면, 네트워크 상에서 그들의 가능성 은 상기와 같이 기재된 특징을 추가/삭제를 이용하여 운영되어질 수 있다. 스캐닝은 미디어 서버가 초기에 인스톨될 때 수행되어질 것이다. 스캐닝 처리 초기에는, 스캔과 관련된 파일 시스템의 트리가 생성되어진다. 가상 디렉토리들은 사용자 선택에 기반한 미디어 서버에 추가되어질 것이다.

상기 사용자는 파일 사이즈에 기반한 미디어 파일의 필터링을 수행할 것이다(예를 들어, 1MB 보다 작은 파일들을 배제). 상기 적용된 선택과 필터링은 사용자가 미래의 스캔동안 보호되어질 수 있다. 활동적인 가상 폴더들의 아래에 있는 새로운 파일들과 폴더들은 추가되어지고, 그들이 사용가능해지면 자동적으로 네트워크에 가능해진다.

런-타임시에, 자동적인 스캐닝은 단지 가상 디렉토리들 상에서만 수행되어진다. 수동적인 스캐닝은 컴퓨터에 부착된 임의의 하드 드라이브/폴더 상에서 수행되어진다. 가상 디렉토리들은 요구된 바와 같이 부가되어진다.

상기한 바와 같이, UPMP^TM 장치는 UPMP^TM 장치들의 다른 카테고리를 정의하는 서비스들의 컨테이너(container)이며 보금자리 장치이다. XML 장치 기술 문서는 임베디드 서비스 및 장치 속성(예를 들어 장치 이름)에 관한 정보를 포함하는 모든 장치 메타데이터(metadata)를 유지하는 장치에 의해 호스트된다. 본 발명에 따른 상기 UPMP^TM 장치 구성은 리눅스 및 Windows^TM 상의 Intel^TM UPMP^TM SDK의 상부에서 실행되는 크로스 플랫폼 코드(cross-platform code)일 것이다.

가능한 장치들을 non-UPMP^TM 로 연결을 제공하기 위해, UPMP^TM 브리지 장치들 은 다수의 인터페이스 타입들에 대해 구성되어질 것이다. UPMP^TM 소프트웨어는 미디어 서버(도 2A)와 미디어 랜더러(도 1)을 포함한다. 반면, UPMP^TM 장치 브리지들은 IR, serial, 부시스템 장치들(예를 들어 라이팅(lighting), X10) 및 USB 장치 브리지에 대해 정의되어질 것이다.

본 발명의 상기 UPMP^TM IR 장치는 UPMP^TM 네트워크와 IR 전송 인터페이스 사이에서의 브리지는 LIRC Open-Source 프로젝트를 통해 구성되어지고 하드웨어 내 ControlOS 내에 임베드되어지는 것으로서 행동한다. 선택적으로, LIRC Open-Source 프로젝트는 장치 컨트롤 네트워크에 부착된 PC 상에서 호스트되어질 것이다. LIRC의 중요한 부분이 lirc 장치 드라이버에 의해 수신된 IR 시그널을 디코드한 lircd daemon이라는 것이다. 그리고 소켓으로 정보를 제공한다. 상기 UPMP^TM IR 장치는 리눅스 아래에서 실행시키기 위해 구성되어질 수 있으며, 하드웨어에 의존하는 다른 포트들 상에서 실행될 수 있도록 구성되어질 수 있다. 상기 UPMP^TM IR 장치는 다음과 같이 정의되는 단일 서비스를 포함할 수 있다:

〈service〉

〈serviceType〉urn:schemas-upnp-org:service:IRCONTROL:1

〈serviceType〉

〈/service〉

다양한 요소들과 속성들이 UPMP^TM IR 장치에 대한 서술 문서로서 정의되어질 수 있다. 〈lircRemoteName/〉는 LIRC daemon 과 통신하기 위해 적절한 원격 이름과 함께 사용되어질 수 있다. 그러므로, 이 서비스에 의해 노출된 임의의 UPMP^TM 명령은 구성된 원격 이름에 의해 정의된 LIRC daemon으로 자동적으로 보내질 수 있을 것이다.

본 발명의 상기 UPMP^TM serial 장치는 UPMP^TM 네트워크와 serial 전송 인터페이스 사이에서의 브리지는 하드웨어 내 ControlOS 내에 임베드되어지는 것으로서 행동한다. 상기 serial 장치 서술 XML 문서 탬플릿은 다음과 같이 정의되는 단일 서비스를 포함할 것이다.

〈service〉

〈serviceType〉urn:schemas-upnp-org:service:SERIALCONTROL:1

〈serviceType〉

〈/service〉

직렬장치 탬플릿(Serial Device Template)은 TCP/IP 네트워크에 기반한 UPnPtn 과 직렬 프로토콜 사이에서 어댑터(adapter)로서 가능한다. 이것은 인터페이스파일에 기반한 잘 짜여진 XML 형태로 모든 장치에 특정 통신 셋팅(setting)과 파라미터에 대한 번역을 포함한다. 이 솔루션(solution)은 부호화 또는 컴파일화(compilation)을 요구하지 않으며, 드라이버는 여하한 텍스트 에디터(text editor)내에서도 수정되고 유질 될 수 있다. 특정 직렬장치에 관한 모든 정보는 제 조자가 공그바는 메뉴얼이나 직렬장치 기술로부터 추출될 수 있을 것이다.

도 12에 도시되어 있듯이, 직렬장치를 갖는 통신 프로세서는 응용 기기에 의해 실행되어 질 동작을 요구하는 사용자에 의해 시작된다. 예를 들면, 사용자는 사용자 화면 상의 볼륨 업(Volume Up) 버튼을 누르는 것을 선택할 수 있다. UPnP^TM 동작요청(Action Request) 이 콘트롤 포인트(Control Point)에 전송된 다음 유일 장치며(Unique Derice Name :UDN)에 의해 식별된 직렬장치 어플리케이션(Application)으로 향한다.

직렬 장치 어댑터내의 직렬 장치 어플리케이션은 UPnP^TM 동작 요청을 수신하여 직렬 명령으로 번역하는데, 번역은 사용자 생성 직렬 프로토콜 정의 파일(Serial Device PD.wml)의 메모리내 표현으로부터 적절한 데이터를 검색함으로써 이루어진다. 직렬 명령은 그런 다음 자이가 연결되고 구성되어진 직렬 포트로 향한다. 직렬 장치는 직렬 명령을 수신하여 요청된 동작을 실행한다. 만약 직렬 장치가 직렬 장치 어플리케이션에 응답을 보내면, 적절한 UPnP^TM 동작 요청이 발생되어 사용자 인터페이스 화면으로 재차 향해지도록 콘트롤 포인트로 역전송된다.

직렬 장치는 UPnP^TM 동작 요청과는 독자적인 응답을 전송할 수 있다. 예를 들면, 사용자는 장치를 직접적으로 작동할 수 있으며, 따라서 직렬 장치 어플리케이션에 전송될 응답을 유발할 수 있다. 통지 청취기(Notifcation Listener)는 직렬 응답 명령을 포착하여, 만약 직렬 프로토콜 정의가 관련되어 발생된 변수 엔트 리(Veriable entry)를 포함하면 UPnP^TM 통지를 콘트롤 포인트에 전송한다.

직렬 프로토콜 정의는 다음을 포함할 수 있다:

● 직렬 형태: 사용될 통신 프로토콜을 정의한다.

가능한 값: RS232, RS485 또는 RS422.

● 보드율(Baud Rate): 하드웨어 속도를 정의한다.

가능한 값:300, 600, 1200, 1800, 2400, 3600, 4800, 7200, 9600, 14400, 19200, 28800, 38400, 57600, 115200.

● 스톱 비트(Stop Bits): 캐릭터 프레임(character Frame)의 마지막 부분. 가능한 값:1,2.

● 패리티(Parity): 캐릭터 프레임에서 데이터 비트 뒤를 따르는 선택 패리티 비트.

가능한 값: 영, 홀수, 짝수.

● 데이터 비드: 바이트 형태의 데이터 비트의 수. 가능한 값:5,6,7,8.

● 데스크(Desc): 장치 설명(Device Description).

● 흐름제어(Flow Control): 데이터 전송 흐름 제어.

가능한 값: 영, Xon-xoff, 하드웨어.

● 캐리지 반송(Carrige Return): (선택적) 만약 장치가 데이터 전송의 마지막에 CR을 요구하는 경우. 가능한 값: 예(Yes), 아니오(No)(디폴트:Default).

● 포괄적 지연(Global delay): (선택적)전송 중의 1/1000초 단위의 지연시 간.

몇몇 장치들은 출력 버퍼에 쓰기가 불가능한 값이나 캐릭터를 사용한다. 선택적인 변환표(Trans Table)가 제공되어 금지 값과 이의 대응 변환 값 사이의 변환을 다룰 수 있다. 이 태크(tag)는 변환이 필요 없으면 비어 있게(empty) 된다.

그렇지 않으면, 사용자는 각 값에 대해 다음 다섯 태크를 특정해야 한다: 값(Value), 값 형태(Value Type), 인(In), 아웃(Out), 플레이스(Place).

● 값: 이 태크는 금지 값을 나타낸다.

● 값 형태: 수신(또는 송신) 값의 형태를 특정한다.

가능한 값: numhex, numdec, 스트링(string).

● In: 금지 값 그 자체.

● Out: 변환 값.

● 플레이스: 변환을 위해 입력/출력 버퍼 중 어느 것이 점검되어야 하는가. 가능한 값은 다음을 포함함:

A - 시작 및 종료(Start, End)스트링을 제외한 전체 버퍼.

ES - 종료 스트링을 포함한다.

SS - 시작 스트링을 포함한다.

직렬 통신 형태/방법을 정의하는 프로토콜은 다음을 포함할 수 있다:

● 형태(Type): 프로토콜의 통신 형태: 가능한 값:텍스트(text), 헥스(hex).

● 시작 스트링: (선태적)이 스트링은 모든 출력 버퍼의 시작에 붙게 되며 임의의 입력 버퍼의 초기에 제거된다. 사용자는 시작 스트링의 바이트 크기 뿐 만아니라 데이터 형태의 속성을 또한 특정할 수 있는데,

예는:

＜StartString Vaule Type="numhex"ByteSize="2"＞0202＜/StartString＞.

값 형태로서 가능한 것: numhex, numdec 과 스트링.디폴트는 스트링이다.

● 종료 스트링: (선택적) 이 스트링은 모든 출력 버퍼의 끝에 붙게 되며 임의의 입력 버퍼의 끝에서 제거된다. 사용자는 종료 스트링의 바이트 크기 뿐 만 아니라 데이터 유형 속성을 또한 특정할 수 있는데, 가능한 값은 :numhex, numdec 과 스트링(디폴트).

● 연속(Sequence): 몇몇 직렬 장치는 명령이 전송되기 전후에 각기 세션(session)이 개방되고 폐쇄될 것을 필요로 한다. 이 부분은 시작연속과 종료연속을 기술한다. 값 형태는 프로토콜 형태로부터 추출된다.

● 시작연속(Start Sequence):(선택적)

요청: (선택적): 세션을 개방하는 스트링.

응답: (선택적): 시작 연속에 대한 예상 응답.

● 종료연속(End Seqence): (선택적)

요청: (선택적):세션을 폐쇄하는 스트링.

응답: (선택적): 종료 연속 요청에 대한 예상 응답.

● 검사합(Cheek Sum):(선태적) 몇몇 직렬 장치는 출력 버퍼에 검사합 필드를 요구한다.

이 부분은 이 필드를 기술하는 바 다음과 같은 사항을 기술한다.: 구조화 방법, 필드의 바이트 크기 및 위차할 장소. 가능한 값:SS, A, ES, SIZE. 사용자가 검사합을 실현하면, 모든 필드가 의무적이게 된다.

SS - 검사합 계산에서 시작 스트링을 포함한다.

A - 검사합 계산에서 버퍼의 데이터 부분을 포함한다.

ES - 검사합 계산에서 종료 스트링을 포함한다.

SIZE - 검사합 계산에서 전 출력 버퍼의 크기를 포함한다.

최종(Last) - 검사합은 버퍼의 끝에 위치하게 된다.

BL - 검사합은 종료 스트링 전에 위치하게 된다.

아무것도 없으면 끝에 위치하게 된다.

플레이스(Place): 검사합 필드의 위치. 가능한 값: Last, BL(Last 전).

바이트 크기: 검사합 필드의 바이트 크기의 길이.

UPnP^TM 장치는 요청될 수 있는 하나 이상의 동작을 지원한다. 바람직하게는 UPnP^TM 직렬장치에 의해 지원되는 모든 동작, 이의 논증(arquments) 및 명령의 형식을 포함하는 동작표가 제공된다. 임의의 입력 파라미터가 바람직하게는 관련 상태 변수와 결합된다. 명령에 파라미터가 없으면(이것은 명령이 단순 스트링이라는 것을 암시한다), 어떤 관련 상태 변수도 특정될 필요가 없다.

● 이름(Name): 동작의 이름.

● 지연(Delay): (선택적) 명령을 송신한 후 기다려야 하는 일천분지 일초 단위의 수. 만약 이 파라미터가 특정되면, 이것은 포괄적 지연 파라미터를 무시한다. 그렇기 않으면, 포괄적 지연 파라미터가 모든 명령에 대해 지연을 결정한다.

● 연속(Seq): 이 필드는 명령을 전송하기 위해 세션이 개방되어야 하는지 그리고 그 후에 폐쇄되어야 하는지 정의한다.

● 요청(Request): 요청된 동작 출력 버퍼의 형식을 기술한다.

● 응답(Reply): (선택적) 응답 동작 입력 버퍼의 형식을 기술한다.

● 논증목록(argument List): 논증표는 몇 가지 논증을 포함하는데 각각의 논증은 다음 필드를 포함한다.

○ 이름: 논증의 이름

○ 방향(direction): 출력 버퍼의 논증 부분이거나(이는 실제 장치에 전송될 명령의 부분을 의미한다) 또는 응답 버퍼의 부분임(이는 실제 장치로부터 얻게 될 응답 부분을 의미한다).

값:in, out

○ 관련상태 변수(related State Variable): 논증 각각은 하나의 관련상태 변수와 결합 되어야 한다. 여기서, 본 발명자는 관련 상태 변수의 이름을 특정한다.

바람직하게는 서비스 상태표(service stste table)이 제공되어 직렬 장치 내에서 발생하는 변화에 대한 통지 메세지를 전송하기 위해 사용된다. 따라서, 전송사진(send Events) 속성이 설정되어야 하며 다음 필드들이 각 관련 상태 변수에 대해 제공되어야 한다: 이름, 데이터 유형, 갑 형태, 및 허용 값 범위/허용값표

● 전송사건: 변수의 값이 변한 경우 통지가 전송되어야 하는지를 특정한다. 가능한 값: 예, 아니오.

● 이름: 변수의 이름

● 데이터 유형: 변환된 데이터 유형. 가능한 값: 스트링, numhexm numdec.

● 값 형태: 직렬 장치로부터 수신된 실제 데이터 유형. 가능한 값: numhex, numdec 및 스트링.

● 허용 값 범위/허용값 목록(allowed Value Range/allowed Value List): 이 태크는 이 변수에 대한 허용 값을 특정하는데, 이는 몇 가지 값의 범위이거나 몇가지 값에 제한될 수 있다.

a)PT 값: (선택적)

이 속성은 직렬 장치가 수신하고 반송되어야 할 실제 값을 정의한다. 이 속성은 존재하지 않으면, 변환도 일어나지 않는다.

b)허용 값 범위: 이 요소는 사용자 특정 최소 및 최대 허용 값을 정의한다. 아래 예에서, 관련 상태 변수는 +30의 최대값과 -30의 최소값을 지원한다. 그러나, 실제 전송 및 반송 값은 0×62 및 0×9E 이다. 그러므로, UPnP 직렬 장치는 양방향으로 변환을 일어켜야 한다. 예로:

＜허용 값 범위＞

＜최소 PT 값 = "62"＞ - 30＜/최소＞

＜최소 PT 값 = "9E"＞ + 30＜/최EO＞

＜/허용 값 범위＞

c)허용 값 목록: 이 요소는 모든 허용 값에 대한 사용자 특정 목록을 정의한다. 아래 예에서, 관련 상태 변수의 지원 값은 0, 1, 2, 4, 6, 8 인데 이는 태크의 값에 따라 양방향으로 변환된다. 예를 들면;

＜허용 값 목록＞

＜허용 값 PT 값 = "0"＞NTSC＜/허용 값＞

＜허용 값 PT 값 = "1"＞PAL60＜/허용 값＞

＜허용 값 PT 값 = "2"＞4.43NTSC＜/허용 값＞

＜허용 값 PT 값 = "4"＞PAL＜/허용 값＞

＜허용 값 PT 값 = "6"＞SECAM＜/허용 값＞

＜허용 값 PT 값 = "8"＞Auto＜/허용 값＞

＜/허용 값 목록＞

도 13에서 서브시스템(Subsystem) 장치가 도시되어 있는데 UPnP^TM 네트워크와 직렬 장치 인터페이스와 유사한 방법으로 하드웨어 내에 콘트롤오에스(Control OS)로 구형되는 직렬 전송 사이에서 브리지(bridge)로서 동작한다. 바람직하게는 표준 또는 개인적으로 관리되는 프로토콜을 사용하는 하부 응용기기(subappliances)를 일반적으로 관리하고 제어하는 가볍거나(lighting) 또는 HVAC 시스템과 같은 제3자 하부시스템을 통합할 수 있도록 설계된다. 본 발명에서, UPnP^TM 직렬 장치와 UPnP^TM 하부시스템 간의 주요 차이점은 서브 시스템내의 하부 응용기기들의 관리와 제어에 반영된다. 비록 하부시스템은 수 많은 하부 응용기기들을 관리하고 제어하지만, 오직 한 가지 경우의 하부시스템 직렬 장치가 물리적 하부시스템마다 존재하며, 하부 응용기기 유형마다 한 가지 경우의 서비스 설명을 포함한다(즉, 키패드, 스위치, 조광기,(dimmer), 모터 등). 각 서비스 설명 파일은 각 하부 응용기기에 할당된 하나의 사건화 변수(evented-variable)를 유지한다. 하부시스템 직렬 장치로부터 물리적 하부 응용기기에로의 통신은 그러므로 하부시스템이 이의 하부 응용기기를 제어하도록 요청함으로써 실행된다.

이제 도 14를 참조하면, 본 발명의 바람직한 실시 예에 따라 구성되고 동작되는 미디어 서버(medir server) 구조에 대 한 단순화된 블록도이다.

도 14에서 본 발명의 UPnP^TM 미디어 서버는 바람직하게는 UPnP^TM 미디어 서버 장치 탬플릿에 기반하고 있는데, 이는 미디어 서버 각각의 구현은 콘텐트(Content) 디렉토리와 연결 관리자(Connection Manager) 서비스를 포함할 것을 요구한다. 콘텐트 디렉토리 서비스는 콘트롤 포인트로 하여금 장치로부터 이용할 수 있는 AV 콘텐트에 대한 정보를 찾도록 한다. 연결 관리자는 콘텐트를 전송하기 위해 사용될 특별 전송 프로토콜 및 데이터 형식을 선택하기 위해 사용된다. AV 운송(Transport) 서비스의 존재 여부는 장치에 의해 지원되는 전송 프로토콜에 달려 있다.

UPnP^TM 미디어 서버 장치는 하나 이상의 미디어 렌더러(Renderer) 장치와 함께 사용되어 콘트롤 포인트로 하여금 미디어 서버에서 연예(AV) 콘텐트(예로, 비디 오, 음악, 영상 등)을 찾도록 하며 또한 이 콘텐트를 홈 네트워크 내에서 임의의 적절한 미디어 렌더러에서 실행되도록 한다. 콘트롤 포인트는 원하는 콘텐트(예, 영화, 노래, 플레이 목록, 사진앨범 등) 등을 찾아내기 위해 미디어 서버와 같이 상호 작용한다. 콘텐트 식별된 후에는, 콘트롤 포인트는 미디어 서버로부터 원하는 미디어 런더러로 콘텐트를 전송하기 위해 사용될 수 있는 공통 전송 프로토콜과 데이터 형식을 식별할 필요가 있다. 이 같은 전송 파라미터들이 설정된 후에는, 콘트롤 포인트는 콘텐트의 흐름(예, 재생:Play, 휴지:Pause, 정지:Stop, 탐색:Seek, 등)을 제어한다. 선택된 전송 프로토콜에 따라, 이 같은 흐름 제어 동작은 바람직하게는 미디어 서버나 미디어 렌더러 어느 하나에 전송되며 양쪽에 모두 전송되지 않는다. 실제 콘텐트 전송은 UPnP 이외의 전송 프로토콜을 사용하여 미디어 서버와 미디어 렌더러에 의해 직접 실행된다.

미이어 서버는 바람직하게는 Wendow^TM 서비스로서 실현되며 다음 구성 성분과 기능을 포함한다:

● HTTP 포스트(Post) API: 미디어 데이터베이스를 유지하고 이로부터 데이터를 검색하기 위해 데이터베이스 레이어(Layer)와 상호 작용하는 미디어 관리 GUI를 위한 인터페이스. 이 인터페이스는 가상 디렉토리, 플레이 목록, 및 UPnP^TM

브라우즈와 서치(Search) 동작을 통한 미디어 파일의 관리와 이에 대한 액세스를 제공한다.

● 데이터 레이어 API:슬레이트(Slate) 데이터베이스에 반대로 작동되는 SQL 질의(Query) 인터페이스를 제공한다.

●SQLite 개방소스(Open Source) 데이터베이스:

홈 네트워크에 이용할 수 있는 모든 미디어 파일에 관한 정보와 함께 미디어 서버 데이터베이스에 관한 메다 데이터(meta-data)를 갖는 표들을 포함한다. 미디어 서버 데이터베이스는 미디어 파일에 관한 다음 정보를 유지한다: 파일 ID, 전경로(Full), 가상 디렉토리, 제목, 생성자: Creator, 예술가;Artist, 앨범, 장르:Genre, 주석:Comments, 저작권, 형식, 트랙번호:Track Number, 년도, 비트 율,시간 길이, 크기, 형태, 부모:Parented, 자식 카운트;Child Count, 주파수.

● 파일 시스템 변화통지: 데이터베이스를 최신으로 유지하고 사건화 변수들을 통해 미디어 콘트롤러/매니저에 대한 "변화정부"에의 액세스 제공하기 위해 파일 시스템 변화에 대한 실시산 모니터링(가상 디렉토리를 통한 사상(mapped).

● 구성(Configuration) 파일:디폴트 시스템 가상 디렉토리, 지원되는 미디어 형태와 사용될 전송 프로토콜과 아울러 로킹(logging)과 네트워킹 세팅에 관한 데이터를 포함한다.

● 디렉토리 로드(Load) 관리 API

● 가상 디렉토리 API

● 미디어 스캔 메커니증

본 발명의 UPnP^TM 미디어 렌더러는 바람직하게는 리눅스 플랫폼(Linux Platform)에서 동작하는UPnP^TM 미디어 렌더러 장치 탬플릿에 기반한다.

네트워크상에서 다른 장치들을 찾아내고 제어할 수 있는 콘트롤러인 UPnP^TM 콘트롤 포인트가 제공된다. 찾아내 후에는, 콘트롤 포인트는 장치 설명과 장치의 서비스를 검색하여 서비스를 제어하기 위한 동작을 일으키며, 그리고 서비스의 사건원(event source)에 기록한다. 서비스의 상태가 변화면 언제든 사건 서버는 사건을 콘트롤 포인트로 전송하게 된다. 상세 명세는 UPnP^TM 포럼(forum)에 의해 정의되고 관리되며 UPnP^TM 장치 구조서류에 기술된다.

콘트롤 포인트는 바람직하게는 Intel^TM UPnP^TM SDK 상에서 운영되는, 그리고Linux, Window^TM과 WinCE^TM 하에서 Window^TM 서비스 및/ 또는 Linuux 대몬(daemon) 으로서 운영되는 교차(cross) 플랫폼 코드이다.

콘트롤 포인트 구성파일은 바람직하게는 /INSTALL - AIR/Server Root 에서 Window^TM상에 위치되는 Control Point Config.xml 구성 파일로 부터 적재되며, 그리고 리눅스에서는 /etc/upnp/Server Root/Control Point Config.xml에서 적재된다. 이 구성 파일을 사용하여, 콘트롤 포인트의 네트위킹 파라미터, 장치 서치 유형, 및 로깅 수준이 구성될 수 있으며, UPnP^TM 장치와 서비스가 여과될 수 있다.

콘트롤 포인트와 상호 작용하는 응용 장치(applications)에 대해서는 두개의 인터페이스가 있다.

1. 명령 - 클라이언트(Clients)는 콘트롤 포인트에 UPnP^TM 동작 전송, 변소 상태 획득, 등과 같은 상이한 명령들을 HTTP POET를 거쳐 내장 웹 서버에 전송할 수 있다.

2. 통지 - 응용장치는 UPnP^TM 사건, 새로운 장치들, 및 제거된 장치들에 대한 사건 통지를 수신하도록 등록할 수 있다. 콘트롤 포인트는 TCP/IP 네트웨크 위에 클라이언트의 소켓(sockets) 연결을 허용하는 통지 서버를 가지고 있다. 새로운 클라이언트가 연결되어 소켓을 개방하면(이것은 전체 세션 동안 활성화되어 있다), 서버는 이를 사건에 대한 구독자(subscriber)로서 등록한다. 콘트롤 포인트가(상태가 변화 또는 사건화 변수들의 값의 변화의 결과로서) 사건을 전송하면, 통지 서버는 모든 클라이언트의 개방 소켓에 대해 이것을 전송한다.

명령 인터페이스가 제공되어 포스트(post) 명령을 거쳐 콘트롤 포인트 http 서버에 액세스할 수 있는데, 이는 구성 파일＜uiHttp Port＞에서 특정되는 포트(port) 번호를 갖는 로우컬 호스트(local host)이다.

1. 획득목록(Get List): 네트워크상에서 이용할 수 있는 장치들의 목록을 검색한다. 형태(Type) 또는 UDN에 의해 여과하기 위한 파라미터들이 제공된다.

2. Upnp 동작: 특정 장치에 임의의 UPnP^TM 동작을 전송.

3. Get Service Desc Doc:특정 UDN과 서비스 ID에 대해 서비스 설명 서류를 검색.

4. Get Var: 특정 UDN과 서비스 ID에 대해 변수를 획득.

5. Get Ur: UDN에 대한 URI 획득.

6. Register Evented Var: 통지를 받고 싶어하는 특정 사건 변수에 대한 등록. 디폴트 셋팅은 모든 통지를 전송.

7. UnRegister Evented Var: 통지가 선택되어진 사건 변수를 등록해제.

8. Get Uri Map: 더욱 상세한 UDN ur 사상

9. Register Local Udn: 시사(preview) 기능에 대한 UDN에 대해 국지적 Uri 등록.

10. UnRegister Local Udn: 시사 기능에 대한 UDN에 대해 국지적 Uri 등록해제.

통지는 바람직하게는 TCP 포트를 통해 로우컬 호스트에 제공되며, 포트 번호는 구성 파일＜cpNotification＞에 특정된다.

이용가능한 통지는 다음을 포함한다.

1. 부가 - 장치(Add - device)

콘트롤 포인트가 신규 UPnP^TM 장치가 UPnP^TM 네트워크에 추가되었다는 통지를 받으면, 이것은 모든 구독자에게 통지를 전송하게 된다.

2. 제거 - 장치(Remove - device)

UPnP^TM 장치가 이것이 막 UPnP^TM 네트워크를 벗어나려고 한다는 통지 메세지를 전송하면, 콘트롤 포인트는 모든 구독자에게 UPnP^TM 장치를 그들(구독자들)의 목록에서 제거하라고 통지하게 된다.

3. 변수 - 변화됨(Variable - changed)

콘트롤 포인트가 사건화 변수 변화 통지를 수신하면, 이것은 변수와 이것의 새로운 값을 모든 구독자에게 전송하게 된다.

바람직하게는 IR 학습(Learning) 응용기기가 제공되는데, 이는 학습될 신규 원격제어 구성들과 편집될 기존 원격 제어 구성들을 모두 허용한다. 바람직하게는 응용기기는 시스템의 원격제어 데이터베이스를 확장할 수 있도록 신속히 IR을 획득하여 정당화하는 마법사(wizard)를 포함한다. 원격제어의 학습/편집 프로세스는 콘트롤 박스에 내장된 IR 수신기/송신기에 의해 처리된다.

위에서 기술된 XML 기반 직렬 어댑터는 마법사 기반 직렬 어댑터 생성기를 사용하여 생성될 수 있는데, 여기서 특정 장치에 관한 모든 요구되는 정보는 제조자 공급 사용자 매뉴얼 또는 직렬 트로토콜 정의 서류로부터 추출될 수 있다. 그런다음 발생된 드라이버는 시스템 장치 데이터베이스에 부가될 수 있다. 직렬 장치 템플릿의 일반적 설계는 최종 사용자로 하여금 쉽게 장치 특정 인터페이스를 생성하여 홈 자동화 시스템에 통합할 수 있는 비(non)- UPnP^TM 활성 장치를 활성화할 수 있도록 해준다.

이해할 것은 명료성을 위해 개별 실시 예의 맥락에서 기술된 본 발명의 다양한 특징들은 또한 하나의 실시 예로 결합되어 제공될 수 있다는 것이다. 반대로, 간결성을 위해 하나의 실시 예의 맥락에서 기술된 본 발명의 다양한 특징들은 개별적으로 또는 임의의 적절한 서브콤비네이션(subcombination)으로 또한 제공될 수 있다.

또한 이해할 것은 여기서 기술된 방법들 중 어떤 방법의 하나 이상의 단계가 생략될 수 있거나 도시된 것과는 다른 순서로 실행될 수 있으며, 이러한 것은 본 발명의 진정한 정신이나 범위를 벗어나지 않는 것이다.

여기서 개시된 방법과 장치는 특징 컴퓨터 하드웨어나 소프트웨어를 참조하여 기술되어 졌으나, 여기서 기술된 방법과 장치는 종래 기술을 사용하여 컴퓨터 하드웨어나 소프트웨어로 쉽게 구현될 수 있다는 것을 이해해야 한다.

본 발명은 하나 이상의 특정 실시 예를 참조하여 기술되어 졌으나, 이러한 기술은 전체로서 본 발명의 예시로서 의도된 것이며 보여진 실시 예에 본 발명을 한정하는 것으로 해석되어서는 않된다.

당해 기술 분야에서 숙련된 자에게는 다양한 변형이 가능하며, 한편 여기에 상세히 보여주지는 않았지만 이러한 변형은 본 발명의 진정한 정신과 범위 내에 있게 된다는 것을 이해해야 한다.

Claims

자동 장치 찾기 및 제어의 프로토콜을 구현하도록 동작하는 다수의 네트워크된 장치 콘트롤러;

이 콘트롤러 중 임의의 것에 연결되며 상기 콘트롤러에 연결되기 전에 상기 프로토콜과 같이 사용하도록 구성되지 않은 적어도 하나의 비-프로토콜-순종장치; 및

인터페이스 및 상기 장치들 중 임의의 것과 결합 된 제어요소 중 어떤 것을 발생시키도록 동작하며,

상기 프로토콜과 같이 사용하도록 구성되며 상기 비-프로토콜-순종 장치를 제어하도록 동작하는 프록시를 설정하도록 동작하며, 그리고

상기 인터페이스와 상기 콘트롤러에 연결된 상기 장치에 대해 발생된 상기 제어 요소를 갖는 상기 콘트롤러들 중 임의의 것을 구성하도록 동작하는, 관리 유닛;

을 포함하는 네트워크 된 장치 제어 시스템.
제1항에 있어서,

상기 관리 유닛은 상기 비-프로토콜-순종 장치가 상기 프록시로서 작용하도록 첨부되는 상기 콘트롤러들 중 임의의 것을 구성하도록 동작하는 시스템.
제1항에 있어서,

상기 프록시는;

프로토콜-순종 명령을 상기 비-프로토콜-순종 장치를 제어하기 위한 명령으로 번역하도록 동작하며; 및

상기 번역된 명령을 상기 비-프로토콜-순종 장치에 전송하도록 동작하는;

시스템.
제1항에 있어서,

상기 프로토콜은 UPnP^TM 프로토콜인 시스템,
자동 장치 찾기 및 제어의 프로토콜을 구현하도록 동작하는 다수의 네트워크된 장치 콘트롤러;

이 콘트롤러들 중 임의의 것에 연결되며 상기 콘트롤러에 연결되기 전에 상기 프로토콜과 같이 사용하도록 구성된 적어도 하나의 프로토콜-순종 장치;

상기 콘트롤러들 중 임의의 것에 연결되며 상기 콘트롤러에 연결되기 전에 상기 프로토콜과 같이 사용하도록 구성되지 않은 적어도 하나의 비-프로토콜-순종 장치; 및

인터페이스 및 상기 장치들 중 임의의 것과 결합된 제어 요소 중 어떤 것을 발생시키도록 동작하며,

상기 프로토콜과 같이 사용하도록 구성되며 상기 비-프로토콜-순종 장치를 제어하도록 동작하는 프록시를 설정하도록 동작하며,그리고

상기 인터페이스 및 상기 콘트롤러에 연결된 상기 장치에 대해 발생된 상기 제어 요소를 갖는 상기 콘트롤러들 중 임의의 것을 구성하도록 동작하는,

관리 유닛;

을 포함하는 네트워크 된 장치 제어 시스템.
제5항에 있어서,

상기 관리 유닛은 상기 비-프로토콜-순종 장치가 상기 프록시로서 작용하도록 첨부되는 상기 콘트롤러들 중 임의의 것을 구성하도록 동작하는 시스템.
제5항에 있어서,

상기 프록시는;

프로토콜-순종 명령을 상기 비-프로토콜-순종 장치를 제어하기 위한 명령으로 번역하도록 동작하며; 및

상기 번역된 명령을 상기 바-프로토콜-순종 명령 장치에 전송하도록 동작하는;

시스템.
제5항에 있어서,

상기 프로토콜은 UPnP^TM 프로토콜인 시스템.
자동 장치 찾기 및 제어의 프로토콜을 구현하도록 동작하는 다수의 네트워크된 장치 콘트롤러를 배치하는 단계;

상기 콘트롤로 중 임의의 것에 적어도 하나의 비-프로토콜-순종 장치를 연결하는 단계로서, 상기 콘트롤러에 연결되기 전에 상기 프로토콜과 같이 사용하도록 구성되지 않으며;

인터페이스 및 상기 장치들 중 임의의 것과 결합 된 제어요소 중 어떤 것을 발생시키는 단계;

상기 프로토콜과 같이 사용하도록 구성되며 상기 비-프로토콜-순종 장치를 제어하도록 동작하는 프록시를 설정하는 단계; 및

상기 인터페이스를 갖는 상기 콘트롤러들 및 상기 콘트롤러에 연결된 상기 장치에 대해 발생된 상기 제어 요소 중 어떤 것을 구성하는 단계;

를 포함하는 네트워크 된 장치를 제어를 위한 방법.
제9항에 있어서,

상기 비-프로토콜-순종 장치가 상기 프록시로서 작용하도록 첨부되는 상기 콘트롤러들 중 임의의 것을 구성하는 단계를 더 포함하는 방법.
제9항에 있어서,

상기 발생 단계는;

명령 집합, 통신 프로토콜, 및 인터페이스를 포함하는 비-프로토콜-순종 장치 유형을 정의하는 단계; 및

상기 정의로부터 상기 프록시를 발생시키는 단계;

를 포함하는 방법.
제9항에 있어서,

프로토콜-순종 명령을 상기 비-프로토콜-순종 장치를 제어하기 위한 명령으로 번역하는 단계; 및

상기 번역된 명령을 상기 비-프로토콜-순종 장치로 전송하는 단계;

를 더 포함하는 방법.
자동 장치 찾기 및 제어의 프로토콜을 구현하도록 동작하는 다수의 네트워크된 장치 콘트롤러를 배치하는 단계;

상기 콘트롤러들 중 임의의 것에 적어도 하나의 프로토콜-순종 장치를 연결하는 단계로서, 상기 콘트롤러에 연결되기 전에 상기 프로토콜과 같이 사용하도록 구성되며;

상기 콘트롤러들 중 임의의 것에 적어도 하나의 비-프로토콜-순종 장치를 연결하는 단계로서, 상기 콘트롤러에 연결되기 전에 상기 프로토콜과 같이 사용하도 록 연결되지 않으며;

인터페이스 및 상기 장치들 중 임의의 것과 결합 된 제어 요소 중 어떤 것을 발생시키는 단계;

상기 프로토콜과 같이 사용하도록 구성되며 상기 비-프로토콜-순종 장치를 제어하도록 동작하는 프록시를 설정하는 단계; 및

상기 인터페이스를 갖는 상기 콘트롤러들 및 상기 콘트롤러에 연결된 상기 장치에 대해 발생 된 제어 요소를 중 어떤 것을 구성하는 단계;

를 포함하는 네트워크 된 장치 제어를 위한 방법.
제13항에 있어서,

상기 비-프로토콜-순종 장치가 상기 프록시로서 작용하도록 첨부되는 상기 콘트롤러들 중 임의의 것을 구성하는 단계를 더 포함하는 방법.
제13항에 있어서,

상기 발생단계는;

명령 집합, 통신 프로토콜, 및 인터페이스를 포함하는 비-프로토콜-순종 장치 유형을 정의하는 단계; 및

상기 정의로부터 상기 프록시를 발생시키는 단계;

를 포함하는 방법.
제13항에 있어서,

프로토콜-순종 명령을 상기 비-프로토콜-순종 장치를 제어하기 위한 명령으로 번역하는 단계; 및

상기 번역된 명령을 상기 비-프로토콜-순종 장치로 전송하는 단계;

를 더 포함하는 방법.
UPnP^TM 명령을 비-UPnP^TM-순종 장치로 통신하기 위한 방법으로서, 다음을 포함하는 방법;

비-UPnP^TM-순종 장치의 제어 명세를 적어도 하나의 비-UPnP^TM 명령과 적어도 하나의 UPnP^TM 명령 사이의 맵핑(mapping)으로 변환하는 단계;

UPnP^TM 명령을 수신하고 대응하는 명령을 상기 비-UPnP^TM-순종 장치에 출력하도록 한가지 경우의 UPnP^TM 생성하는 단계;

상기 맵핑에서 UPnP^TM 명령을 찾아내는 단계; 및

상기 비- UPnP^TM -순종 장치 명령에 대응하는 명령을 전송하는 단계.
제17항에 있어서,

상기 제어 명세는 직력,IR, 릴레이,I/O, 또는 USB 장치 중 임의의 것인 방법.
제17항에 있어서,

상기 변환 단계는 xml-기반 형식으로 변환하는 단계를 포함하는 방법.
제17항에 있어서,

상기 비- UPnP^TM -순종 장치로부터 명령을 수신하는 단계;

상기 수신된 명령에 대응하여 상기 맵핑에서 UPnP^TM 명령을 찾는 단계; 및

상기 UPnP^TM 명령을 UPnP^TM 콘트롤러에 전송하는 단계;

를 더 포함하는 방법.
제17항에 있어서,

상기 생성단계는 다수의 하부 응용기기가 연결되는 하부시스템에 대해 상기 UPnP^TM장치를 생성하는 단계를 포함하며, 상기 UPnP^TM 장치는 각각의 하부 응용기기 유형에 대해 하나의 UPnP^TM 서비스를 가지며, 그리고 상기 UPnP^TM 서비스들 각각은 상기 하부 응용기기들 각각에 대해 개별 준거를 가지는 방법.
제21항에 있어서,

UPnP^TM 명령을 명령으로 번역하는 단계;

상기 명령을 이 명령이 지향되는 상기 하부 응용기기들 중 임의의 것의 식별기와 함께 상기 하부시스템에 전송하는 단계;

를 더 포함하는 방법.
제17항에 있어서.

인터페이스 요소를 상기 명령들 중 임의의 것에 자동으로 할당하는 단계; 및

상기 인터페이스 요소가 활성화되면, 상기 인터페이스와 결합된 상기 명령에 대해 상기 찾기 및 전송 단계들을 실행하는 단계;

를 더 포함하는 방법.