KR100647449B1

KR100647449B1 - 특성 루트를 통해서 소프트웨어 오브젝트들을 제어하기위한 시나리오를 식별하는 호출

Info

Publication number: KR100647449B1
Application number: KR1020007006040A
Authority: KR
Inventors: 시터엔예브게니.이
Original assignee: 코닌클리케 필립스 일렉트로닉스 엔.브이.
Priority date: 1998-10-02
Filing date: 1999-09-30
Publication date: 2006-11-23
Anticipated expiration: 2019-09-30
Also published as: US6918123B1; DE69930534D1; WO2000020965A1; EP1046101A1; CN1126032C; KR20010032749A; DE69930534T2; ATE321299T1; EP1046101B1; ES2260938T3; CN1289418A; JP2002526857A

Abstract

정보 처리 시스템은 제 1 및 제 2 소프트웨어 오브젝트들에 의해 표현되는 제 1 및 제 2 물리 컴포넌트들을 갖는다. 두 오브젝트들은 오브젝트들로의 호출들을 통해서 변경가능한 특성들을 갖는다. 시스템은 제 1 특성에서의 변화가 특성 루트를 호출할 때에 제 2 호출을 제 2 오브젝트에 발행시킬 수 있도록 제 1 오브젝트의 제 1 특성을 제 2 오브젝트의 제 2 특성과 연결시키는 특성 루트를 등록할 수 있게 한다. 제 1 오브젝트로의 입력 호출은 루트를 조건부로 호출할 수 있도록 하는 식별자를 포함한다. 이 방식으로, 다른 시나리오들에 속하는 루트들은 독립적으로 유지되어 시스템이 시나리오 식별자들을 갖지 않고도 더욱 신뢰할 수 있게 동작하게 된다.

시나리오, 루트, 특성, 오브젝트, 식별자

Description

특성 루트를 통해서 소프트웨어 오브젝트들을 제어하기 위한 시나리오를 식별하는 호출{Calls identify scenario for control of software objects via property routes}

발명의 배경

본 발명은 정보 처리 시스템, 특히, 배타적이지 않지만 가정 또는 사무 환경에서 가전 제품을 제어하는 방법에 관한 것이다.

배경 기술

마이크로소프트사의 컴포넌트 오브젝트 모델(Component Object Model :COM)기술에 기초하는 클라이언트-서버 모델을 고려하자. 보다 많은 정보에 대해서는, 예를 들어 본원에 참조로 포함되는 마이크로소프트사에 의해 공급되는 1995년 10월의 컴포넌트 오브젝트 모델 사양 버전 0.9를 참조하자. COM은 객체 지향(object-oriented)이다. 오브젝트는 소프트웨어 애플리케이션(software application)에 공개된 바와 같이 관련된 전자 장치의 제어 기능들(control functionalities)을 표현하는 특성들을 갖는다. 외부로부터의 이벤트의 결과로서의 오브젝트의 상태 변화는 소프트웨어 애플리케이션에게 전달된다. 애플리케이션은 이들의 특성들을 변화시키거나 설정함으로써 오브젝트들을 처리한다. 애플리케이션이 어떤 물리적 장치와 관련되는 오브젝트의 특성을 수정할 때, 관련된 장치에 명령이 전송된다.

COM은 애플리케이션들이 일관된 방식으로 통신하도록 하는 일반적인 매카니즘이며, 프로그램 컴포넌트 오브젝트들을 개발하고 지원하는 프레임워크이다. 이는 네트워크내의 분산 오브젝트들의 상호운용(interoperation)을 위한 프레임워크인 CORBA(Common Object Request Broker Architecture)에 규정된 능력들과 유사한 능력들을 제공한다. OLE(object linking and embedding)은 사용자들이 자신들의 디스플레이상에서 보는 복합 문서(compound document)를 위한 서비스들을 제공하며, COM은 인터페이스 니고시에이션(interface negotiation)의 기초가 되는 서비스들(underlying services) 및 이벤트 서비스들(event services)을 제공한다(또 다른 오브젝트에 생긴 이벤트의 결과로서 하나의 오브젝트를 서비스에 넣는다). 이 구현에서, 클라이언트들은 제어를 공개하기 위해 특성들을 사용하며 상태 변화들을 알리기 위해 이벤트들을 사용하는 OLE 자동화 오브젝트들(추상적인 표현(abstract representations))로서 모델링된다. OLE 자동화는 서버에 대한 클라이언트의 스크립팅(scripting) 및 동적 바인딩(late binding)을 가능하게 하는 COM 기술이다. OLE 자동화는 프로그램들이 외부 이용을 가능하게 하는 특징들(명령들 및 질문들)에 대한 호출들을 통해서 다른 프로그램들과의 통신을 제공한다. 오브젝트를 사용하기 전에, 클라이언트 애플리케이션은 우선 오브젝트의 인터페이스 포인터를 획득해야만 한다. 인터페이스 포인터는 오브젝트명을 결합함으로써 또는 장치들을 열거함으로써 네트워크의 디렉토리를 통해 얻어진다. 이름의 결합(moniker binding)을 위해 표준 COM API들이 사용될 수 있다. 오브젝트들에 대한 참조들은 원하는 장치의 명칭 또는 ID를 지정하는 스트링(string)을 이용하여 GetObject 또는 CoGetObject를 호출함으로써 획득될 수 있다. 애플리케이션은 그 다음 적절한 특성들에 대한 "set property" 호출을 통해서 특성들을 설정하거나 검색함으로써 오브젝트를 처리할 수 있다. 애플리케이션이 장치에 대응하는 오브젝트의 특성을 설정하거나 수정할 때, 특성 설정 동작 또는 수정 동작이 명령으로 변환되며, 이 명령은 네트워크를 통해 관련 장치로 전송된다. 오브젝트들은 구현시 차이가 날 수 있지만, 예를 들어 윈도우에 기초한 운영 시스템을 갖는 PC와 같은 제어기상에서 실행되는 클라이언트 애플리케이션들에 대해 유사한 특성에 기초한 모델을 제시할 수 있다.

발명의 목적

이와 같은 오브젝트들(즉, 상기 도입된 바와 같은 소프트웨어 모듈들의 집합) 및 이 오브젝트들간의 상호작용을 제어하는 클라이언트 소프트웨어 애플리케이션들을 포함하는 정보 처리 시스템을 고려하자. 예를 들어, 이 시스템은 오디오/비디오 오락 장치를 갖는 가정용 자동화 서브시스템, 보안 서브시스템 및 사내 기후 제어 서브시스템을 포함한다. 이들 서브시스템들 및 이들의 컴포넌트들은 그 제어를 애플리케이션 클라이언트들에 제시하기 위해 특성들을 사용하며 상태 변화를 애플리케이션 클라이언트들에게 알리기 위해 이벤트들을 사용하는 OLE 자동화 오브젝트들로서 모델링된다. 이 서브시스템들은 그 제어 신호들을 위해서 다른 통신 프로토콜들을 사용할 수 있다. 따라서, 이들은 서로 직접 통신할 수 없기 때문에, 이들은 오브젝트 레벨로 통신한다. 클라이언트 애플리케이션은 제 1(소프트웨어) 서브시스템 또는 제 1 장치를 나타내는 제 1 오브젝트의 "상태" 특성에 대한 변화의 통지를 위해 등록하고, 제 2 서브시스템 또는 제 2 장치를 나타내는 제 2 오브젝트의 특정 특성을 설정함으로써 응답할 수 있다. 그러나, 클라이언트 애플리케이션은 이 상호작용을 제공하기 위해 모든 시간을 운행할 필요가 있다. 그러므로, 또 다른 해결책은 제 1 오브젝트의 특성에의 변화가 생길 때마다 SetProperty 호출로서 제 2 오브젝트의 특성에 전파되는 특성의 새로운 값을 지정하는 것이다. 이 메카니즘은 특성 루트라 불린다. 특성 루트는 오브젝트들을 상호접속해 그 자체 시스템 와이드의(system-wide) OLE 자동화 오브젝트로서 네트워크의 디렉토리에 등록된다. 루트를 등록하는 것은 특성들간의 링크, 반드시는 아니지만, 전형적으로, 다른 오브젝트들의 특성들간에 링크를 생성한다. 제 1 특성이 변할 때마다, 이 변화는 호출을 트리거하여 이들 특성들을 상호접속하는 등록된 루트를 통해서 제 2 특성을 변화시킨다.

그러나, 이 메카니즘은 몇 가지 결점들을 갖는다. 예를 들어, 오브젝트의 특성의 상태 변화가 오브젝트의 특성을 포함한 루트를 등록하는 특정 클라이언트 애플리케이션에 의해서라기보다는 다른 영향에 의해 트리거될 수 있다. 이 환경 하에서 이 상태 변화는 이 특정 루트를 호출시켜서는 안된다. 예를 들어 복수의 루트들이 하나 이상의 공통의 특성들을 가지는 경우에 문제가 발생한다. 루트들간의 하나 이상의 특성들의 이 공유는 특히 장치들이 의도한 바와 같이 부가되거나 대체되는 가정용 네트워크와 같은 오픈 아키텍쳐에서 있을 수 있다. 이 문제를 설명하기 위해, 예를 들어 제 1 특성 루트를 등록하는 제 1 클라이언트 애플리케이션 및 제 2 특성 루트를 등록하는 제 2 애플리케이션을 고려하자. 오브젝트 A의 특성(1)이 상태 "0"에서 상태 "1"로 변하는 경우, 제 1 루트가, 오브젝트(B)의 특성(2)이 자신의 상태를 "0"에서 "1"로 변화시키도록 호출된다. 그러나, 제 2 루트는, 오브젝트 A의 특성(1)의 상태 "0"에서 상태 "1"로의 변화가 오브젝트 C의 특성(3)의 상태 "0"에서 "1"로의 변화를 가져오면 지정한다. 제 1 루트 및 제 2 루트 둘다 등록되었다면, 제 1 루트를 호출시켜 시스템은 제 1 애플리케이션에 대한 바람직한 엔드 상태도 제 2 애플리케이션에 대한 바람직한 엔드 상태도 아닌 상태를 취할 것이다. 왜냐하면 오브젝트 B 및 오브젝트 C 둘 다는 그들 특성의 상태를 변화시킴으로써 응답하기 때문이다. 게다가, 복수의 애플리케이션들이 관련된 특성 루트들을 등록하거나 등록하지 않을 때, 부작용이 완전한 시스템의 고장(breakdown)을 가져올 수 있다. 예를 들어, 특정 애플리케이션이 시스템에 미리 지정된 행동을 제공하는 특정 루트를 등록한다. 또 다른 애플리케이션이 제 1 루트와 공통적인 소스 특성을 갖지만 다른 목적지 특성을 갖는 루트를 부가하거나, 전체적으로 제 1 루트를 제거하는 경우, 시스템을 동작 불능으로 하거나 심지어 자기 파괴적인 결과를 초래할 수 있다.

그러므로, 본 발명의 목적은 시스템이 특성 루트 매카니즘을 사용하여 관련 애플리케이션에 의해 바람직하게 되는 상태를 취하도록 보장하는 것이다. 본 발명의 또 다른 목적은 특성 루트들을 등록하거나 등록하지 않는 것의 결과로서 시스템 고장을 회피하는 것이다.

이를 위해, 본 발명은 제 1 소프트웨어 오브젝트에 의해 표현되는 제 1 물리 컴포넌트 및 제 2 소프트웨어 오브젝트에 의해 표현되는 제 2 물리 컴포넌트를 포함하는 정보 처리 시스템을 제공한다. 제 1 오브젝트는 적어도 제 1 오브젝트로의 제 1 호출을 통해서 변경가능한 제 1 특성을 갖는다. 제 2 오브젝트는 적어도 제 2 오브젝트로의 제 2 호출을 통해서 변경가능한 제 2 특성을 갖는다. 이 시스템은, 제 1 특성에서의 변화가 특성 루트를 호출할 때에 제 2 호출을 제 2 오브젝트에 발행시킬 수 있도록 제 1 특성을 제 2 특성에 연결시키는 특성 루트를 등록할 수 있게 한다. 제 1 오브젝트로의 입력 호출은 루트를 조건부로 호출할 수 있도록 하는 그와 관련된 식별자를 갖는다. 식별자는 예를 들어 시스템 와이즈의 특정 수나 오브젝트이다. 이 오브젝트는 예를 들어 포함되는 모든 루트들의 기술 및 어떤 루트들을 조건부로 호출하기 위한 애플리케이션 논리를 포함한다.

지금까지, 루트는 단지 자동적으로 호출되지는 않는다. 왜냐하면 그 소스 오브젝트의 소스 특성이 변하기 때문이다. 식별자는, 루트가 조건부로, 즉, 하나 이상의 미리 지정된 조건들이 정합되는 경우 호출되게 한다. 예를 들어, 제 1 오브젝트는 제 1 호출을 수신후 제 1 특성을 변화시킨다. 제 1 특성을 변화시킨 후, 제 1 오브젝트는 임의의 특성 루트가 제 1 특성의 변화에 관련되는지를 결정하기 위해 룩업 동작(look-up action)을 개시한다. 이 동작 순서는 바람직하다. 왜냐하면 특성은 변화할 수 없거나 변화할 필요가 없기 때문이다. 이 순서가 반대가 되는 경우, 호출들은 제 1 오브젝트의 특성이 변화를 겪지 않고 제 2 오브젝트로 전송되고 모순이 야기될 것이다. 제 1 특성의 변화와 관련되는 특성 루트가 하나 이상 발견되면, 이 시스템은 식별자와 발견된 하나 이상의 특성 루트들간에 정합이 있는지를 결정한다. 만일 정합이 있는 경우, 정합하는 특성 루트 또는 루트들은 호출된다. 정합이 발견되지 않는 경우, 루트는 호출되지 않는다. 식별자는 예를 들어, 시스템이 동작하는 시나리오에 대한 참조를 포함한다. 이 시나리오와 관련되는 루트 또는 루트들은 제 1 호출내의 식별자에서도 식별된다. 이 시스템은 소프트웨어 애플리케이션이 특성 루트를 등록하게 할 수 있으며, 호출내의 식별자는 소프트웨어 애플리케이션에 대한 참조를 포함한다. 따라서, 특정 소프트웨어 애플리케이션과 관련되는 루트들만이 호출된다. 호출의 식별자는 시나리오 식별자 및 애플리케이션 식별자 둘다 가질 수 있다.

특성 루트는 특성 루트를 등록한 소프트웨어 애플리케이션에 대한 참조를 포함하는 것이 바람직하다. 애플리케이션을 제거하는 경우, 제거된 애플리케이션과 관련되는 루트들은 더 이상 필요하지 않는다. 따라서, 이 루트들은 애플리케이션에 대한 그들의 참조에 기초하여 등록되지 않는다.

상술된 룩업 동작은 제 1 오브젝트와 관련되는 룩업 테이블 또는 그래프를 포함할 수 있다. 예를 들어, 제 1 오브젝트는 룩업 매카니즘 자체를 포함하거나 루트 매니저와 같은 시스템내의 다른 장소에서 룩업 기능을 활성화시킨다. 루트 매니저는 특성 루트들을 관리할 책임이 있는 시스템의 소프트웨어 오브젝트이다. 루트 매니저는 특성 루트의 등록 및 등록해제를 수행한다. 룩업 매카니즘은 제 2 오브젝트의 제 2 특성을 변화시키는 것이 실제로 바람직한지의 여부를 지정하는 식별자를 고려한다. 식별자는 예를 들어 특성 루트를 등록하는 애플리케이션에 의해 의도되는 특정 변화 시나리오를 지정한다. 상술된 예에서처럼, 오브젝트(A)의 특성에 있어서의 변화는 제 1 및 제 2 루트 둘다가 시나리오 제어가 없는 경우 호출되도록 한다. 이 호출이 제 1 루트와 관련되는 시나리오를 식별하는 경우, 제 2 루트는 호출되지 않는다.

본 발명에 따르면, 하나 이상의 오브젝트들을 공유하는 복수의 루트들은 독립적으로 실행되고 서로 간섭하지 않는다. 이 시스템은 식별자에 기초하여 특정 루트 및 이 루트를 등록하는 애플리케이션을 다시 추적할 수 있도록 특성 변화의 어떤 시퀀스도 로그할 수 있다. 후자의 경우는 예를 들어 유지보수 또는 디버깅과 관련된다. 게다가, 애플리케이션이 제거되는 경우, 애플리케이션과 관련되는 모든 루트들을 제거하는 것은 문제가 없다. 이 루트들은 식별자로 인해 서로 독립적으로 실행되고 다른 애플리케이션들과 관련되는 루트들은 서로 영향을 미치지 않는다. 이 독립성 때문에, 시스템은 예를 들어 시스템의 상태, 시간, 이용 가능한 자원 등에 기초하여 루트들을 선택적으로 인에이블 또는 디스에이블할 수 있다. 라벨링된 루트들의 독립성은 또한 소프트웨어 애플리케이션 또는 소프트웨어 에이전트가, 장치들 또는 소프트웨어 모듈들이 플러그 인 또는 언플러그되는 경우에, 루트들을 인에이블하거나 디스에이블하게 할 수 있다. 게임 또는 교육 환경에서, 애플리케이션은 플레이어들의 수, 스킬 및 위치에 기초하여 루트들을 인에이블하거나 디스에이블 할 수 있다. 요약하면, 식별자를 이용하여 루트들을 라벨링함으로써 얻어진 루트들의 독립성은 오브젝트에 기초한 정보 처리 시스템을 사용하는 것에 또 다른 자유도를 부가한다.

도 1은 시나리오 제어 특성 루트들을 도시하는 블록도.

도 2는 특성들을 갖는 오브젝트들로 구성된 객체 지향 시스템의 블록도.

도 3은 본 발명의 또 다른 객체 지향 시스템의 블럭도.

본 발명은 일례로서 그리고 첨부한 도면을 참조로 하여 설명된다.

도 1은 본 발명에 따른 소프트웨어 오브젝트들(210, 212 및 214)들간의 특성 변화의 시나리오 제어 루팅을 도시한 블록도(200)이다. 소프트웨어 오브젝트(210)는 입력 호출을 수신하는 입력(216) 및 출력 호출을 발행하는 출력(218)을 갖는다. 오브젝트(212)는 입력 호출을 수신하는 입력(220)을 갖는다. 오브젝트(214)는 입력 호출을 수신하는 입력(222)을 갖는다. 오브젝트(210)는 복수의 특성들을 가지지만, 도면을 간단화하기 위해서 이 특성들 중 단지 하나의 특성(P210)만이 도시되어 있다. 특성(P210)은 특성(P210)을 참조하는 입력(216)에서의 입력 호출을 통해서 변할 수 있다. 오브젝트들(212 및 214)은 각각 입력(220 및 222)에서의 적절한 입력 호출들을 통해서 변화가능한 각각의 특성들(P212 및 P214)을 갖는다.
제 1 클라이언트 애플리케이션(도시되지 않음)은 특성(P210)에서의 변화가, 오브젝트(210)가 특성(P212)을 변화시키기 위해 출력(218)에서의 출력 호출을 오브젝트(212)에 발행하도록 특성(P210)을 특성(P212)에 연결시키는 제 1 루트를 등록한다. 제 2 클라이언트 애플리케이션은 특성(P210)에서의 변화가, 오브젝트(210)가 특성(P214)을 변화시키기 위해 출력(218)에서의 출력 호출을 오브젝트(214)에 발행하도록 특성(P210)을 특성(P214)에 연결시키는 제 2 루트를 등록한다. 추가적인 조치 없이, 특성(P210)에서의 변화는 제 1 루트 및 제 2 루트 둘다를 호출시키고 이에 따라서 특성들(P212 및 P214) 둘 다에서의 변화를 트리거한다. 그러므로, 본 발명에 따르면, 오브젝트(210)의 입력(216)에서의 입력 호출은 동일한 소스 특성(P210)을 공유하는 제 1 루트 및 제 2 루트 중 적절한 루트를 호출시키도록 선택적으로 제어하기 위한 식별자를 포함한다. 오브젝트(210)가 입력(216)에 대해 호출 또는 요청을 수신하는 경우, 오브젝트는 호출을 처리하여 이 호출에 따라서 특성(P210)을 변화시킨다. 그 결과, 오브젝트(210)는 루트가 특성(P210)의 변화와 관련되는지를 결정하기 위해 룩업 동작을 트리거한다. 오브젝트(210)는 이 예에서 특성(P210)의 변화에 관한 루트들을 식별하는 룩업 테이블(224)을 갖는다. 룩업 동작의 결과는 제 1 루트 및 제 2 루트 둘 다가 특성 변화와 관련이 있다는 것이다. 입력(216)에서의 호출은 특성(P210)의 변화에 관한 루트들 중 어느 루트가 호출되는지를 결정하기 위한 식별자를 포함한다. 식별자가 "I"인 경우, 테이블(224)은 제 1 루트가 오브젝트(212)의 특성(P212)을 변화시키기 위해 호출되는 것으로 규정한다. 식별자가 "Ⅱ"인 경우, 테이블(224)은 제 2 루트가 오브젝트(214)의 특성(P214)을 변화시키기 위해 호출되는 것으로 규정한다. 관련된 루트를 호출하기 전에 특성을 변화시키는 것은 신뢰성의 이유로 행해진다.

삭제

도 2는 본 발명에 따른 정보 처리 시스템(100)의 예를 도시한 블록도이다. 시스템(100)은 복수의 소프트웨어 오브젝트들(102, 104, 106, 108, 110 및 112)를 포함한다. 오브젝트들(102-112) 각각은 예를 들어 가정용 자동화 시스템내의 특정 제어가능한 장치를 나타낸다. 오브젝트들(102 내지 112) 각각은 하나 이상의 특성들, 이 예에선 특성 1, 특성 2 및 특성 3으로 불리는 3개의 특성들을 갖는다. 클라이언트 소프트웨어 애플리케이션(114)은 오브젝트들(102, 104, 106, 110 및 112)을 상호접속시키는 복수의 루트들(116, 118 및 122)을 등록한다. 오브젝트(102)의 특성 1이 자신의 상태를 변화시킨 경우, 루트(116)는 오브젝트(104)의 특성 2를 변화시키기 위해 호출된다. 차례로, 오브젝트(104)의 특성 2가 자신의 상태를 변화시킨 경우, 루트(118)는 오브젝트(106)의 특성 1을 변화시키기 위해 호출된다. 오브젝트(106)의 특성 1의 상태 변화가 완료된 경우 루트(120)는 오브젝트(110)의 특성 1을 설정하기 위해 호출된다. 오브젝트(110)의 특성 1이 오브젝트(112)의 특성 2를 변화시키기 위해서 자신의 상태를 변화시킨 경우 오브젝트(110)는 루트(122)를 통해서 오브젝트(112)에 접속된다.

루트들(116 내지 122)을 호출시킴으로써 실행되는 시나리오의 일례는 다음과 같다. 오브젝트(102)의 특성 1이 DVD 플레이어(도시되지 않음)의 온/오프 제어 기능을 나타낸다. 특성 1이 "온"에서 "오프"로 상태를 변화한 경우, 사운드 시스템(도시되지 않음)은 활성화되어야만 된다. 오브젝트(104)의 특성 2가 사운드 시스템의 온/오프 제어 기능을 나타낸다. 오브젝트(104)의 특성 2는 루트(116)를 통해서 설정된다. 사운드 시스템이 오브젝트(104)를 통해서 활성화되는 경우, 방의 빛(도시되지 않음)이 미리 결정된 레벨로 어둡게 될 것이다. 그러므로, 오브젝트(104)는 오브젝트(106)의 특성 1을 변화시키기 위해 루트(118)를 호출한다. 오브젝트(106)는 조명 시스템(도시되지 않음)에 대한 제어기(도시되지 않음)의 소프트웨어 표현을 포함하며, 오브젝트(106)의 특성 1은 루트(118)를 통해서 설정된 빛의 휘도 레벨을 나타낸다. 제어기 표현(106)은 조명 시스템, 여기에서는 오브젝트(110)의 표현에 호출을 발행하는데, 이 오브젝트의 특성 1은 루트(120)를 통해서 제어기의 상태에 따라서 설정된다. 빛이 미리 결정된 레벨로 설정된 경우, 오브젝트(110)는 전화기(도시되지 않음)를 나타내는 오브젝트(112)의 상태를 변화시키기 위해 루트(122)를 호출한다. 루트(122)는 DVD 영화를 볼 때 사용자가 인터럽트되는 것을 회피하기 위해서 전화의 음향 신호를 디스에이블하도록 한다. 오브젝트(112)의 특성 2는 전화의 음향 신호의 온/오프 제어 기능을 나타낸다.

여기에서는, 제 2 소프트웨어 애플리케이션(124)이 루트(126 및 128)를 등록한다. 루트(126)는 오브젝트(106)의 특성 1의 상태에서의 변화를 오브젝트(108)의 특성 1에 전파한다. 루트(128)는 오브젝트(106)의 특성 1의 상태의 변화를 오브젝트(110)의 특성에 전파한다. 상기 예에서, 소프트웨어 오브젝트(106)에 의해 표현되는 광 제어기가 상태를 "저(light low)" 또는 "소등(light off)"으로 변화시킨 경우, 상기 예에서 조명 시스템을 나타내는 오브젝트(110)의 특성 1에의 루트(128)가 호출된다. 또한, 호출이 이 예에서 가정 보안 시스템(도시되지 않음)을 나타내는 오브젝트(108)의 특성 1에 발행된다. 오브젝트(108)의 특성1을 설정하는 것은 가정 보안 시스템을 온한다.

루트(128)는 루트(120)와 병렬로 실행된다는 것에 유의하라. 루트들(128 및 120)이 다른 라벨들 또는 식별자들을 갖지 않는 경우, 오브젝트(106)의 특성 1에서의 상태 변화는 루트들(120, 126 및 128)을 직접 호출시키고 간접적으로 루트(122)를 호출시킨다. 이것은 이 경우에 사용자의 의도는 아니다. 따라서, 오브젝트들이 식별자들을 통해서 관련된 시나리오를 식별할 수 있도록 호출들을 라벨링함으로써, 하나 이상의 소스 오브젝트들의 하나 이상의 소스 특성들을 공유할 때조차, 한편으로는 루트(120) 및 다른 한편으로는 루트(126 및 128)는 독립적으로 된다.

도 3은 DVD 플레이어를 정지하기 위한 사용자의 동작을 오락 시스템(300)이 자동적으로 검출할 수 있도록 하는 시나리오를 도시한다. 시스템(300)은 DVD 플레이어(도시되지 않음)를 나타내는 소프트웨어 오브젝트(302), 조명 시스템(도시되지 않음)을 나타내는 소프트웨어 오브젝트(304) 및 카메라(도시되지 않음)를 나타내는 소프트웨어 오브젝트(306)를 포함한다. 원격 제어 장치(308)상의 버튼을 누르면 다음과 같은 시나리오가 활성화된다. DVD 모드가 "재생"으로 변경되어, 빛의 휘도가 20%가 되고 카메라의 배경 인식이 "어둡게"로 설정되고 그 상태가 (사용자의 의자내에서) "검출 변화"로 설정된다. 사용자가 일어나는 경우, 카메라는 움직임 검출기를 통해서 그/그녀의 움직임을 검출한다. 사용자의 움직임을 검출한 경우, "휘도"는 100%로 설정되며, 카메라의 배경 인지는 "밝음"으로 설정되고 DVD 모드는 "정지"로 설정된다. 유사한 시나리오는 사용자가 TV 프로그램을 시청하는 경우 가능하다. 이 경우에, 프로그램의 자동 기록이 활성화된다. 사용자 돌아오면, 컨텐트가 떠난 시점에서부터 재생된다. 몇몇 경우에, 이와 같은 시스템의 행동은 시나리오를 통해서 활성화되지 않는 한 바람직하지 않다고 여겨질 수 있다. 예를 들어, 사용자가 단지 현재의 프로그램을 떠나 놓친 컨텐트를 리뷰하지 않고 나중에 돌아오는 것을 바라는 경우이다.

상기 시스템들(100 및 300)은 객체 지향이며, 오브젝트 특성들의 제어에 기초한다. 가정 오디오/비디오 상호동작성(HAVi: Home Audio/Video interoperability)에 기초한 시스템은 루트 라벨링 방식으로부터 유사한 이점을 얻을 수 있다. HAVi의 간략한 설명은 우선 본 발명에 따른 시스템의 HAVi 구현을 위한 컨텐트를 제공하기 위해서 주어진다.

필립스 일렉트로닉스가 가맹하고 있는 가전제품 제조업자들의 컨소시엄은 오디오/비디오 전자기기 및 멀티미디어 산업의 표준을 제공하기 위해서 가정용 네트워크에서의 디지털 가전 제품용 API(application programmning interfaces)들의 핵심에 관한 사양에 대해 작업해왔다. API는 운영 시스템 또는 애플리케이션 프로그램에 대한 요구를 실행하는데 필요한 방법을 지정한다. 가정용 네트워크는 분산 계산 플랫폼이라고 여겨진다. HAVi(가정 오디오/비디오 상호동작성) 아키텍쳐라 불리는 표준의 주된 목적은 다른 벤더들(vendors)의 제품들이 상호동작할 수 있도록, 즉 애플리케이션 작업들을 수행할 수 있도록 하는 것이다. 가정 오락 기기(DVD 플레이어들, DV 캠코더들, 디지털 TV 세트 등)와 같은 현재 CE 장치들은 디지털 처리 및 디지털 저장 시스템들이다. 이 장치들을 네트워크로 접속하는 것으로써 처리 및 저장 자원들을 공유하는 것이 가능하게 된다. 이것은 예를 들어 사용자 상호작용을 단순화하기 위해서 몇몇 CE 장치들의 제어를 동시에 조정할 수 있게 한다. 예를 들어, 제 1 장치는 제 2 장치상에 순간적인 기록을 하는 한편, 제 3 장치상의 EPG(전자 프로그램 가이드)에 액세스할 수 있다. 가정용 네트워크는 CE 장치들을 접속하기 위한 패브릭(fabric)을 제공한다. 접속된 장치들이 제어(한 장치가 다른 장치로 명령을 전송) 및 AV(오디오/비디오) 데이터(한 장치가 다른 장치로 오디오 또는 비디오 스트림을 전송) 둘 다를 교환할 수 있게 한다. 이 네트워크는 이 모두를 달성하기 위하여 여러 필요 조건들에 부합해야만 한다. 이는 고 데이터 레이트의 AV 스트림의 전송을 적절하게 지원하여야만 한다. 이 네트워크는 자기 구성, 자기 관리 및 핫 플러그-앤-플레이를 지원하여야만 한다. 이는 저비용의 케이블링 및 인터페이스들을 요구해야만 한다.

HAVi 소프트웨어 아키텍쳐는 플랫폼에 독립적이고 자바에 기초한다. HAVi는 네트워크에 접속된 장치들간에서 제어 및 컨텐트를 전송하기 위해 고성능의 시리얼 버스 프로토콜 IEEE 1394 을 사용한다. IEEE 1394 표준은 동적으로 구축 가능하고, 저비용의 디지털 네트워크이다. IEEE 1394는 백플랜(backplane) 물리층 및 지점간(point-to-point) 케이블 접속에 의한 가상 버스 구현 둘다를 규정한다. 백플랜 버전은 12.5, 25 또는 50Mbits/sec로 동작한다. 케이블 버전은 100, 200 및 400 Mbits/sec의 데이터 레이트를 지원한다. 이 표준은 매체, 토폴로지 및 프로토콜을 지정한다. IEEE 1394 트랜스포트 프로토콜은 특히 고 데이터 레이트 능력으로 인해 오디오 및 비디오 통신 프로토콜들을 지원하는데 유용하다.

HAVi 아키텍쳐는 CE 장치들의 추상적인 표현을 통해서 네트워크내의 CE 장치들을 제어한다. 추상적인 표현들은 제어기에 의해 동작되고 관련된 실제 CE 장치들의 특이성(idiosyncrasies)을 숨긴다. 따라서, 추상적인 표현은 고레벨의 소프트웨어를 위해서 균일한 인터페이스를 제공한다. 추상적인 표현들은 표현되는 장치의 특성들을 반영하는 제어 특성들로 등록된다. 추상적인 표현들은 애플리케이션들에 자신들의 상호동작성 API들을 노출시키고 가정용 네트워크 상에서 이동 가능한 분산 애플리케이션들을 조립하기 위한 서비스들의 세트를 집합적으로 형성한다.

아키텍쳐는 장치가 가정용 네트워크내의 또 다른 장치에 명령 또는 제어 정보를 전송하도록 한다. HAVi 순응(HAVi-compliant) 장치는 그 사용자 인터페이스(예를 들어, GUI) 및 그 제어 능력과 관련하는 데이터(장치 제어 모델 또는 DCM이라 불리는 상기의 추상적인 표현, 이하 참조)를 포함한다. 이 데이터는 예를 들어 네트워크상의 다른 장치들에 의해 업로딩되어 실행될 수 있는 HAVi 바이트코드(자바)를 포함한다. HAVi 순응 장치는 시스템내의 다른 장치들과 통신하는데 최소한 충분한 기능을 갖는다.
상호작용동안, 장치들은 피어 대 피어 형태(peer-to-peer fashion)로 제어 및 데이터를 교환할 수 있다. 이것은 통신 레벨에서 어떠한 장치들도 시스템의 마스터 또는 제어기로서 작용할 필요가 없도록 한다. 다른 한편으로, 이것은 논리적인 마스터 또는 제어기가 기본적인 피어 대 피어 통신 모델에 제어 구조를 부가하도록 할 수 있다. HAVi는 후술되는 바와 같이 제어기들 및 제어된 장치들을 구별한다. 제어기는 제어되는 장치의 호스트로서 역할을 하는 장치가다. 제어기는 제어되는 장치에 관한 추상적인 표현을 호스트한다. 제어 인터페이스는 추상적인 표현의 API를 통해서 노출된다. 이 API는 애플리케이션이 장치를 제어하기 위한 액세스 포인트이다.

HAVi 순응 CE 장치들은 FAV(Full-AV device), IAV(Intermediate-AV device) 및 BAV(Base-AV device)와 같이 분류되는 장치이다.

FAV는 HAVi 소프트웨어 아키텍쳐의 완전한 세트의 소프트웨어 컴포넌트들을 포함한다(이하 참조). FAV는 HAVi 바이트코드에 대해 런타임 환경을 갖는 것을 특징으로 한다. 이것은 FAV가 예를 들어 그 제어에 대해 향상된 능력들을 제공하기 위해서 다른 장치들로부터 바이트코드를 업로드하게 할 수 있다. 예를 들어, FAV는 HAVi 순응 셋톱 박스, HAVi 순응 디지털 TV 수상기 및 가정용 PC에 의해 형성될 수 있다. 예를 들어, 지능형 TV 수상기는 네트워크 상에 접속된 다른 장치들의 HAVi 제어기가 될 수 있다. 이 수상기는 이 장치를 위한 UI를 생성하고 이 장치의 외부 제어를 제공하기 위하여 다른 장치로부터 업로드된 바이트코드를 얻는다. 이 장치를 나타내는 아이콘은 TV 스크린상에 나타날 수 있으며, 이 아이콘을 이용한 사용자 상호작용에 의해 제어 프로그램의 요소들이 나타난 장치를 미리 지정된 방식으로 활성화할 수 있다.

IAV는 HAVi 바이트코드에 대한 런타임 환경을 제공하는 것이 아니라 가정용 네트워크상의 특정 장치들의 제어를 위한 고유의 지원을 제공할 수 있다. IAV는 특정 장치들의 일반적인 기능들을 제어하기 위한 인터페이스를 제공하는 임베드된 소프트웨어 요소들을 포함한다. 이들 소프트웨어 요소들은 HAVi 바이트코드일 필요는 없고, 다른 장치들에 액세스하도록 고유의 인터페이스들을 사용하는 IAV상에 고유의 애플리케이션들로서 구현될 수 있다.

BAV는 업로딩될 수 있는 HAVi 바이트코드를 제공할 수 있지만 HAVi 아키텍쳐의 임의의 소프트웨어 요소들을 호스트하지 않는다. BAV는 전자의 업로딩된 바이트코드에 의해 FAV를 통해서 제어가능하다. BAV는 고유의 코드를 경유하여 IAV를 통해서 제어가능하다. 한편으로는, FAV와 BAV 또는 IAV와 BAV간의 통신에서는 HAVi 바이트코드가 BAV에 의해 사용되는 명령 프로토콜로 및 명령 프로토콜로부터 번역될 필요가 있다.

HAVi 아키텍쳐의 핵심 사양에 포함되는 주된 소프트웨어 요소들이 이하에 리스트된 요소들이다. 이들 요소들의 보다 상세한 설명을 위하여, 본원에 참조된 HAVi 사양을 참조하라.

1) 1394 통신 매체 매니저(CMM)- 다른 소프트웨어 요소 및 IEEE 1394간의 인터페이스로서 역할을 한다.

2) 이벤트 매니저(EM)- 기기들(장치들)이 네트워크에 부가되거나 제거될 때 발생하는 네트워크 구성의 변화와 같은 네트워크내의 이벤트들의 여러 소프트웨어 요소들에 통지한다.

3) 레지스트리 - 네트워크에 접속되는 기기들에 대한 정보 및 그들이 제공하는 기능들을 유지한다. 애플리케이션들은 이 정보를 레지스트리로부터 얻을 수 있다.

4) 메시징 시스템(MS)- 네트워크상의 각종 기기들의 소프트웨어 요소들간의 통신을 용이하게 하는 API로서 역할을 한다. 메시징 시스템은 HAVi 소프트웨어 요소들에 통신 설비들을 제공한다. 이것은 네트워크 및 트랜스포트층들에 독립적이다. 메시징 시스템은 임의의 FAV 및 IAV에 임베딩된다. 메시징 시스템은 FAV 또는 IAV에서의 추상적인 표현을 위한 식별자들을 할당하는 역할을 한다. 이들 식별자들은 우선 FAV 또는 IAV에서 등록하기 위한 추상적인 표현들에 의해 사용된다. 그리고, 이들은 가정용 네트워크내에서 서로 식별하기 위해 추상적인 표현들에 의해 사용된다. 제 1 추상적인 표현들이 다른 추상적인 표현에 메시지를 전송하고자 할 때, 메시징 API를 호출하면서 후자의 식별자을 사용하여야만 한다.

5) 장치 제어 모듈(DCM)- 네트워크상의 기기를 표현한다. 애플리케이션 프로그램들은 DCM과 직접 상호작용할 수 있다. 이것은 각각의 개별적인 기기의 특이성으로부터 이들을 보호한다.

삭제

6) DCM 매니저- DCM들을 인스톨한다. 새로운 기기에 관한 새로운 DCM들을 인스톨함으로써 자동적으로 네트워크의 변화에 반응한다.

7) DDI(Data Driven Interaction) 제어기- HAVi 소프트웨어 요소 대신에 기기의 디스플레이상에 GUI(그래픽 사용자 인터페이스)를 렌더링한다. 이것은 그래픽에서 텍스트만으로 변화하는 광범위한 디스플레이들을 지원한다.

8) 스트림 매니저(SMGR)- 네트워크상의 2개 이상의 기기들간의 접속을 생성하고 실시간 AV 스트림들을 라우팅한다.

HAVi 아키텍쳐는 레벨 1 및 레벨 2라 불리는 적어도 2개의 레벨의 상호동작성을 지정한다.

레벨 1의 상호동작성은 기존의 장치들이 기본적인 기능 레벨로 통신하도록 하는 일반적인 요구를 다룬다. 이를 달성하기 위하여, 레벨 1의 상호동작성은 하나의 장치가 다른 장치와 통신할 수 있도록 하는 일반적인 세트의 제어 메시지들(명령들)과 그 분류(TV, VCR, DVD 플레이어 등)가 주어진 장치로부터 당연히 기대되는 한 세트의 이벤트 메시지들을 규정하여 사용한다. 이 방식을 지원하기 위해, 장치 발견, 통신 및 HAVi 메시지 세트라고 하는 기본적인 세트의 매카니즘이 요구된다.

장치 발견에 대하여, 가정용 네트워크내의 각각의 장치는 자신의 능력을 다른 장치들에 공지하도록 하는 널리 규정된 방법을 필요로 한다. HAVi 방식은 소위 SDD(자기 기술 데이터(self describing data)) 데이터를 이용한다. SDD 데이터는 네트워크내의 모든 장치들에 필요하게 된다. SDD 데이터는 다른 장치들에 의해 액세스될 수 있는 장치에 관한 정보를 포함한다. SDD 데이터는 소위 임베딩된 장치 제어 모듈(임베딩된 DCM)의 순시화(instantiation)를 허용하도록 하는 충분한 정보를 최소한 포함한다. 임베딩된 DCM은 플랫폼 의존 코드내의 제어 IAV 또는 FAV 상에 미리 인스톨된 코드의 일부이며 고유의 인터페이스들을 사용해 IAV 또는 FAV의 자원들에 액세스한다. 상술된 바와 같이, 장치에 관한 DCM은 장치의 일반적인 기능들을 제어하기 위한 인터페이스를 제공하는 소프트웨어 요소이다. 임베딩된 DCM의 순시성은 레지스트리로 장치의 능력들의 등록을 실시한다. 레지스트리는 디렉토리 서비스를 제공하고 네트워크상의 임의의 오브젝트가 네트워크상의 다른 오브젝트에 위치할 수 있도록 한다. 등록은 네트워크상의 특정 장치에 전송할 수 있는 기본적인 세트의 명령 메시지들을 애플리케이션이 추론하도록 한다.

통신에 대하여; 애플리케이션이 장치의 능력을 결정하면, 이 애플리케이션은 이들 능력들에 액세스할 필요가 있다. 이것은 애플리케이션들이 장치에 요구를 발부하도록 하는 일반적인 통신 설비를 필요로 한다. 이 서비스는 HAVi 메시징 시스템들 및 DCM들에 의해 제공된다. 이 애플리케이션은 DCM들에 HAVi 메시지들을 전송하고, 그 다음 이 DCM들은 장치들과의 특성 통신을 시작한다.

HAVi 메시지 세트들에 대하여, 레벨 1의 상호동작성을 지원하기 위하여, 명확하게 규정된 세트의 메시지들이 필요한데, 이것은 특정한 공지된 분류(예를 들어, TV 수상기들의 분류, VCR의 분류, DVD 플레이어들의 분류 등)의 모든 장치들에 의해 지원되어야만 된다. 이것은 장치가 제조자와 관계없이 부가적인 장치들뿐만 아니라 기존의 장치들과 함께 동작할 수 있도록 한다.

이들 3개의 기본적인 필요 조건들은 임의의 최소 레벨의 상호동작성을 지원한다. 임의의 장치가 레지스트리를 통해서 다른 능력들을 문의할 수 있기 때문에, 임의의 장치는 다른 장치에 의해 지원되는 메시지 세트를 결정할 수 있다. 애플리케이션들이 메시징 시스템에 액세스할 수 있으므로, 임의의 장치는 임의의 다른 장치와 상호작용할 수 있다.

레벨 1의 상호동작성은 장치들이 기본적인 레벨의 기능으로 상호동작할 수 있도록 한다. 그러나, 장치가 FAV상에 임베딩된 DCM에 존재하지 않는 임의의 부가적인 기능을 가지는 다른 장치와 통신할 수 있도록 보다 확장된 매카니즘이 필요하게 된다. 예를 들어, 임베딩된 DCM은 기존 제품들의 모든 특성들을 지원할 수 없고 장래의 제품의 카테고리들 중 완전히 새로운 카테고리들을 지원할 가능성이 없다. 레벨 2의 상호동작성은 이 매카니즘을 제공한다. 이를 달성하기 위해, HAVi 아키텍쳐는 상술된 임베딩된 DCM의 대안으로서 업로딩가능한 DCM을 허용한다. 업로딩된 DCM은 FAV상의 기존의 DCM을 대체할 수 있다. 업로딩가능한 DCM은 임의의 적절한 소스에 의해 제공될 수 있지만, 유사한 기술은 BAV 장치의 HAVi SDD 데이터에 업로딩가능한 DCM을 배치하도록 하며 BAV가 가정용 네트워크에 접속될 때 BAV에서 FAV장치로 업로딩하도록 한다. HAVi 아키텍쳐가 벤더에 관해서 중립적이므로, 업로딩된 DCM은 잠재적으로 상이한 하드웨어 아키텍쳐들을 갖는 각종 FAV 장치들에서 동작할 필요가 있다. 이를 달성하기 위해서, 업로딩된 DCM들은 HAVi(자바) 바이트코드로 실행된다. FAV 장치들상의 HAVi 바이트코드 런타임 환경은 업로딩된 DCM들의 순시 및 실행을 지원한다. FAV 장치내에서 생성되고 실행되면, DCM은 상술된 것과 동일한 방식으로 BAV 장치들과 통신한다.

레벨 2의 상호동작성의 효과는 특정 장치의 기능에 액세스하기 위해서 필요하게 되는 자원을 고려할 때 명료하게 된다. 레벨 2는 장치에 의해서 제공되는 모든 능력들을 나타내는 업로딩된 DCM을 통해서 장치가 제어되도록 하는 반면에, 레벨 1에서와 유사한 기능을 달성하기 위해, 이 DCM은 네트워크내의 어느 곳에 임베딩되어야만 된다. 예를 들어, 새로운 장치가 네트워크에 부가될 때, 레벨 1은 적어도 하나의 다른 장치가 새로운 장치와 호환가능한 임베딩된 DCM을 포함하는 것을 필요로 한다. 이에 비하여, 레벨 2는 하나의 장치가 새로운 장치로부터 얻어진 업로딩된 DCM을 위한 런타임 환경을 제공하는 것만을 필요로 한다.

바이트코드를 업로딩하고 실행하는 개념은 또한 장치 제어 애플리케이션들이라 불리는 특정 장치를 위한 애플리케이션의 가능성을 제공한다. 이들 애플리케이션들을 통해서 장치 제조자는 HAVi안의 모든 특징들을 표준화할 필요없이 장치의 특정 특징들을 제어하는 방법을 사용자에게 제공할 수 있다. 이 애플리케이션은 HAVi 바이트코드내의 DCM에 의해 제공되어 네트워크상의 각각의 FAV 장치에 의해 업로딩되어 인스톨될 수 있다.

부가적인 정보를 위하여, 공공 도메인에서 입수 가능한 HAVi 사양 및 IEEE 1394 사양에 대한 참조가 행해진다. HAVi 핵심 사양은 웹, 예를 들어, http :// www. sv. philips.com/news/press상에서 입수 가능하고 본원에 참조로 포함된다.

지금부터, HAVi 컨텍스트내에서는, 루트들은 HAVi 순응 시스템을 구성하는 장치들에서의 상태 변화시에 메시징 트랙픽을 셋업하기 위한 등록을 통해서 인스톨될 수 있다. 다시, 식별자를 이용하여 메시지를 라벨링함으로써, 다른 시나리오들의 루트들은 도 1 및 도 2를 참조하여 서술된 객체 지향 방식과 유사한 방식으로 독립적으로 유지된다. 이들 다른 컨텍스트내에서, 용어들, 즉 호출 및 메시지들, 오브젝트들 및 HAVi-소프트웨어 표현들은 본 발명의 목적을 위해 동등한 것으로서 해석되어야만 한다.
다음의 US 특허 출원이 본원에 참조로 포함된다.
폴 챔버스(Paul Chambers) 및 사라브 스리바스타바(Saurabh Srivastava)에 의한 1996년 10월 15일에 출원된 동일 양수인의 미국 시리얼 번호 제 08/731,624호(대리인 번호 PHA 23,169)의 "태스크 구동 분산 멀티미디어 컨슈머 시스템(Task-Driven Distributed Multimedia Consumer System)". 이 문서는 복수의 가전 제품 장치와, 상기 장치들에 결합되며 상기 장치들 사이에서의 상호작용을 제어하는 태스크 구동 제어 수단을 포함하는 제어 시스템에 관한 것이다. 제어 수단은 각 컨슈머 장치의 각각의 소프트웨어 표현들에 따라서 동작한다. 소프트웨어 표현내의 태스크의 변동하는 복잡성을 캡슐화함으로써, 필요에 따라서 이를 단순하게 하거나 또는 복잡하게 하여 능력을 공통 레벨까지 끌어올릴 수 있다. 인터페이스의 레벨은 장치에 공통이기 때문에, 애플리케이션들은 매우 다른 복잡도 레벨을 구현하는 장치들을 균일하게 조정할 수 있다.
예브제니 시테인(Yevgenyi Shteyn)에 의한 1998년 9월 2일자로 출원된 동일 양수인의 미국 시리얼 번호 제09/146,020호(대리인 번호 PHA 23,492)의 "고 데이터 레이트 HAVi 네트워크에 표현된 저 데이터 레이트 네트워크(Low Data-Rate Network Represented On High Data-Rate HAVi-Network)". 이 문서는 가정용 자동화 네트워크내에서 장치들을 제어하기 위한 COM에 기초한 소프트웨어 컴포넌트들과 저 데이터 레이트 트랜스포트층을 사용하는 PC에 기초한 가정용 자동화 시스템에 관한 것이다. 가정용 자동화 시스템은 고 데이터 레이트 트랜스포트층으로서 IEEE 1394를 사용하는 메시징에 기초한 HAVi-네트워크와 병합된다. HAVi 네트워크는 가정용 오락 시스템내의 오디오/비디오 기기를 제어한다. 가정용 자동화 서비스들 및 장치들은 HAVi 순응 요소들로서 HAVi 네트워크의 FAV 또는 IAV 장치에 등록된다. 가정용 자동화 자원들(장치들 및 서비스들)은 HAVi 네트워크로부터의 가정용 자동화 시스템의 제어를 가능하게 하기 위해 COM OLE 자동화 인터페이스들 및 HAVi 순응 인터페이스들 둘 다를 갖는다.
예브제니 시테인(Yevgenyi Shteyn) 및 그레고리 제위키(Gregory Gewickey)에 의한 1998년 6월 30일에 출원된 미국 시리얼 번호 제09/107,525호(대리인 번호 PHA 23,438)의 "다중 통신 프로토콜들을 갖는 시스템의 장치들의 동적 DE 등록(Dynamic DE-Registering of devices in system with multiple communication protocols)". 이 문서는 제 1 및 제 2 전자 서브시스템들과 서브시스템들을 제어하는 제어 수단을 갖는 정보 처리 시스템에 관한 것이다. 적어도 제 1 서브시스템은 제어 수단에 등록된 소프트웨어 표현을 갖는다. 제어 수단은 소프트웨어 표현과 상호작용을 통해서 제 1 서브시스템의 상태를 변화시킨다. 제 1 및 제 2 서브시스템들은 또한 제어 수단이 포함되는 일없이 서로 직접 상호작용할 수 있다. 충돌을 피하기 위해, 적어도 제 1 서브시스템은 제어 수단에 소프트웨어 표현을 기능적으로 디스에이블하도록 제어 수단에 등록을 취소할 수 있다.

삭제

Claims

정보 처리 시스템(100, 300)에 있어서,

제 1 소프트웨어 오브젝트(210)에 의해 표현되는 제 1 물리 컴포넌트와,

제 2 소프트웨어 오브젝트(212)에 의해 표현되는 제 2 물리 컴포넌트를 포함하며,

상기 제 1 오브젝트는 적어도 상기 제 1 오브젝트로의 제 1 호출을 통해서 변경가능한 제 1 특성(P210)을 가지며,

상기 제 2 오브젝트는 적어도 상기 제 2 오브젝트로의 제 2 호출을 통해서 변경가능한 제 2 특성(P212)을 가지며,

상기 시스템은, 상기 제 1 특성에서의 변화가 특성 루트를 호출할 때에 상기 제 2 호출을 상기 제 2 오브젝트에 발행시킬 수 있도록 상기 제 1 특성을 상기 제 2 특성에 연결시키는 특성 루트(224에서 "212,1"; 116, 118, 120, 122)를 등록할 수 있게 하며,

상기 제 1 오브젝트로의 입력 호출은 상기 루트를 조건부로 호출할 수 있도록 하는 그와 관련된 식별자(224에서 "I")를 갖는, 정보 처리 시스템.
제 1 항에 있어서,

상기 제 1 오브젝트는 상기 제 1 호출을 수신한 후에 상기 제 1 특성을 변화시키며,

상기 제 1 특성을 변화시킨 후에, 상기 제 1 오브젝트는 임의의 특성 루트가 상기 제 1 특성의 변화와 연관되는지를 결정하기 위해 룩업 동작을 개시하며,

상기 제 1 특성의 변화와 연관된 특성 루트들이 하나 이상 발견되는 경우, 상기 시스템은 상기 식별자와 발견된 하나 이상의 특성 루트들 사이에 정합이 존재하는지를 결정하며,

정합이 존재하면, 상기 정합 특성 루트나 루트들이 호출되는, 정보 처리 시스템.
제 1 항에 있어서,

상기 식별자는 상기 시스템을 동작시키는 시나리오(224에서 "I")에 대한 참조(reference)를 포함하는, 정보 처리 시스템.
제 1 항에 있어서,

상기 시스템은 소프트웨어 애플리케이션이 상기 특성 루트를 등록시킬 수 있도록 하며,

상기 식별자는 상기 소프트웨어 애플리케이션에 대한 참조를 포함하는, 정보 처리 시스템.
제 4 항에 있어서,

상기 식별자는 상기 시스템을 동작시키는 시나리오에 대한 참조를 포함하는, 정보 처리 시스템.
제 1 항에 있어서,

상기 시스템은 소프트웨어 애플리케이션이 상기 특성 루트를 등록시킬 수 있도록 하며,

상기 특성 루트는 상기 소프트웨어 애플리케이션에 대한 참조를 포함하는, 정보 처리 시스템.
제 4 항에 있어서,

상기 애플리케이션에 의해 등록된 상기 특성 루트는 상기 시스템 상에서 상기 애플리케이션을 실행한 후에 등록해제되는, 정보 처리 시스템.
정보 처리 시스템을 제어할 수 있도록 하는 방법에 있어서,

상기 시스템은,

제 1 소프트웨어 오브젝트(210)에 의해 표현되는 제 1 물리 컴포넌트와,

제 2 소프트웨어 오브젝트(212)에 의해 표현되는 제 2 물리 컴포넌트를 포함하며,

상기 제 1 오브젝트는 상기 제 1 오브젝트로의 제 1 호출을 통해서 변경가능한 적어도 제 1 특성(P210)을 가지며,

상기 제 2 오브젝트는 상기 제 2 오브젝트로의 제 2 호출을 통해서 변경가능한 적어도 제 2 특성(P212)을 가지며,

상기 방법은,

상기 제 1 특성에서의 변화가 루트가 호출되는 경우 상기 제 2 호출을 상기 제 2 오브젝트에 발행시킬 수 있도록 상기 제 1 특성을 상기 제 2 특성에 연결시키는 특성 루트(224에서 "212,1"; 116, 118, 120, 122)를 등록할 수 있도록 하는 단계와,

상기 루트를 선택적으로 호출하기 위해 식별자(224에서 "I")를 갖는 상기 제 1 호출을 상기 제 1 오브젝트가 수신할 수 있도록 하는 단계와,

상기 식별자와 상기 등록된 루트 사이에 정합이 존재하는지를 결정할 수 있도록 하는 단계와,

정합이 존재하는 경우 등록된 상기 루트를 호출할 수 있도록 하는 단계를 포함하는, 정보 처리 시스템 제어 방법.
제 8 항에 있어서,

상기 제 1 특성이 변화된 후에 상기 정합 루트를 호출할 수 있도록 하는 단계를 포함하는, 정보 처리 시스템 제어 방법.