KR20030024806A

KR20030024806A - 정보 처리 장치

Info

Publication number: KR20030024806A
Application number: KR10-2003-7001005A
Authority: KR
Inventors: 다꾸로 노다; 마꼬또 사또; 유끼히꼬 아오끼; 히사또 시마
Original assignee: 소니 가부시끼 가이샤
Priority date: 2001-05-24
Filing date: 2002-05-20
Publication date: 2003-03-26
Also published as: EP1300989A1; US20030177270A1; JP3661936B2; JP2003046535A; WO2002096037A1; CN1463521A

Abstract

본 발명은, UPnP 컨트롤러 포인트로부터 AV/C 기기를 제어할 수 있도록 한 정보 처리 장치에 관한 것이다. IEEE802 네트워크(11)에는 UPnP 컨트롤 포인트(1)가 접속되어 있고, IEEE1394 네트워크(12)에는 AV/C 기기(3, 4)가 접속되어 있다. IEEE802 네트워크(11)와 IEEE1394 네트워크(12)는, 브릿지로서 기능하는 UPnP 디바이스(2)를 통하여 접속되어 있다. UPnP 디바이스(2)는 UPnP 컨트롤 포인트(1)로부터 송신되어 온 SOAP 커맨드를 AV/C 커맨드로 변환하고, IEEE1394 네트워크(12)를 통하여 AV/C 기기(3)에 전송한다. 본 발명은 퍼스널 검퓨터에 적용할 수 있다.

Description

정보 처리 장치{INFORMATION PROCESSING APPARATUS}

최근, IEEE(Institute of Electrical and Electronics Engineers)1394 고속 직렬 버스를 이용한 네트워크(이하, 간단히 IEEE1394 네트워크라 함)가 보급되어 왔다. 오디오 기기나 비디오 기기를 이 IEEE1394 네트워크에 접속함으로써, 각 기기는, AV/C 커맨드를 이용하여, 다른 기기를 제어할 수 있다.

한편, IEEE802 네트워크도 보급되고 있다. 이 IEEE802는 주로 퍼스널 컴퓨터를 서로 접속하기 위한 네트워크로서, UPnP(Universal Plug and Play)의 프로토콜에 기초하여, 각 퍼스널 컴퓨터는 다른 퍼스널 컴퓨터를 제어할 수 있다.

그러나, 이 IEEE1394 네트워크와 IEEE802 네트워크는 각각 독립된 것으로, IEEE802 네트워크에 접속되어 있는 기기(이하, UPnP 기기라 함)는 IEEE1394 네트워크에 접속되어 있는 기기(이하, AV/C 기기라 함)를 제어할 수 없다는 과제가 있었다.

〈발명의 개시〉

본 발명은 이러한 상황을 감안하여 이루어진 것으로, UPnP 기기가 AV/C 기기를 제어할 수 있도록 하는 것이다.

본 발명의 정보 처리 장치는, 제1 네트워크로부터의 제1 포맷의 데이터를 취득하는 취득 수단과, 취득 수단에 의해 취득된 제1 포맷의 SOAP에 기초한 커맨드를 제2 네트워크의 AV/C 커맨드로 변환하여 제2 포맷으로 저장하는 변환 수단과, 변환 수단에 의해 변환된 제2 포맷을 제2 네트워크에 송신하는 송신 수단을 포함하는 것을 특징으로 한다.

상기 변환 수단은, SOAP에 기초한 커맨드에 기술되어 있는 제2 네트워크에 접속되어 있는 기기를 지정하는 노드 유니크 ID와 노드 ID의 대응표를 갖고, SOAP에 기초한 커맨드에 기술되어 있는 제2 네트워크에 접속되어 있는 기기를 지정하는 노드 유니크 ID를, 대응표에 기초하여 노드 ID로 변환할 수 있다.

상기 변환 수단은, SOAP에 기초한 커맨드와 그것에 기초하여 제2 네트워크에 송신되는 커맨드와의 대응표를 갖고, 제2 네트워크를 통하여 수신된 리스펀스에 대응하는 SOAP에 기초한 커맨드를 대응표에 기초하여 검색하고, SOAP에 기초한 커맨드에 대응하는 리스펀스를 제1 네트워크에 송신할 수 있다.

상기 변환 수단은, SOAP에 기초한 커맨드에 포함되는 트랜잭션 라벨에 기초하여, SOAP에 기초한 커맨드와 리스펀스를 대응시킬 수 있다.

상기 변환 수단은, 제1 네트워크에 접속되어 있는 기기로부터의 리퀘스트에 대응하는 파이널 리스펀스가 사전에 정해져 있는 시간 내에 제2 네트워크에 접속되어 있는 기기로부터 수신되지 않을 때, 제1 네트워크에 접속되어 있는 기기에 대하여 처리 중인 것을 나타내는 리스펀스를 송신할 수 있다.

상기 SOAP에 기초한 커맨드가 제2 네트워크의 버스 리세트 시에 재송을 요구하는 커맨드인 경우, 제2 네트워크의 버스 리세트를 검지하여, 제2 네트워크에 버스 리세트가 발생했을 때, 커맨드를 송신하는 검지 수단을 더 포함하도록 할 수 있다.

상기 변환 수단은, 또한 제2 네트워크의 AV/C 커맨드를 제1 포맷의 SOAP에 기초한 커맨드로 변환하여 제1 포맷으로 저장하고, 송신 수단은, 또한 변환 수단에 의해 변환된 제1 포맷의 SOAP에 기초한 커맨드를 제1 네트워크에 송신할 수 있다.

본 발명의 정보 처리 방법은, 제1 네트워크로부터의 제1 포맷의 데이터를 취득하는 취득 단계와, 취득 단계의 처리에 의해 취득된 제1 포맷의 SOAP에 기초한 커맨드를 제2 네트워크의 AV/C 커맨드로 변환하여 제2 포맷으로 저장하는 변환 단계와, 변환 단계의 처리에 의해 변환된 제2 포맷을 제2 네트워크에 송신하는 송신 단계를 포함하는 것을 특징으로 한다.

본 발명의 기록 매체의 프로그램은, 제1 네트워크로부터의 제1 포맷의 데이터를 취득하는 취득 단계와, 취득 단계의 처리에 의해 취득된 제1 포맷의 SOAP에 기초한 커맨드를 제2 네트워크의 AV/C 커맨드로 변환하여 제2 포맷으로 저장하는 변환 단계와, 변환 단계의 처리에 의해 변환된 제2 포맷을 제2 네트워크에 송신하는 송신 단계를 포함하는 것을 특징으로 한다.

본 발명의 프로그램은, 제1 네트워크로부터의 제1 포맷의 데이터를 취득하는 취득 단계와, 취득 단계의 처리에 의해 취득된 제1 포맷의 SOAP에 기초한 커맨드를제2 네트워크의 AV/C 커맨드로 변환하여 제2 포맷으로 저장하는 변환 단계와, 변환 단계의 처리에 의해 변환된 제2 포맷을 제2 네트워크에 송신하는 송신 단계를 실행시킨다.

본 발명의 정보 처리 장치 및 방법, 기록 매체와 프로그램에서는, IEEE802에 기초한 제1 네트워크로부터의 SOAP에 기초한 커맨드가 제2 네트워크의 AV/C 커맨드로 변환된다.

본 발명은, 정보 처리 장치에 관한 것으로, 특히, IEEE802에 기초한 제1 네트워크에 접속되어 있는 기기가, IEEE1394에 기초한 제2 네트워크에 접속되어 있는 기기를 제어할 수 있도록 한 정보 처리 장치에 관한 것이다.

도 1은 본 발명이 적용되는 네트워크 시스템의 구성을 도시한 도면.

도 2는 도 1의 UPnP 디바이스(2)의 구성을 도시한 블록도.

도 3은 도 1의 UPnP 디바이스(2)가 갖는 디바이스 모델의 구성을 도시한 도면.

도 4는 AV/C 커맨드 프레임의 구성을 도시한 도면.

도 5는 ctype을 설명하는 도면.

도 6은 subunit_type을 설명하는 도면.

도 7은 도 1의 네트워크 시스템의 처리를 설명하는 흐름도.

도 8은 도 7의 단계 S3에서 출력되는 커맨드의 구성을 도시한 도면.

도 9는 도 7의 단계 S24의 처리에 의해 출력되는 커맨드의 구성을 도시한 도면.

도 10은 도 7의 단계 S34의 처리에 의해 출력되는 리스펀스의 구성을 도시한 도면.

도 11은 도 7의 단계 26의 처리에 의해 출력되는 리스펀스의 예를 도시한 도면.

도 12는 도 3의 루트 디바이스가 갖는 AV/C Proxy Device Description의 구성을 도시한 도면.

도 13은 도 3의 1394 프록시 서비스가 갖는 AV/C Proxy Service Description의 구성을 도시한 도면.

도 14는 도 3의 1394 노드 서비스가 갖는 AV/C Nodes Service Description의 구성을 도시한 도면.

도 15는 도 3의 1394 노드 서비스가 갖는 AV/C Nodes Service Description의 구성을 도시한 도면.

도 16은 도 3의 루트 디바이스가 갖는 AV/C Proxy Device Description의 다른 구성을 도시한 도면.

도 17은 도 3의 1394 프록시 서비스가 갖는 AV/C Proxy Service Description의 다른 구성을 도시한 도면.

도 18은 도 3의 1394 노드 서비스가 갖는 AV/C Nodes Service Description의 다른 구성을 도시한 도면.

도 19는 디바이스 모델의 다른 구성을 도시한 도면.

도 20은 도 19의 루트 디바이스가 갖는 AV/C Proxy Device Description의 구성을 도시한 도면.

도 21은 도 19의 루트 디바이스가 갖는 AV/C Proxy Device Description의 구성을 도시한 도면.

도 22는 도 19의 1394 프록시 서비스가 갖는 AV/C Proxy Service Description의 구성을 도시한 도면.

도 23은 도 19의 AV/C 노드 서비스가 갖는 AV/C Node Service Description의 구성을 도시한 도면.

도 24는 디바이스 모델의 또 다른 구성을 도시한 도면.

도 25는 도 24의 루트 디바이스가 갖는 AV/C Proxy Device Description의 구성을 도시한 도면.

도 26은 도 24의 AV/C 프록시 서비스가 갖는 AV/C Proxy Service Description의 구성을 도시한 도면.

도 27은 도 24의 AV/C 노드 서비스가 갖는 AV/C Node Service Description의 구성을 도시한 도면.

도 28은 디바이스 모델의 다른 구성을 도시한 도면.

도 29는 도 28의 루트 디바이스가 갖는 AV/C Proxy Device Description의 구성을 도시한 도면.

도 30은 도 28의 루트 디바이스가 갖는 AV/C Proxy Device Description의 구성을 도시한 도면.

도 31은 도 28의 AV/C 프록시 서비스가 갖는 AV/C Proxy Device Description의 구성을 도시한 도면.

도 32는 도 28의 AV/C 노드 서비스가 갖는 AV/C Node Service Description의구성을 도시한 도면.

도 33은 디바이스 모델의 비교를 도시한 도면.

〈발명을 실시하기 위한 최량의 형태〉

도 1은 본 발명을 적용한 네트워크 시스템의 구성을 도시하고 있다. 이 구성에서는, IEEE802 네트워크(11)에 UPnP 컨트롤 포인트(1)가 접속되어 있다. IEEE1394 네트워크(12)에는 AV/C 기기(3, 4)가 접속되어 있다. IEEE802 네트워크(11)와 IEEE1394 네트워크(12)는 UPnP 디바이스(UPnP-AV/C 프록시)(2)에 각각 접속되어 있다.

도 2는 UPnP 디바이스(2)의 구성 예를 도시하고 있다. 도 2에서, CPU (Central Processing Unit)(21)는, ROM(Read Only Memory)(22)에 기억되어 있는 프로그램, 또는 기억부(28)로부터 RAM(Random Access Memory)(23)에 로드된 프로그램에 따라서 각종 처리를 실행한다. RAM(23)에는 또한, CPU(21)가 각종 처리를 실행하는 데에 필요한 데이터 등도 적절하게 기억된다.

CPU(21), ROM(22) 및 RAM(23)은, 버스(24)를 통하여 서로 접속되어 있다. 이 버스(24)에는 또한, 입출력 인터페이스(25)도 접속되어 있다.

입출력 인터페이스(25)에는, 키보드, 마우스 등으로 이루어지는 입력부(26), CRT, LCD 등으로 이루어지는 디스플레이 및 스피커 등으로 이루어지는 출력부(27), 하드디스크 등으로 구성되는 기억부(28), 모뎀, 터미널 어댑터 등으로 구성되는 통신부(29)가 접속되어 있다. 통신부(29)는 IEEE802 네트워크(11) 또는 IEEE1394 네트워크(12)를 통한 통신 처리를 행한다.

입출력 인터페이스(25)에는 또한, 필요에 따라서 드라이브(30)가 접속되고, 자기 디스크(41), 광 디스크(42), 광 자기 디스크(43), 혹은 반도체 메모리(44) 등이 적절하게 장착되고, 이들로부터 판독된 컴퓨터 프로그램이 필요에 따라서 기억부(28)에 인스톨된다.

UPnP 기기(도 1의 예인 경우, UPnP 컨트롤 포인트(1) 및 UPnP 디바이스(2))는, 주로, 어드레싱(Addressing), 디스커버리(Discovery), 디스크립션(Description), 컨트롤(Control), 이벤팅(Eventing), 프리젠테이션(Presentation)의 6개의 기능을 갖고 있다. 어드레싱은 각 UPnP 기기가 IEEE802 네트워크(11) 상에서 어드레스를 취득하기 위한 기능이며, DHCP(Dynamic Host Configuration protocol) 또는 AutoIP가 이용된다.

디스커버리는, 어드레싱 후에 행해지고, 이에 따라 UPnP 컨트롤 포인트(1)는 컨트롤하고자 하는 타깃 기기를 발견할 수 있다. 여기서 이용되는 프로토콜은 SSDP(Simple Service Discovery Protocol)이다. 각 기기는, IEEE802 네트워크(11)에 접속되었을 때, 자기 자신 내에 갖는 디바이스나 서비스를 통지하는 메시지를 IEEE802 네트워크(11) 상에 멀티 캐스트한다(특히, 상대를 지정하지 않고 패킷을 송신한다). UPnP 컨트롤 포인트(1)는, 이 멀티캐스트된 메시지를 수신함으로써, IEEE802 네트워크(11)에 어떠한 기기가 접속되었는지를 알 수 있다.

반대로, UPnP 컨트롤 포인트(1) 측에서, 현재 IEEE802 네트워크(11)에 접속되어 있는 기기를 조사하는 것도 가능하다. 이 때, UPnP 컨트롤 포인트(1)는, 발견하고자 하는 디바이스나 서비스를 키워드로 하여, 검색 커맨드를 IEEE802 네트워크(11) 상에 멀티캐스트한다. IEEE802 네트워크(11)에 접속되어 있는 각 기기는, 멀티캐스트된 검색 커맨드로 규정되어 있는 조건에 자기 자신이 적합한 경우, 그 검색 커맨드에 대하여 리스펀스를 유니캐스트한다(상대측을 지정하여, 패킷을 송신한다). 이에 따라, UPnP 컨트롤 포인트(1)는 IEEE802 네트워크(11)에 접속되어 있는 기기를 검지할 수 있다.

또한, 각 기기는, IEEE802 네트워크(11)로부터 벗어날 때에도, 사전에 그 취지를 브로드캐스트한다.

디스커버리에 의해 UPnP 컨트롤 포인트(1)가 발견한 컨트롤 대상의 기기가 출력한 SSDP 패킷에는, 디바이스 디스크립션(Device Description)의 URL(Uniform Resource Locator)이 기술되어 있다. UPnP 컨트롤 포인트(1)는, 그 URL에 액세스함으로써, 그 기기의 더 상세한 디바이스 정보를 디바이스 디스크립션으로부터 얻을 수 있다. 이 디바이스 정보에는, 아이콘 정보, 모델명, 생산자명, 상품명 등이 포함되어 있다.

또한, 이 디바이스 정보에는, 그 디바이스가 갖는 서비스 정보가 기술되어 있으며, 그 서비스의 상세한 정보가 기술되어 있는 서비스 디스크립션(Service Description)도 서비스 정보에 기술되어 있는 URL로부터 찾아갈 수 있다.

UPnP 컨트롤 포인트(1)는, 이들 디바이스 정보(Device Description)나 서비스 정보(Service Description)로부터, 타깃에 대한 액세스 방법을 알 수 있다.

또한, 디바이스 디스크립션에는, 후술하는 프리젠테이션 URL도 기술되어 있다.

디바이스 디스크립션 및 서비스 디스크립션은 XML(Extensible Markup Language)로 표현되어 있다.

컨트롤은 액션(Action)과 쿼리(Query)의 2개로 크게 분류된다. 액션은 서비스 디스크립션의 액션 정보에 규정된 방법으로 행해지고, 액션을 인보크함으로써, UPnP 콘트롤 포인트(1)는 타깃을 조작할 수 있다.

한편, 쿼리는, 서비스 디스크립션의 stateVariable의 값을 추출하기 위해 이용된다. stateVariable의 값은 기기의 상태를 나타내고 있다.

컨트롤에서는, SOAP(Simple Object Access Protocol)라는 트랜스포트 프로토콜이 이용된다. 그 표현 언어로서는 XML이 이용된다.

이벤팅(Eventing)은, stateVariable의 값이 변경되었을 때, 그것을 타깃으로부터 UPnP 컨트롤 포인트(1)에 통지시키기 위해 이용된다. UPnP 컨트롤 포인트(1)는, 서비스 디스크립션을 해석함으로써, stateVariable로부터 타깃이 보유하는 변수를 알 수 있다. UPnP 컨트롤 포인트(1)는 타깃에 대하여, 서브 스크립션을 출력해 둠으로써, 그 변수 중, sendEvents가 yes로 되어 있는 변수에 관하여, 변수의 변경이 있었을 때, 타깃으로부터 통지를 수취할 수 있다. 이벤팅에서는 GENA(General Event Notification Architecture)라는 트랜스포트 프로토콜이 이용된다. 그 표현 언어로서는 XML이 이용된다.

프리젠테이션(Presentation)은, 사용자에게 사용자 인터페이스(UI)를 이용한컨트롤 수단을 제공하기 위해 이용된다. 디바이스 디스크립션에 기술된 프리젠테이션 URL에 액세스함으로써, HTML(Hyper Text Markup Language)에 의해 기술된Presentation Page를 얻을 수 있다. 그 기능에 의해 타깃으로 어플리케이션을 준비할 수 있다.

UPnP 디바이스(UPnP-AV/C 프록시)(2)는, IEEE802 네트워크(12)와 IEEE1394 네트워크(12) 사이의 브릿지로서 기능하며, 내부에 도 3에 도시한 디바이스 모델을 갖는다. 이 예의 디바이스 모델은, 1개의 루트 디바이스(root device)(61)로 구성되며, 이 루트 디바이스(61)는 AV/C 프록시 서비스(AV/C proxy service)(71)와 AV/C 노드 서비스(AV/C nodes service)(72)를 갖고 있다.

AV/C 프록시 서비스(이하, 간단히, 프록시 서비스라 함)(71)는, IEEE1394 네트워크(12)의 버스 리세트 발생, 버스 ID, 노드의 수, 버스 매니저, 등시성 자원 매니저의 노드 유니크 ID(NUID), 갭 카운트(Gap Count), 셀프 ID 패킷(Self ID 패킷) 등을 관리한다.

AV/C 노드 서비스(이하, 간단히 노드 서비스라 함)(72)는 SOAP에 기초한 커맨드와 AV/C에 기초한 커맨드의 변환 처리를 행한다.

도 4는 이 AV/C 커맨드 프레임의 포맷을 나타내고 있다.

CTS 필드에는 커맨드 세트의 종류가 기술된다. 값「0000」은 커맨드 세트가 AV/C 커맨드 세트인 것을 나타낸다.

ctype 필드에는, 그 패킷이 커맨드인지 리스펀스인지, 커맨드인 경우에는 커맨드의 기능 분류, 리스펀스인 경우에는 커맨드의 처리 결과의 분류가 기술된다.

도 5는 이러한 커맨드와 리스펀스의 예를 도시하고 있다. 도 5에 도시한 바와 같이, 커맨드로서는 크게 나누어 4종류의 커맨드가 준비되어 있다.

CONTROL(ctype=0000)은 기능을 외부로부터 제어하는 커맨드이다.

STATUS(ctype=0001)는 외부로부터 상태를 조회하는 커맨드이다.

또한, 제어 커맨드의 서포트의 유무를 외부로부터 조회하는 커맨드로서, GENERAL INQUIRY(ctype=0100)와 SPECIFIC INQUIRY(ctype=0010)가 있다. 전자는, 오피 코드(opcode) 서포트의 유무를 조회하는 커맨드이고, 후자는, 오피코드와 오퍼랜드(operands)의 서포트의 유무를 조회하는 커맨드이다.

NOTIFY(ctype=0011)는 상태의 변화를 외부에 알리도록 요구하는 커맨드이다.

리스펀스는 커맨드의 종별에 따라서 반환된다.

CONTROL 커맨드에 대한 리스펀스로서는, 이하와 같은 것이 있다.

NOT IMPLEMENTED(ctype=1000)는 커맨드가 실장되어 있지 않은 것을 통지한다. ACCEPTED(ctype=1001)는 커맨드가 실행된 것을 통지한다. REJECTED (ctype=1010)는 커맨드를 실행할 수 없었던 것을 통지한다.

INTERIM(ctype=1111)은 커맨드가 처리 중인 것을 통지한다.

STATUS 커맨드에 대한 리스펀스로서는, NOT IMPLEMENTED와 REJECTED 외에, IN TRANSITION과 STABLE이 있다.

IN TRANSITION(ctype=1011)은 스테이터스가 천이 중인 것을 통지한다. STABLE은 스테이터스가 천이 중이 아니라, 안정되어 있는 것을 통지한다.

GENERAL INQUIRY 및 SPECIFIC INQUIRY 커맨드에 대한 리스펀스로서는, IMPLEMENTED와 NOT IMPLEMENTED가 있다. IMPLEMENTED(ctype=1100)는 커맨드가 실장되어 있는 것을 통지한다.

NOTIFY 커맨드에 대한 리스펀스로서는, NOT IMPLEMENTED, REJECTED, INTERIM, CHANGED가 있다.

INTERIM은 NOTIFY가 수취된 것을 먼저 통지한다. CHANGED(ctype=1101)는, 그 후, 타깃의 상태가 변화한 것을 통지한다.

도 4의 AV/C 커맨드 프레임에서의 subunit_type은 커맨드의 수신처를 나타낸다. 그 구체적인 예가 도 6에 도시되어 있다.

즉, subunit_type의 값「00000」은 이 AV/C 커맨드의 수신처(서브 유닛)가 비디오 모니터인 것을 나타낸다. 또한, 값「00101」은 그 수신처가 튜너(Tuner)인 것을 나타낸다.

subunit_type의 값「111l1」은 그 커맨드가 유닛처인 것을 나타낸다. 이에 따라, 예를 들면, 장치의 전원의 온 오프 상태 등이 제어된다.

도 4의 subunit_type 다음에는 subunit_ID가 배치된다. 이 subunit_ID는, 유닛 내에, 동일한 종류의 서브 유닛이 복수개 존재하는 경우의 판별을 행하기 위해 판별 번호로서 이용된다. 따라서, 결국, subunit_type과 subunit_ID의 2개에 의해 커맨드의 수신처가 특정되게 된다.

오피 코드는 명령 동작을 나타내며 오퍼랜드는 명령의 부가적 조건을 나타낸다.

도 6에는, subunit_type이 튜너인 경우의 오피코드의 예가 나타나 있다. 튜너의 오피코드인 경우, 값 C8h는 DIRECT SELECT INFORMATION TYPE을 나타내며, 값 CBh는 DIRECT SELECT DATA를 나타낸다.

이와 같이, 각 서브 유닛마다 오피코드의 테이블이 준비된다. 또한, 각 오피코드마다, 오퍼랜드가 정의된다.

예를 들면, 튜너의 선국이 행해지는 경우, 오피코드는 DIRECT SELECT INFORMATION TYPE으로 되고, 오퍼랜드로 주파수나 채널 번호 등의 파라미터가 지정된다.

다음에, 도 7의 흐름도를 참조하여, IEEE802 네트워크(11)에 접속되어 있는 UPnP 컨트롤 포인트(1)가 IEEE1394 네트워크(12)에 접속되어 있는 기기를 제어하는 처리에 대하여, AV/C 기기(3)의 전원을 온시키는 경우를 예로 하여 설명한다.

단계 S1에서, UPnP 컨트롤 포인트(1)는, UPnP-AV/C 프록시(2)를 구성하는 루트 디바이스(61)의 프록시 서비스(71)에, IEEE1394 네트워크(12)에 변화가 있는 경우, 이것을 통지하도록, 서브 스크라이브(SUBSCRIBE)한다. 단계 S11에서, 프록시 서비스(71)는, 이 서브 스크라이브를 수취하면, 그것에 대응하는 처리를 실행한다.

예를 들면, 지금, AV/C 기기(3)가 단계 S31에서 IEEE1394 네트워크(12)에 접속되었다고 하면, 단계 S32에서 AV/C 기기(3)에 버스 리세트가 발생하고, 마찬가지로, 단계 S21에서 루트 디바이스(61)의 노드 서비스(72)에 버스 리세트가 발생한다. 이 때, 노드 서비스(72)는 단계 S22에서 이 버스 리세트의 발생을 프록시 서비스(71)에 통지한다.

프록시 서비스(71)는, 단계 S12에서 노드 서비스(72)로부터의 통지를 검지하면, 단계 S11에서 취득한 UPnP 컨트롤 포인트(1)로부터의 서브스크라이브에 기초하여, 단계 S13에서 UPnP 컨트롤 포인트(1)에 대하여 AV/C 기기(3)가 IEEE1394 네트워크(12)에 접속된 것을 통지(NOTIFY)한다.

단계 S2에서 UPnP 컨트롤 포인트(1)는 프록시 서비스(71)로부터의 통지를 수취한다. 이에 따라, UPnP 컨트롤 포인트(1)는 IEEE1394 네트워크(12)에 AV/C 기기(3)가 접속된 것을 알 수 있다.

따라서, 단계 S3에서, UPnP 컨트롤 포인트(1)는 AV/C 기기(3)의 소정의 동작을 제어(지금의 경우, AV/C 기기(3)의 전원을 온)하기 위한 커맨드를 기술한, SOAP에 기초한 액션(Action)의 리퀘스트 패킷(request packet)을 인보크(Invoke)한다.

도 8은, 이 때 UPnP 컨트롤 포인트(1)로부터 노드 서비스(72)에 전송되는 메시지의 예를 나타내고 있다. UPnP 컨트롤 포인트(1)는, 노드 서비스(72)가 갖는 후술하는 도 14와 도 15에 도시한 AV/C 노드 서비스 디스크립션(Nodes Service Description)을 참조하여, 이 메시지를 작성한다.

Transaction에 포함되는 숫자「5」는, 커맨드에 대응하여 리스펀스가 반송되어 오므로, 그 리스펀스가 어떤 커맨드에 대응하는 것인지를 인식시키기 위한 라벨로서의 트랜잭션 라벨을 나타내고 있다.

Body에 포함되는 nuid는, 이 메시지의 송신 상대의 노드 유니크 ID(NUID)를 나타낸다. 지금의 예의 경우, AV/C 기기(3)의 NUID「0800460000000000」을 나타낸다. 이 NUID는, 단계 S2의 처리에서, 프록시 서비스(71)로부터 취득한 통지에 기술되어 있던 것이다.

command「00FFB270」은, UPnP 컨트롤 포인트(1)가 노드 서비스(72)에 대하여 발생을 요구하는 AV/C 커맨드의 내용을 나타내고 있다.

command에 포함되는 MSB측의「00FF」(16진수)는, 노드 서비스(72)가 발생하는 도 9에 도시한 AV/C 파워 컨트롤 커맨드(POWER control command)(2진수)에서의 CTS「0000」, ctype「0000」, subunit_type「11111」및 subunit_ID「111」에 대응하고 있다. 즉, 16진수의「00FF」를 2진수로 나타내면,「0000000011111111」로 된다.

다음의「B2」는 오피코드에 대응하고,「70」은 오퍼랜드에 대응한다.

resume「1」은, AV/C 기기(3)가 접속되어 있는 기기에 버스 리세트가 발생한 경우, 이 커맨드에 대응하는 리스펀스의 재송을 AV/C 노드 서비스(72)에 요구하는 것이다. 노드 서비스(72)는, 이 요구를 받은 경우, 버스 리세트를 검지했을 때, 이 커맨드에 대응하는 리스펀스를 재송하는 처리를 행한다.

avcCommandSend는, 이러한 커맨드를, AV/C 커맨드로서 IEEE1394 네트워크(12)에 출력하는 것을 노드 서비스(72)에 요구하는 것이다.

이들 커맨드의 내용을 나타내는 값은 전부 텍스트로 표시되어 있기 때문에, 어떤 종류의 AV/C 커맨드도 기술하는 것이 가능해진다.

도 7로 되돌아가, 노드 서비스(72)는, 단계 S23에서 도 8에 도시한 Action의 인보크를 수취하면, 단계 S24에서 그것에 대응하여 도 9에 도시한 바와 같은 AV/C 커맨드(AV/C POWER control command)를 생성하여, IEEE1394 네트워크(12)를 통하여 AV/C 기기(3)에 송신한다.

AV/C 노드 서비스(72)는, NUID와 노드 ID의 대응표를 생성, 보유하고 있으며, 버스 리세트가 발생할 때마다 그것을 갱신한다. NUID는 이 대응표에 기초하여노드 ID로 변환되고, IEEE1394 네트워크(12)에 전송된다.

AV/C 기기(3)는, 단계 S33에서 노드 디바이스(72)로부터 송신되어 온 AV/C POWER control command를 수신하면, 그 커맨드의 내용에 대응하여, 장치의 전원을 온 시킨다. 그 후, 단계 S34에서 AV/C 기기(3)는 그것에 대응하는 도 10에 도시한 바와 같은 AV/C 리스펀스(AV/C POWER response)를 생성하여, 노드 서비스(72)에 송신한다.

도 10에 도시한 바와 같이, CTS는 도 9의 AV/C POWER control command와 마찬가지로「0000」으로 된다. response는, 도 5에 도시한 바와 같이, ACCEPTED를 나타내는 값「9」(1001)로 된다.

subunit_type과 subunit_ID는, 도 9의 AV/C POWER control command와 동일한 값으로 된다. 즉, 이 경우, 이 값은 송신원을 나타내게 된다.

오피코드와 오퍼랜드도 도 9의 AV/C POWER control command와 동일한 값으로 된다.

노드 서비스(72)는, 단계 S25에서 AV/C 기기(3)로부터 송신되어 온 AV/C POWER response를 수신하면, 단계 S26에서 도 11에 도시한 바와 같은 SOAP 프로토콜에 기초한 Action으로서 Response를 생성하여, UPnP 컨트롤 포인트(1)에 송신한다.

도 11에 도시한 Transaction에 나타내는 값「5」는, 도 8의 Action (Command)과 쌍을 이루는 Action(Responce)인 것을 나타내기 때문에, 도 8에서의 Transaction의 값「5」에 대응하여「5」(동일한 값)로 되어 있다.

AV/C 기기(3)는, 이 커맨드를 수신하면, 그것에 대응하여, 장치의 전원을 온시키고, 단계 S34에서, 도 10에 도시한 바와 같은 AV/C POWER response를 생성하여, 노드 서비스(72)에 송신한다.

노드 서비스(72)는, Transaction의 대응 관계를 유지하기 위한 테이블(대응표)을 생성하고, 보유하고 있다. 즉, 단계 S23에서 도 8에 도시한 AV/C POWER control command를 수신하고, 단계 S24에서 도 9에 도시한 바와 같은 AV/C POWER control command를 출력할 때, 양자가 대응하는 것을 테이블에 기억한다. 따라서, 이 테이블을 참조함으로써, 노드 서비스(72)는, AV/C 기기(3)로부터 도 10에 도시한 AV/C POWER response가 송신되어 왔을 때, 그것이 도 8에 도시한 AV/C POWER control command에 대응하는 리스펀스인 것을 인식할 수 있다.

그리고, 노드 서비스(72)는, 단계 S25에서 AV/C POWER response를 수신하면, 단계 S26에서, 도 11에 도시한 바와 같은 SOAP에 기초한 action의 response를 생성하여, UPnP 컨트롤(1)에 송신한다.

그 response「09FFB270」은, 도 10의 AV/C POWER response에 기술되어 있는 2진수 값「00001001111111111010001001110000」에 대응하고 있다.

UPnP 컨트롤 포인트(1)는, 단계 S4에서, 이 리스펀스를 수신한다. 이에 따라, UPnP 컨트롤 포인트(1)는, AV/C 기기(3)가 장치의 전원을 온시킨 것을 알 수 있다.

AV/C의 규정에 따르면, AV/C 기기는, 수신한 리퀘스트에 대응하는 처리를 즉시 실행할 수 없을 때, INTERIM을 리스펀스로서 반환하는 것이 규정되어 있다. 그AV/C 기기는, 그 후, 그 리퀘스트에 대응하는 처리가 완료했을 때, 그 시점에서 파이널 리스펀스를 리퀘스트의 송신자에게 반환하게 된다.

그러나, 리퀘스트를 수신하고 나서, 파이널 리스펀스가 반환되기까지의 시간은 규정되어 있지 않다. 따라서, 노드 서비스(72)는, 단계 S24의 처리에서 AV/C 기기(3)에 대하여 AV/C 커맨드를 출력한 후, 단계 S25의 처리에서, AV/C 기기(3)로부터 AV/C 리스펀스를 받기까지의 시간을 관리한다. 미리 설정되어 있는 소정의 시간(예를 들면, 30초간) 이내에 리스펀스가 수신된 경우, 그 리스펀스가 INTERIM이 아니면(파이널 리스펀스인 경우), AV/C 노드 서비스(72)는 수신한 리스펀스에 대응하는 리스펀스를 UPnP 컨트롤 포인트(1)에 즉시 전송한다.

이것에 대하여, 수신한 리스펀스가 INTERIM인 경우, AV/C 노드 서비스(72)는 AV/C 커맨드를 송신하고 나서 30초가 경과할 때까지 대기한다. 그리고, 30초가 경과하기 전에, INTERIM 이외의 리스펀스(파이널 리스펀스)가 수신되었을 때, 그 파이널 리스펀스에 대응하는 리스펀스를 출력한다. 30초 이내에 파이널 리스펀스가 수신되지 않은 경우, AV/C 노드 서비스(72)는, INTERIM을 리스펀스로서 출력한다. 이에 따라, UPnP 컨트롤 포인트(1)는 적어도 30초간 이내에 요구한 처리를 완료할 수 있는지의 여부를 알 수 있다.

이상의 처리를 실행하기 위해, 도 3에 도시한 UPnP-AV/C 프록시(2)가 갖는 디바이스 모델의 루트 디바이스(61)는 도 12에 도시한 AV/C Proxy Device Description을 갖고, 프록시 서비스(71)는 도 13에 도시한 AV/C Proxy Service Description을 가지며, 노드 서비스(72)는 도 14와 도 15에 도시한 AV/C NodesService Description을 갖는다.

이들 Description은, 그 기기가 갖는 기능을 실행할 때 필요로 하는 파라미터, 그 밖의 조건을 기술한 것으로, 다른 기기는, 그 기기에 그 기능의 실행을 요구할 때, 그 Description을 참조함으로써, 거기에 기술되어 있는 조건을 부가하여, 그 기기에 커맨드를 보내게 된다.

도 12에서의 deviceType「urn:sony-corp:device:1394ProxyDevice:1」은 루트 디바이스(61)의 형태를 나타내고 있다. FriendlyName「proxy for IEEE1394」는 루트 디바이스(61)의 프렌드리 네임을 나타내고 있다.

UDN「nuid:upnp-1394proxy-root-0800460000000000」은 루트 디바이스(61)의 고유 번호를 나타내고 있다.

이 예에서는, 프록시 서비스(71)와 노드 서비스(72)의 2개의 service가 규정되어 있다.

한쪽 service에서, ServiceType「urn:sony-corp:service:1394ProxyService:1」은 프록시 서비스(71)의 서비스의 형태가 Proxy Service인 것을 나타내며, serviceID「urn:sony-corp:ServiceId:1394ProxyService1」은 프록시 서비스(71)의 고유명을 나타내고 있다.

SCPDURL「./scpd/proxyScpd.xml」은, 프록시 서비스(71)가 갖는 AV/C Proxy Service Description의 URL(구체적으로는, 도 13에 도시한 AV/C proxy Service Description의 URL)을 나타내고 있다.

또한, 다른 쪽 ServiceType「urn:sony-corp:service:1394NodeService:1」은노드 서비스(72)의 서비스 형태가 NodeService인 것을 나타낸다. 이 service의 SCPDURL「./scpd/nodeScpd.xml」은 노드 서비스(72)가 갖는 AV/C Nodes Service Description(구체적으로는, 도 14와 도 15에 도시한 AV/C Nodes Service Description)의 URL을 나타내고 있다.

도 13의 AV/C Proxy Service Description에서의 action은 프록시 서비스(71)가 실행하는 각종 액션을 나타낸다. name「getNodeNum」은 액션의 명칭을 나타낸다. 이 action은 IEEE1394 네트워크(12) 상의 노드의 수를 취득하는 액션이다.

이「getNodeNum」의 action은「nodeNum」의 명칭의 direction이「out」의 인수(그 인수에 다른 기기가 값을 넣고 프록시 서비스(71)에 출력해 나가는 인수)를 갖고 있다.

그리고, 이「nodeNum」인수에 저장되는 변수는, serviceStateTable에 관련성이 규정되어 있다. 즉, 이 변수는, 상태 변수에 변화가 있는 경우, 서브스크라이브하고 있는 기기에 대하여 통지되는 변수이며, 그 형태는「uil」로 된다.

도 14와 도 15의 AV/C Nodes Service Description에는, AV/C 커맨드를 보내는 액션인「avcCommandSend」가 규정되어 있다. 이 커맨드는,「nuid」, 「avcCommand」,「resume」,「inlineNuidPosition」,「inlineNuid」, 및「avcResponse」인수를 갖고 있다. 마지막「avcResponse」는, direction이「out」이므로, 다른 기기로부터 출력되고, 노드 서비스(72)에 보내진다. 이것에 대하여,「avcResponse」를 제외한 5개의 인수는, 그 direction이「in」으로 되어 있으므로, 거기에 값이 세트되고, 노드 서비스(72)로부터 발행되고, 다른 기기에 입력된다.

이들 6개의 인수에는, 모든 관련성이 serviceStatTable에 기술되어 있다. 이들 인수는 stateVariable sendEventes가 no인 경우(변수에 변화가 없는 경우)에 발생되고,「nuid」,「avcCommand」,「inlineNuid」및「avcResponce」는, 모두 그 변수의 형태가「bin.hex」로 된다. 「resume」은, 변수의 형태가「boolean」으로 되고,「inlineNuidPosition」은, 변수의 형태가「uil」로 된다.

도 14에서의「inilineNuid」(삽입된 NUID)와,「inlineNuidPosition」(NUID의 삽입 위치)은, 수신처 기기의 NUID 이외의 NUID를 지정하는 경우에 이용된다(그 커맨드가 다른 AV/C 기기의 NUID를 필요로 하는 경우에 이용된다).

UPnP 컨트롤 포인트(1)는, 이 Description에 따라서 리퀘스트를 보내어 온다. 따라서, 리퀘스트를 수신한 AV/C 기기는, 그 Description의 규정에 기초하여, 리퀘스트를 해석화함으로써 NUID를 검출할 수 있다.

도 16은, 루트 디바이스(61)가 갖는 AV/C Proxy Device Description의 다른 예를 나타내고 있다. 이 예에서도, 프록시 서비스(71)의 ServiceType「urn:sony-corp:service:1394ProxyService:1」과, 노드 서비스(72)의 ServiceTyp e「urn:sony-corp:1394NodeService:1」이 기술되어 있다.

도 16에서, 도시는 생략되어 있지만, serviceId「urn:sony-corp:serviceld:1394ProxyService:1」의 SCPDURL에는, 도 17의 AV/C ProxyService Description의 URL이 기술된다. 또한, serviceId「urn:sony-corp:serviceId:1394NodeService:1」의 SCPDURL에는, 도 18의 AV/CNodesServiceDescripiton의 URL이 기술된다.

도 17은, 프록시 서비스(71)가 갖는 AV/C Proxy Service Description의 다른 예를 나타내고 있다.

도 17의 예에서는, 노드의 수를 취득하는「getNodeNum」의 명칭의 액션이 기술되어 있다.

마찬가지로, 도 18은, 노드 서비스(72)가 갖는 AV/C Nodes Service Descrip tion의 다른 예를 나타내고 있다.

도 18의 예에서는, AV/C 커맨드를 보내는「avcCommandSend」의 액션이 3개의 인수「nuid」,「command」,「response」를 갖도록 규정되어 있다.

이상에서는, 도 3에 도시한 바와 같이, 1개의 루트 디바이스(61)에, 프록시 서비스(71)와 노드 서비스(72)를 보유하도록 하였지만, 예를 들면, 도 19에 도시한 바와 같이, 프록시 서비스(71)를 루트 디바이스(61-1)에 보유시킴과 함께, IEEE1394 네트워크(12) 상의 개개의 노드에 대한 서비스를 각 루트 디바이스마다 정의하도록 할 수도 있다. 도 19의 예에서는, 루트 디바이스(root device)(61-2)에, 노드 서비스(72-1)가 보유되고, 루트 디바이스(61-3)에 노드 서비스(72-2)가 보유된다.

도 20과 도 21은 도 19의 루트 디바이스(61-1 내지 61-3)가 갖는 AV/C Proxy Device Description의 예를 나타내고, 도 22는 도 19의 프록시 서비스(71)가 보유하는 AV/C Proxy Service Description의 예를 나타내며, 도 23은 도 19의 노드 서비스(72-1, 72-2)가 갖는 AV/C Node Service Description의 예를 나타낸다.

도 20과 도 21의 예에서는, deviceType「urn:schemas-upnp-org:device:1394 ProxyDevice:1」이, 루트 디바이스(61-1)에 대응하여 기술되고, deviceType 「urn:sony-corp:device:1394NodeDevice:1」이, 루트 디바이스(61-2)에 대응하여 기술되고, deviceType「urn:sony-corp:device:1394NodeDevice:1」이 루트 디바이스(61-3)에 대응하여 기술되어 있다.

도시는 생략되어 있지만, deviceType「urn:schemas-upnp-org:device:1394 ProxyDevice:1」의 SCPDURL에는, 도 22의 AV/C Proxy Service Description의 URL이 기술되고, deviceType「urn:sony-corp:device:1394ProxyDevice:1」과 deviceType 「urn:sony-corp:device:1394NodeDevice:1」의 SCPDURL에는, 각각 도 23의 AV/C Nodes Service Description의 URL이 기술된다.

도 22에서는, serviceStateTable에「nodeNum」의 변수의 정의가 이루어져 있다. 이 변수의 정의는 Query에 의해 조사할 수 있다.

도 23에서는, AV/C 커맨드를 보내는 액션인「avcCommandSend」가 기술되어 있다.

도 24는, 디바이스 모델의 또 다른 구성 예를 나타낸다. 이 예에서는, 도 19의 예와 마찬가지로, 노드 서비스(72-1, 72-2)가 노드마다 설정되어 있지만, 도 19의 예와 달리, 이들 서비스는 전부 프록시 서비스(71)와 함께 1개의 루트 디바이스(61)에 보유되어 있다.

도 25는 도 24의 예에서의 루트 디바이스(61)가 갖는 AV/C Proxy Device Description의 구성을 나타내고, 도 26은 도 24의 프록시 서비스(71)가 보유하는AV/C Proxy service Description의 구성 예를 나타내며, 도 27은 도 24의 노드 서비스(72-1, 72-2)가 갖는 AV/C Node Service Description의 구성 예를 나타낸다.

도 25의 예에서는, 3개의 서비스가 규정되어 있는 serviceId「urn:sony-corp:serviceId:1394ProxyService1」의 SCPDURL에는, 도 26의 AV/C Proxy Service Description의 URL이 기술되고, serviceId「urn:sony-corp:serviceId:1394 NodeService1」과,「urn:sony-corp:serviceId:1394 NodeService2」의 SPCDURL에는, 도 27의 AV/C Node Service Description의 URL이 기술된다.

도 26의 예에서는,「nodeNum」의 변수가 규정되어 있다.

도 27의 예에서는, AV/C 커맨드를 보내는 액션이 규정되어 있다.

도 28은 디바이스 모델의 또 다른 구성 예를 도시하고 있다. 이 구성 예에서는, 루트 디바이스(61)에 프록시 서비스(71)가 보유되어 있다. 또한, 노드 서비스(72-1, 72-2)는, 각각 노드마다 설치되며, 루트 디바이스(61)의 내부에 형성된 임베디드 디바이스(embedded device)(81-1, 81-2)에 각 보유된다. 도 29와 도 30은 도 28에서의 루트 디바이스(61)가 보유하는 AV/C Proxy Device Description의 구성 예를 나타내고, 도 31은 도 28의 프록시 서비스(71)가 보유하는 AV/C Proxy Service Description의 구성 예를 나타내며, 도 32는 도 28의 노드 서비스(72-1, 72-2)가 갖는 AV/C Node Service Description의 구성 예를 나타낸다.

도 29와 도 30의 예에서, serviceId「urn:sony-corp:serviceId:1394Pro xyService1」은 도 28의 프록시 서비스(71)에 대응하고, 그 SCPDURL에는 도 31의 AV/C Proxy Service Description의 URL이 기술된다.

serviceId「urn:sony-corp:serviceId:1394NodeService1」은, 도 28의 AV/C 노드 서비스(72-1)에 대응하고,「urn:sony-corp:serviceId:1394NodeService2」는, AV/C 노드 서비스(72-2)에 대응하며, 각각의 SCPDURL에는 도 32의 AV/C node Service Description의 URL이 기술된다.

도 31의 예에서는,「NODE Num」의 변수가 정의되어 있다.

도 32의 예에서는, AV/C 커맨드를 보내는 액션「avcCommandSend」가 규정되어 있다.

다음에, 도 3, 도 19, 도 24 및 도 28에 도시한 디바이스 모델을 비교한다.

도 3의 예에서는, 1개의 루트 디바이스(61)에 프록시 서비스(71)와 노드 디바이스(72)가 각각 하나씩 정의된다.

도 19의 예에서는, 프록시 서비스(71)가 하나의 루트 디바이스(61-1)에 정의됨과 함께, 1394 상의 개개의 노드에 대한 노드 서비스(72-1, 72-2)가 루트 디바이스(61-2, 61-3)마다 정의된다.

도 24의 예에서는, 프록시 서비스(71)가 1개의 루트 디바이스(61)에 설정되는 외에, 노드 서비스가 각 노드마다 대응하여 설정되고, 이들 노드 서비스(72-1, 72-2)는 프록시 서비스(71)와 마찬가지로 1개의 루트 디바이스(61)에 보유된다.

도 28의 예에서는, 1394 상의 노드가 전부 루트 디바이스(61)의 임베디드 디바이스(81-1, 81-2)로서 정의된다.

도 33은, 도 3, 도 19, 도 24 및 도 28의 디바이스 모델의 특징의 비교 결과를 나타내고 있다. 또, 도 33에서 타입 A, 타입 B, 타입 C 및 타입 D는 각각 도3, 도 19, 도 24 또는 도 28의 디바이스 모델에 대응하고 있다.

타입 A부터 타입 D까지를 비교하면, SSDP의 패킷량이 크게 다른 것을 알 수 있다. 즉, 루트 디바이스가 1개일 때, SSDP의 수는, 3+2d+k로 된다. 여기서, d는 임베디드 디바이스의 수, k는 서비스 타입의 수를 의미한다. 따라서, 1394 네트워크(12) 상의 노드의 수를 N으로 할 때, SSDP의 패킷의 양은, 타입 A일 때 5개, 타입 B일 때 4+4N개, 타입 C일 때 4+N개, 타입 D일 때 4+3N개로 된다. 특히, 타입 B(도 19)와 타입 D(도 28)인 경우에는, 노드 수의 수배가 되는 수의 패킷이 흐르게 된다. 따라서, 네트워크의 트래픽의 관점에서 고려한 경우, SSDP의 패킷의 양이 적은 타입 A(도 3)의 예가 바람직하다.

버스의 구성의 변경 통지는, 타입 A인 경우 GENA에 의해 행해지고, 타입 B, C, D인 경우 SSDP에 의해 행해진다.

프리젠테이션 URL의 구성의 단위는, 타입 A와 타입 C가 버스 단위로 되고, 타입 B와 타입 D가 노드 단위로 된다. 노드마다 URL을 갖는 것이 가능한 타입 B(도 19)와 타입 D(도 28)가 알기 쉽지만, 타입 A(도 3)와 타입 C(도 24)에 관해서도, 프록시 서비스(71)가 각 노드에 대한 링크 페이지 같은 것을 준비하면, 실질적으로 대응하는 기능을 실현할 수 있다고 생각된다.

N0TIFY의 통지의 단위는, 타입 A인 경우 버스 단위로 되고, 타입 B, C, D 인 경우 노드 단위로 된다.

이상을 통합하면, 타입 A(도 3)의 예가 최적이라고 생각된다.

이상에서는, IEEE802 네트워크(11)에 접속되어 있는 기기가, IEEE1394 네트워크(12)에 접속되어 있는 기기를 제어하도록 하였지만, 후자가 전자를 제어하는 것도 가능하다.

상술한 일련의 처리는, 하드웨어에 의해 실행시킬 수도 있지만, 소프트웨어에 의해 실행시킬 수도 있다. 일련의 처리를 소프트웨어에 의해 실행시키는 경우에는, 그 소프트웨어를 구성하는 프로그램이, 전용의 하드웨어에 내장되어 있는 컴퓨터, 또는, 각종 프로그램을 인스톨함으로써, 각종 기능을 실행하는 것이 가능한, 예를 들면 범용의 퍼스널 컴퓨터 등에, 네트워크나 기록 매체로부터 인스톨된다.

이 기록 매체는 도 2에 도시한 바와 같이, 장치 본체와는 별도로, 사용자에게 프로그램을 제공하기 위해서 배포되는, 프로그램이 기록되어 있는 자기 디스크(41)(플로피 디스크를 포함), 광 디스크(42)(CD-ROM(Compact Disk-Read Only Memory), DVD(Digital Versatile Disk)를 포함), 광 자기 디스크(43)(MD(Mini-Disk)를 포함), 혹은 반도체 메모리(44) 등으로 이루어지는 패키지 미디어로 구성될 뿐만 아니라, 장치 본체에 사전에 내장된 상태로 사용자에게 제공되는, 프로그램이 기록되어 있는 ROM(22)이나 기억부(28)에 포함되는 하드디스크 등으로 구성된다.

또, 본 명세서에 있어서, 기록 매체에 기록되는 프로그램을 기술하는 단계는, 기재된 순서를 따라서 시계열적으로 행해지는 처리는 물론, 반드시 시계열적으로 처리되지 않더라도 병렬적 혹은 개별로 실행되는 처리도 포함하는 것이다.

또한, 본 명세서에 있어서, 시스템이란, 복수의 장치에 의해 구성되는 장치 전체를 나타내는 것이다.

이상과 같이, 본 발명에 따르면, IEEE802에 기초한 제1 네트워크로부터의 SOAP에 기초한 커맨드를 제2 네트워크의 AV/C 커맨드로 변환하도록 하였으므로, 간단하고 또한 확실하게, 제1 네트워크에 접속되어 있는 기기로부터 제2 네트워크에 접속되어 있는 기기를 제어하는 것이 가능해진다.

Claims

IEEE802의 SOAP에 기초한 제1 포맷으로 통신하는 제1 네트워크와 IEEE1394의 AV/C 커맨드에 기초한 제2 포맷으로 통신하는 제2 네트워크 사이에서 데이터를 수수하는 정보 처리 장치에 있어서,

상기 제1 네트워크로부터의 상기 제1 포맷의 데이터를 취득하는 취득 수단과,

상기 취득 수단에 의해 취득된 상기 제1 포맷의 상기 SOAP에 기초한 커맨드를 상기 제2 네트워크의 상기 AV/C 커맨드로 변환하여 상기 제2 포맷으로 저장하는 변환 수단과,

상기 변환 수단에 의해 변환된 상기 제2 포맷을 상기 제2 네트워크에 송신하는 송신 수단

을 포함하는 것을 특징으로 하는 정보 처리 장치.
제1항에 있어서,

상기 변환 수단은, 상기 SOAP에 기초한 커맨드에 기술되어 있는 상기 제2 네트워크에 접속되어 있는 기기를 지정하는 노드 유니크 ID와 노드 ID의 대응표를 갖고, 상기 SOAP에 기초한 커맨드에 기술되어 있는 상기 제2 네트워크에 접속되어 있는 기기를 지정하는 노드 유니크 ID를, 상기 대응표에 기초하여 노드 ID로 변환하는 것을 특징으로 하는 정보 처리 장치.
제1항에 있어서,

상기 변환 수단은, 상기 SOAP에 기초한 커맨드와 그것에 기초하여 상기 제2 네트워크에 송신되는 커맨드와의 대응표를 갖고, 상기 제2 네트워크를 통하여 수신된 리스펀스에 대응하는 상기 SOAP에 기초한 커맨드를 상기 대응표에 기초하여 검색하고, 상기 SOAP에 기초한 커맨드에 대응하는 리스펀스를 상기 제1 네트워크에 송신하는 것을 특징으로 하는 정보 처리 장치.
제3항에 있어서,

상기 변환 수단은, 상기 SOAP에 기초한 커맨드에 포함되는 트랜잭션 라벨에 기초하여, 상기 SOAP에 기초한 커맨드와 리스펀스를 대응시키는 것을 특징으로 하는 정보 처리 장치.
제1항에 있어서,

상기 변환 수단은, 상기 제1 네트워크에 접속되어 있는 기기로부터의 리퀘스트에 대응하는 파이널 리스펀스가 사전에 정해져 있는 시간 내에 상기 제2 네트워크에 접속되어 있는 기기로부터 수신되지 않을 때, 상기 제1 네트워크에 접속되어 있는 기기에 대하여 처리 중인 것을 나타내는 리스펀스를 송신하는 것을 특징으로 하는 정보 처리 장치.
제1항에 있어서,

상기 SOAP에 기초한 커맨드가 상기 제2 네트워크의 버스 리세트 시에 재송을 요구하는 커맨드인 경우, 상기 제2 네트워크의 버스 리세트를 검지하여, 상기 제2 네트워크에 버스 리세트가 발생했을 때, 상기 커맨드를 송신하는 검지 수단을 더 포함하는 것을 특징으로 하는 정보 처리 장치.
제1항에 있어서,

상기 변환 수단은, 또한 상기 제2 네트워크의 상기 AV/C 커맨드를 상기 제1 포맷의 상기 SOAP에 기초한 커맨드로 변환하여 상기 제1 포맷으로 저장하고,

상기 송신 수단은, 또한 상기 변환 수단에 의해 변환된 상기 제1 포맷의 상기 SOAP에 기초한 커맨드를 상기 제1 네트워크에 송신하는 것을 특징으로 하는 정보 처리 장치.
IEEE802의 SOAP에 기초한 제1 포맷으로 통신하는 제1 네트워크와, IEEE1394의 AV/C 커맨드에 기초한 제2 포맷으로 통신하는 제2 네트워크 사이에서 데이터를 수수하는 정보 처리 장치의 정보 처리 방법에 있어서,

상기 제1 네트워크로부터의 상기 제1 포맷의 데이터를 취득하는 취득 단계와,

상기 취득 단계의 처리에 의해 취득된 상기 제1 포맷의 상기 SOAP에 기초한 커맨드를, 상기 제2 네트워크의 상기 AV/C 커맨드로 변환하여 상기 제2 포맷으로저장하는 변환 단계와,

상기 변환 단계의 처리에 의해 변환된 상기 제2 포맷을 상기 제2 네트워크에 송신하는 송신 단계

를 포함하는 것을 특징으로 하는 정보 처리 방법.
IEEE802의 SOAP에 기초한 제1 포맷으로 통신하는 제1 네트워크와, IEEE1394의 AV/C 커맨드에 기초한 제2 포맷으로 통신하는 제2 네트워크 사이에서 데이터를 수수하는 정보 처리 장치의 프로그램으로서,

상기 제1 네트워크로부터의 상기 제1 포맷의 데이터를 취득하는 취득 단계와,

상기 취득 단계의 처리에 의해 취득된 상기 제1 포맷의 상기 SOAP에 기초한 커맨드를 상기 제2 네트워크의 상기 AV/C 커맨드로 변환하여 상기 제2 포맷으로 저장하는 변환 단계와,

상기 변환 단계의 처리에 의해 변환된 상기 제2 포맷을 상기 제2 네트워크에 송신하는 송신 단계

를 포함하는 것을 특징으로 하는 컴퓨터 판독 가능한 프로그램이 기록되어 있는 기록 매체.
IEEE802의 SOAP에 기초한 제1 포맷으로 통신하는 제1 네트워크와 IEEE1394의 AV/C 커맨드에 기초한 제2 포맷으로 통신하는 제2 네트워크 사이에서 데이터를 수수하는 정보 처리 장치를 제어하는 컴퓨터에,

상기 제1 네트워크로부터의 상기 제1 포맷의 데이터를 취득하는 취득 단계와,

상기 취득 단계의 처리에 의해 취득된 상기 제1 포맷의 상기 SOAP에 기초한 커맨드를 상기 제2 네트워크의 상기 AV/C 커맨드로 변환하여 상기 제2 포맷으로 저장하는 변환 단계와,

상기 변환 단계의 처리에 의해 변환된 상기 제2 포맷을 상기 제2 네트워크에 송신하는 송신 단계

를 실행시키는 프로그램.