WO2002096037A1 - Appareil de traitement d'informations - Google Patents

Appareil de traitement d'informations Download PDF

Info

Publication number
WO2002096037A1
WO2002096037A1 PCT/JP2002/004835 JP0204835W WO02096037A1 WO 2002096037 A1 WO2002096037 A1 WO 2002096037A1 JP 0204835 W JP0204835 W JP 0204835W WO 02096037 A1 WO02096037 A1 WO 02096037A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
command
format
soap
ieee
Prior art date
Application number
PCT/JP2002/004835
Other languages
English (en)
French (fr)
Inventor
Takuro Noda
Makoto Sato
Yukihiko Aoki
Hisato Shima
Original Assignee
Sony Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corporation filed Critical Sony Corporation
Priority to KR10-2003-7001005A priority Critical patent/KR20030024806A/ko
Priority to EP02726442A priority patent/EP1300989A1/en
Publication of WO2002096037A1 publication Critical patent/WO2002096037A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40091—Bus bridging
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge

Definitions

  • the present invention relates to an information processing apparatus, and in particular, a device connected to a first network based on IEEE 802 controls a device connected to a second network based on IEEE 1394
  • the present invention relates to an information processing device that can perform the information processing. Background art
  • IEEE 1394 networks networks using the IEEE 1394 high-speed serial bus (hereinafter simply referred to as IEEE 1394 networks) have become widespread. By connecting audio and video devices to this IEEE1394 network, each device can control other devices using AV / C commands.
  • IEEE 802 networks are also widespread.
  • This IEEE 802 is a network mainly for connecting personal computers to each other, and each personal computer controls another personal computer based on the uPnP (Universal Plag and Play) protocol. be able to.
  • uPnP Universal Plag and Play
  • the IEEE 1394 network and the IEEE 802 network are independent from each other, and devices connected to the IEEE 802 network (hereinafter referred to as UPnP devices) are 1 394
  • UPnP devices devices connected to the IEEE 802 network
  • AV / C devices devices connected to the network
  • An information processing apparatus includes: a capturing unit that captures data in a first format from a first network; and a command based on a SOAP of the first format captured by the capturing unit. And a transmitting means for transmitting the second format converted by the converting means to the second network.
  • the conversion means has a correspondence table between a node unique ID and a node ID that specifies a device connected to the second network described in the command based on SOAP, and a conversion table described in the command based on SOAP. Node unique IDs that specify devices connected to the second network can be converted to node IDs based on the correspondence table.
  • the conversion means has a correspondence table between a command based on SOAP and a command transmitted to the second network based on the command, and the command based on SOAP corresponding to the response received via the second network. And a response corresponding to a command based on the SOAP can be transmitted to the first network based on the correspondence table.
  • the conversion means can associate a SOAP-based command with a response based on a transaction label included in the SOAP-based command.
  • the conversion means when a final response corresponding to a request from a device connected to the first network is not received from a device connected to the second network within a predetermined time, A response indicating that processing is in progress can be transmitted to the device connected to the first network.
  • the transmitting means may further be provided.
  • the conversion means further converts the AV / C command of the second network into a command based on the SOAP of the first format and stores it in the first format, and the transmitting means is further converted by the conversion means.
  • a command based on the first format SOAP can be transmitted to the first network.
  • the information processing method includes a capturing step of capturing data of a first format from a first network, and a command based on a SOAP of a first format captured by the processing of the capturing step.
  • the recording medium program includes a capturing step of capturing data of a first format from a first network, and a command based on the SOAP of the first format captured by the processing of the capturing step.
  • the program of the present invention includes a capturing step of capturing data of a first format from a first network, and a command based on a SOAP in a first format captured by the processing of the capturing step.
  • a conversion step of converting the data into an AV / C command and storing it in the second format, and a transmission step of transmitting the second format converted by the processing of the conversion step to the second network are executed.
  • FIG. 1 is a diagram showing a configuration of a network system to which the present invention is applied.
  • FIG. 2 is a block diagram showing the configuration of the UPnP device 2 in FIG.
  • FIG. 3 is a diagram showing a configuration of a device model of the UPnP device 2 in FIG. 1 c .
  • FIG. 4 is a diagram showing a configuration of an AV / C command frame.
  • FIG. 5 is a diagram illustrating ctype.
  • FIG. 6 is a diagram illustrating a subunit-type.
  • FIG. 7 is a flowchart for explaining the processing of the network system in FIG. 1.
  • FIG. 8 is a diagram showing the configuration of a command output in step S3 in FIG.
  • FIG. 9 is a diagram showing a configuration of a command output in the process of step S24 in FIG.
  • FIG. 10 is a diagram showing the configuration of the response output in the process of step S34 in FIG.
  • FIG. 11 is a diagram showing an example of a response output in the process of step 26 in FIG.
  • FIG. 12 is a diagram showing a configuration of an AV / C Proxy Device Description having gl 3 ⁇ root device power S.
  • FIG. 13 is a diagram showing a configuration of an AV / C Proxy Service Description having a proxy service S of FIG.
  • FIG. 14 is a diagram showing the configuration of the AV / C Nodes Service Description that has the 13394 nodes service of FIG.
  • FIG. 15 is a diagram showing the configuration of the AV / C Nodes Service Description that has the 13394 nodes service of FIG.
  • FIG. 16 is a diagram showing another configuration of the AV / C Proxy Device Description having the root device power S of FIG.
  • FIG. 17 is a diagram showing another configuration of the AV / C Proxy Service Description having the proxy service S of FIG.
  • FIG. 18 is a diagram showing another configuration of the AV / C Nodes Service Description having the 1394 nodes service capability S of FIG.
  • FIG. 19 is a diagram showing another configuration of the device model.
  • FIG. 20 is a diagram showing the configuration of the AV / C Proxy Device Description having the root device power S shown in FIG.
  • FIG. 21 is a diagram showing the configuration of the AV / C Proxy Device Description having the root device power S shown in FIG.
  • FIG. 22 is a diagram showing a configuration of the AV / C Proxy Service Description of the 1394 proxy service in FIG.
  • FIG. 23 is a diagram showing a configuration of an AV / C Node Service Descriptor having the AV / C node service shown in FIG.
  • FIG. 24 is a diagram showing still another configuration of the device model.
  • FIG. 25 is a diagram showing the configuration of the AV / C Proxy Device Description having the root device power S of FIG.
  • FIG. 26 is a diagram showing the configuration of the AV / C Proxy Service Description having the AV / C proxy service capability S of FIG.
  • FIG. 27 is a diagram showing the configuration of the AV / C Node Service Description having the AV / C node service capability S of FIG.
  • FIG. 28 is a diagram illustrating another configuration of the device model.
  • FIG. 29 is a diagram showing the configuration of the AV / C Proxy Device Description of FIG. 28 having root device power S.
  • FIG. 30 is a diagram showing the configuration of the AV / C Proxy Device Description having the ⁇ root device power S shown in FIG.
  • FIG. 31 is a diagram showing the configuration of the AV / C Proxy Service Description having the AV / C proxy service capability S of FIG.
  • FIG. 32 is a diagram showing the configuration of the AV / C Node Service Descriptor having the AV / C node service shown in FIG.
  • FIG. 33 is a diagram showing a comparison of device models. BEST MODE FOR CARRYING OUT THE INVENTION
  • FIG. 1 shows a configuration of a network system to which the present invention is applied.
  • a UPnP control point is connected to the IEEE 802 network 11.
  • AV / C devices 3 and 4 are connected to the IEEE 1394 network 12.
  • the IEEE 802 network 11 and the IEEE 1394 network 12 are connected to a UPnP device (UPnP-AV / C proxy) 2, respectively.
  • FIG. 2 illustrates a configuration example of the UPnP device 2.
  • CPU Central Processing Unit
  • ROM Read Only Memory
  • FIG. 2 illustrates a configuration example of the UPnP device 2.
  • CPU Central Processing Unit
  • ROM Read Only Memory
  • the RAM 23 also stores data necessary for the CPU 21 to execute various types of processing, as appropriate.
  • the CPU 21 s R0M 22 and the RAM 23 are interconnected via a bus 24.
  • An input / output interface 25 is also connected to the bus 24.
  • the input / output interface 25 includes an input unit 26 composed of a keyboard, a mouse, etc., a display composed of a CRT S LCD, an output unit 27 composed of a speaker, a storage unit 28 composed of a hard disk, a modem, a terminal Communication unit 29 composed of an adapter etc. is connected.
  • the communication unit 29 performs communication processing via the IEEE 802 network 11 or the IEEE 1394 network 12.
  • a drive 30 is connected to the input / output interface 25 as necessary, and a magnetic disk 41, an optical disk 42, a magneto-optical disk 43, or a semiconductor memory 44, etc. are mounted as appropriate and read from them.
  • the installed computer program is installed in the storage unit 28 as necessary.
  • UPnP devices (in the example of FIG. 1, UPnP control point 1 and UPnP device 2) are mainly used for addressing, discovery, and de- vice. It has six functions: Description, Control, Eventing, and Presentation. Each UPnP device uses an IEEE 802 network 11 This is a function to obtain the address above, and uses DHCP (Dynamic Host Configuration Protocol) or AutoIP.
  • DHCP Dynamic Host Configuration Protocol
  • AutoIP AutoIP
  • UPnP control point 1 is performed after addressing, so that UPnP control point 1 can find the target device that you want to control.
  • the protocol used here is SSDP (Simple Service Discovery Protocol).
  • SSDP Simple Service Discovery Protocol
  • each device When connected to the IEEE 802 network 11, each device multicasts a message on the IEEE 802 network 11 to notify its own devices and services. Send packets).
  • UP n p Control Poin sheet 1 the Mano retinyl by receiving the cast message, the IEEE 8 0 2 network 1 1, what kind of device is connected can known Rukoto.
  • the UPnP control point 1 can also check the devices currently connected to the IEEE 802 network 11. At this time, the UPnP control point 1 multicasts a search command on the IEEE 802 network 11 using the device or service to be discovered as a keyword. If each device connected to the IEEE802.11 network 11 itself satisfies the conditions specified in the multicast search command, it performs a multicast response to the search command (the other party). Specify the side and send the packet). This allows the UPnP control point 1 to detect devices connected to the IEEE 802 network 11.
  • each device broadcasts that fact beforehand even when it deviates from the IEEE 802 network 11.
  • the SSDP bucket output by the device to be controlled discovered by UPnP control point 1 by the discovery includes a device description (Device Description).
  • cription) URL Uniform Resource Locator
  • UPnP control point 1 can obtain more detailed device information of the device from the device description by accessing the URL.
  • This device information includes icon information, model name, producer name, and product name.
  • the device information describes the service information of the device, and a service description (Service Description) that describes detailed information of the service is also obtained from the URL described in the service information. You can enter.
  • Service Description Service Description
  • the UPnP control point 1 can know how to access the target by using the device information (Device Description) and the service information (Service Description).
  • Controls are broadly classified into two types: actions and queries.
  • the Action is performed by the method specified in the action information of the Service Description.
  • the Action By invoking the Action, the UPnP controller node 1 can operate the target.
  • Query is used to retrieve the value of stateVariable of Service Description.
  • the value of stateVariable indicates the state of the device.
  • Control uses a transport protocol called SOAP (Simple Object Access Protocol).
  • SOAP Simple Object Access Protocol
  • XML is used as the expression language. .
  • Eventing is used to notify the UPnP control point 1 from the target when the value of stateVariable changes.
  • UPnP Control 1 is to analyze the Service Description
  • the variables held by the target can be known from the stateVariable.
  • UPnP control point 1 can receive a notification from the target when a change is made to any of the variables for which sendEvents is set to yes. it can.
  • Eventing uses a transport protocol called GENA (General Event Notification Architecture).
  • XML is used as the expression language.
  • Presentation is used to provide a user with control means using a user interface (UI).
  • UI user interface
  • UI user interface
  • HTML Hyper Text Markup Language
  • the UPnP device (UPnP-AV / C proxy) 2 functions as a bridge between the IEEE 802 network 11 and the IEEE 1394 network 12, and internally has the device model shown in Fig. 3. Having.
  • the device model consists of one root device 61, which consists of an AV / C proxy service 71 and an AV / C node service. (AV / C nodes ser vice) 72
  • proxy service 71 1 is a bus reset, bus ID, number of nodes, bus manager, and isochronous resource manager of IEEE 1394 network 12. It manages the node unique ID (NUID), gap count (Gap Count), and self ID packet (Self ID packet).
  • NUID node unique ID
  • Gap Count gap count
  • Self ID packet self ID packet
  • node service 72 converts commands based on S0AP and commands based on AV / C.
  • Fig. 4 shows the format of this AV / C command frame.
  • the type of command set is described in the CTS field.
  • the value “0 0 0 0” indicates that the command set is an AV / C command set.
  • the ctype parameter describes whether the packet is a command or a response, if it is a command, the function classification of the command, and if it is a response, the classification of the processing result of the command.
  • Figure 5 shows an example of such a command and response. As shown in the figure, there are roughly four types of commands.
  • the response is returned according to the command type.
  • STATUS command includes NOT IMPLEMENTED and REJECTED, as well as IN TRANSITION and STABLE.
  • Responses to the NOTIFY command include NOT IMPLEMENTED, REJECTED, INTERIM, and CHANGED.
  • INTERIM will first notify that the NOTIFY has been accepted.
  • Subunit_type in AV / C command frame shown in FIG. 4 c Specific examples representing the destination of the command is shown in FIG.
  • the value “0 0 0 0 0” of the subunit_type indicates that the destination (subunit) of the AV / C command is a Video Monitor.
  • the value “0 0 0 1 1” indicates that the destination is Tuner.
  • “1 1 1 1 1” in the subunit—type column indicates that the command is addressed to the unit. This controls, for example, the power on / off of the device.
  • Subunit_ID is placed next to subunit_type in FIG. This subunit_ID is used as a discrimination number for discriminating a case where a plurality of subunits of the same type exist in the unit. Therefore, the destination of the command is ultimately specified by the submiit_type and subunit_ID.
  • the opcode indicates the instruction operation, and the operand indicates the additional condition of the instruction.
  • Fig. 6 shows an example of opcode when scbunit_type is Tuner.
  • the value C 8 h indicates DIRECT SELECT INFORMATION TYP ⁇
  • the value C B h indicates DIRECT SERECT DATA.
  • an opcode table is prepared for each subunit.
  • operand power S is defined for each opcode.
  • the opcode is DIRECT SELECT INF0RMATION TYPE, and parameters such as frequency and channel number are specified by operand.
  • the UPnP control point 1 connected to the IEEE 802 network 11 connects to the IEEE 1394 network 12
  • step S1 the UPnP control point 1 changes the proxy service 71 of the root device 61 constituting the UPnP-AV / C proxy 2 to the IEEE 1394 network 12 if there is a change. SUBSCRIBE to notify you.
  • step S11 when receiving the subscribe, the proxy service 71 executes a process corresponding to the subscribe.
  • a bus reset occurs in the AV / C device 3 in step S32.
  • a bus reset occurs in the node service 72 of the root device 61.
  • the node service 72 notifies the proxy service 71 of the occurrence of the bus reset in step S22.
  • the proxy service 71 detects the UPnP in step S13 based on the subscription from the UPnP control point 1 captured in step S11. Notify control point 1 that AV / C device 3 has been connected to IEEE 1394 network 12 (NOTIFY).
  • step S2 the UPnP control point 1 receives the notification from the proxy service 71. This allows the UPnP control point 1 to know that the AV / C device 3 has been connected to the IEEE 1394 network 12. Therefore, in step S3, the UPnP control point 1 describes a command for controlling a predetermined operation of the AV / C device 3 (in this case, turning on the power of the AV / C device 3). Invoke request packet of Action based on.
  • FIG. 8 shows an example of a message transferred from the UPnP control point 1 to the node service 72 at this time.
  • UPnP control point 1 This message is created with reference to the AV / C Nodes Service Description shown in FIG. 14 and FIG.
  • the number “5” included in the Transaction indicates a transaction label as a label for recognizing which command the response corresponds to since the response is returned in response to the command. .
  • the nuid included in the Body indicates the node unique ID (NUID) of the transmission destination of this message.
  • NUID node unique ID
  • the NUID of the AV / C device 3 is “0 8 004 6 000 000 000 0”. This NUID is described in the notification obtained from the proxy service 71 in the processing of step S2.
  • the command “00FFB270” indicates the content of the AV / C command that the UPnP control point 1 requests the node service 72 to generate.
  • the “0 0 FF” (1 hexadecimal number) on the MSB side included in the command is the CTS “0 000” and ctype “c” in the AV / C POWER control command (binary number) shown in FIG. 9 where the node service 72 is generated. 0 0 00 ”, subunit—type“ 1 1 1 1 1 ”, and subunit_ID“ 1 1 1 ”. That is, if "0 0 FF" of the hexadecimal number is represented by a binary number, it becomes "0 0 0 00 00 0 0 1 1 1 1 1 1 1”.
  • resume “1” requests the AV / C node service 72 to retransmit a response corresponding to this command when a bus reset occurs in the device to which the AV / C device 3 is connected.
  • the node service 72 when detecting a bus reset, performs a process of resending a response corresponding to this command.
  • the avcCommandSend converts such a command into an AV / C command as an IEEE 13 94 requests the node service 72 to output to the network 12. Since all the values representing the contents of these commands are expressed in text, any type of AV / C command can be described.
  • step S23 when the node service 72 receives the action invocation shown in FIG. 8 in step S23, it responds to it in step S24. Then, an AV / C power control command as shown in FIG. 9 is generated and transmitted to the AV / C device 3 via the IEEE1394 / network 12.
  • the AV / C node service 72 generates and holds a correspondence table between NUID and node ID, and updates it every time a bus reset occurs.
  • the NUID is converted into a node ID based on this correspondence table, and transferred to the IEEE 1394 network 12.
  • the AV / C device 3 Upon receiving the AV / C POWER control command transmitted from the node device 72 in step S33, the AV / C device 3 turns on the power of the device in accordance with the content of the command. Then, in step S34, the AV / C device 3 generates an AV / C response (AV / C POWER response) as shown in FIG. 10 corresponding to the AV / C device 3, and transmits it to the node service 72.
  • AV / C POWER response AV / C POWER response
  • the CTS is set to “0000” as in the AV / C POWER control command of FIG.
  • the response is a value “9” (1001) representing ACCEPTED, as shown in FIG.
  • the subunit-type and subunit-ID have the same value as the AV / C POWER control com ⁇ d in Fig. 9. That is, in this case, this value indicates the transmission source.
  • the opcode and ope d are also the same value as the AV / C POWER control command in Fig. 9. 'The node service 72 sends the AV / C power transmitted from the AV / C device 3 in step S25. When the response is received, a response is generated as an action based on the S0AP protocol as shown in FIG. 11 and transmitted to the UPnP control point 1 in step S26.
  • Fig. 11 1 The Transaction shown here is the "5". In order to indicate that it is the Action (Responce) that is the counterpart to the Action (Command) in Fig. 8, the value of "Transaction” in Fig. 8 is “5". "5" (same value) corresponding to "".
  • the AV / C device 3 Upon receiving this command, the AV / C device 3 turns on the power of the device in response to this command, and generates an AV / C POWER response as shown in FIG. Send to service 72.
  • the node service 72 generates and holds a table (correspondence table) for holding the correspondence between Transactions. That is, when the AV / C POWER control command shown in FIG. 8 is received in step S23 and the AV / C POWER control command shown in FIG. 9 is output in step S24, the two correspond to each other. Is stored in the table. Therefore, by referring to this table, when the AV / C power response shown in FIG. 10 is transmitted from the AV / C device 3, the node service 72 transmits the AV / C power response shown in FIG. It can recognize that it is a response corresponding to the control command.
  • the node service 72 upon receiving the AV / C POWER response in step S25, the node service 72 generates a response of the action based on the SOAP as shown in FIG. 11 in step S26, and transmits it to the UPnP control 1. I do.
  • the response “09 FFB 270” corresponds to the binary value “0000100 1 1 1 1 1 1 1 1 1 10 1000 1001 1 10000” described in the AV / C POWER response in FIG.
  • UPnP control point 1 receives this response in step S4. This allows the UPnP control point 1 to know that the AV / C device 3 has turned on the power of the device.
  • an AV / C device is required to return INTERIM as a response when it cannot immediately execute the processing corresponding to the received request.
  • the AV / C device will return a final response to the sender of the request at that time.
  • the node service 72 outputs an AV / C command to the AV / C device 3 in the process of step S24, and then outputs the AV / C response from the AV / C device 3 in the process of step S25.
  • Manage time to receive If a response is received within a preset time (for example, 30 seconds), if the response is not INTERIM (if it is a final response), The C node service 72 immediately transfers the response corresponding to the received response to the UPnP control point 1.
  • the AV / C node service 72 waits until 30 seconds have elapsed after transmitting the AV / C command. If a response (final response) other than INTERIM is received before 30 seconds have elapsed, the response corresponding to the final response is output. If no final response is received within 30 seconds, the AV / C node service 72 outputs INTERIM as a response. As a result, the UPnP control point 1 can know whether or not the requested processing can be completed within at least 30 seconds.
  • the root device 61 of the device model of the UPnP-AV / C proxy 2 shown in FIG. 3 has the AV / C Proxy Device Description shown in FIG. 71 has an AV / C Proxy Service Description shown in FIG. 13, and a node service 72 has an AV / C Nodes Service Description shown in FIGS. 14 and 15.
  • the deviceType “urn: sony-cor: device: 1394ProxyDevice: 1” in FIG. 12 represents the type of the root device 61.
  • FriendlyName "proxy for IEEE1394J indicates the friendly name of the root device 61.
  • ServiceType “urn: sony-corp: service: 1394ProxyService vice: 1 J” indicates that the service type of the proxy service 71 is Proxy Service
  • servicelD “urn: sony—corp: ServiceId: 1394ProxyServicel ” represents the unique name of the proxy service 71.
  • the SCPDURL “./scpd/proxyScpd.xml” is the URL of the AV / C Proxy Service Description of the proxy service 71 (specifically, the URL / UR of the AV / C Proxy Service Description shown in Figure 13). Show and show.
  • the other ServiceType "urn: sony-corp: service: 1394NodeService: 1J" indicates that the service type of the node service 72 is NodeService.
  • SCPDURL "./scpd/nodeScpd.xml" of this service Represents the URL of the AV / C odes Service Description (specifically, the AV / C Nodes Service Description shown in FIGS. 14 and 15) of the node service 72.
  • the action in the AV / C Proxy Service Description in FIG. 13 represents various actions executed by the proxy service 71.
  • name “getNodeNumj indicates the name of the action. This action is an action that obtains the number of nodes on the IEEE1394 network 12.
  • variables stored in the “n.deNum” argument are associated with the serviceStateTable.
  • this variable is a variable that is notified to subscribed devices when there is a change in the status variable, and its type is “ui l”.
  • the AV / C Nodes Service Description in Fig. 14 and Fig. 15 specifies "avcCommandSendJ" which is an action to send AV / C command.
  • This command is "nu id”, “avcCommand”, “; resumej , "InlineNuidPositionJ”, “inlineNuid”, and “avcResponse”.
  • the last "ResponseJ is direct Since the ion is "outj", it is output from another device and sent to the node service 72.
  • the five arguments except “avcResponse” have the direction "in” The value is set there, issued from the node service 72, and input to another device.
  • FIG. 16 shows another example of an AV / C Proxy Device Description having 61 root devices.
  • the service type “urn: sony-corp: service: 1394Proxy Service: 1 J” of the proxy service 7 1 and the service type “urn: sony_corp: 1394Node Service: 1” of the node service 7 2 are also described.
  • the SCPDURL of the serviceld “urn: sony—corp: serviceId: 1394ProxyServicel” is the URL of the AV / C Proxy Service Description in Fig. 17. Force, eyes ⁇ described.
  • FIG. 17 shows another example of the AV / C Proxy Service Description of the proxy service 71.
  • a function named “getNodeNum” for acquiring the number of nodes is described.
  • FIG. 18 illustrates another column of the AV / C Nodes Service Description of the node service 72.
  • the action force of “avcCotmnandSend” for sending an AV / C command is defined to have three arguments “nuid”, “command”, and “; responsej”.
  • one root device 61 holds the proxy service 71 and the node service 72.
  • the service 71 may be held in the root device 61-1, and the service for each node on the IEEE1394 network 12 may be defined for each root device.
  • the node service 72-1 is held in the norm device (root device) 61-2
  • the node service 72-2 is held in the root device 61-3.
  • FIGS. 20 and 21 show examples of AV / C Proxy Device Descriptions possessed by the root devices 61-1 to 61-3 in FIG. 19, and
  • FIG. 22 shows AV / C Proxy Device Descriptions held by the proxy service 71 in FIG.
  • An example of the C Proxy Service Description is shown.
  • Fig. 2'3 shows an example of the / C Node Service Description of the node service 72-1, 72-2 in Fig. 19.
  • deviceType device urn scheraas-upnp-org ' ⁇ device: 1394ProxyDevice: 1 ”is described corresponding to the root device 6 1—1 and deviceType“ u: rn: sony— corp: device: 1394NodeDevice: 1 ”, root device 6 1—2, and deviceType“ urn: sony— corp: device: 1394NodeDevice: 1 ” Have been.
  • the device type "urn: scheraas-upnp-org-device” 1 ⁇ 94ProxyDevice: lJ SCPDURU is described in the URL 51 of the AV / C Proxy Service Description in FIG. urn: sony-corp: device: 1394ProxyDevice: 1 "and device The SCPDURU of Type “urrT-sony-corp: device: 1394NodeDevice: l” is described in the URL of the AV / C Nodes Service Description in Figure 23.
  • variable “nodeNum” is defined in the serviceStateTable. The definition of this variable can be checked by Query.
  • FIG. 24 shows still another configuration example of the device model.
  • node services 72-1, 72-2 are provided for each node.
  • the proxy service 71 are held in one root device 61.
  • FIG. 25 shows the configuration of the AV / C Proxy Device Description of the root device 61 in the example of FIG. 24, and FIG. 26 shows the AV / C Proxy service held by the proxy service 71 of FIG. Fig. 27 shows a configuration example of the AV / C Node Service Description of the node services 72-1, 72-2 in Fig. 24.
  • the SCPDURL of serviceld "urn: sony-corp: serviceld: 1394ProxyServicel” that defines three services is the URL of the AV / C Proxy Service Description in Fig. 26.
  • the SPCDURU of serviceld “urn: sony—corp: serviceld: 139 4NodeServicel” and “urn: sony-corp: serviceld: 1394NodeService2j” are described in the URI of the AV / C Node Service Description in FIG. 27.
  • FIG. 28 shows still another configuration example of the device model.
  • the proxy service 71 is held in the root device 61.
  • the node services 72-1 and 72-2 are provided for each node, and embedded devices 81-1-1, 8 formed inside the root device 61. 1 and 2 are held respectively.
  • FIGS. 29 and 30 show a configuration example of the AV / C Proxy Device Description held by the root device 61 in FIG. 28, and
  • FIG. 31 shows the AV held by the proxy service 71 in FIG. Fig. 32 shows a configuration example of the AV / C Node Service Description of the node services 72-1, 72-2 in Fig. 28.
  • serviceld ur urn '-sony-corp' serviceld'-l394ProxyServicelJ corresponds to the proxy service 71 in FIG. 28, and its SCPDURL is URL / S of AV / C Proxy Service Description
  • one proxy service 71 and one node device 72 are defined for one root device 61, respectively.
  • the proxy service 7 1 is defined in one root device 6 1-1 and the node services 7 2 — 1, 7 2 — 2 root for each node on 1 3 9 4 device 6 1–2, 6 1–3 are defined for each.
  • the proxy service 71 is provided in one root device 61, and the node services are provided correspondingly to each node, and the node services 7 2—1 and 7 2 — 2 is stored in one root device 61 as in proxy service 71.
  • FIG. 33 shows the results of comparing the features of the device models of Figures 3, 19, 24, and 28.
  • type A, type B, type C, and type D correspond to the device model of FIG. 3, FIG. 19, FIG. 24, or FIG. 28, respectively.
  • the SSDP packet amount is significantly different. That is, when the number of root devices is one, the number of SSDPs is 3 + 2d + k.
  • d means the number of embedded devices
  • k means the number of service types. Therefore, assuming that the number of nodes on the 1 3 9 4 network 1 2 is N, the amount of SS DP packets is 5 for type A, 4 + 4 N for type B, and 4 for type C. + N, 4 + 3 N for type D.
  • the number of packets will be several times the number of nodes. Therefore, from the viewpoint of network traffic, an example of type A (Fig. 3) with a small amount of SSDP packets is desirable.
  • Notification of a change in the path configuration is made by GENA in the case of type A, and is made by SSDP in the case of types B, C, and D.
  • the units of the configuration of the presentation URL are type A and type C as bus units, and type B and type D as node units.
  • Type B ( Figure 19) and Type D ( Figure 28), which can have a URL for each node, are easy to understand, but for Type A ( Figure 3) and Type C ( Figure 24), the proxy service It is considered that if 71 prepares something like a link page for each node, the corresponding function can be realized substantially.
  • the NOTIFY notification unit is a bus unit for type A, and a node unit for types B, C, and D.
  • the devices connected to the IEEE 802 network 11 are controlled from the devices connected to the IEEE 802 network 11, but the former must be controlled from the latter. Is also possible.
  • the series of processes described above can be executed by hardware, but can also be executed by software.
  • the programs that make up the software execute various functions by installing a computer built into a dedicated hard disk or by installing various programs. It can be installed on a general-purpose personal computer from a network or a recording medium.
  • the recording medium is distributed separately from the main body of the apparatus to provide the program to the user.
  • the magnetic disk 41 including the floppy disk
  • the optical disk 42 including CD-ROM (Compact Disk-Read Only Memory), DVD (Digital Versatile Disk)
  • magneto-optical disk 43 including MD (Mini-Disk)
  • package media consisting of semiconductor memory 44 R0M22, which stores the program, and the hard disk included in the storage unit 28, etc., which is provided to the user in a state in which it is not only built in the main body of the device but also in the device main body.
  • steps for describing a program to be recorded on a recording medium are not limited to processing performed in chronological order according to the described order, but are not necessarily performed in chronological order. Alternatively, it also includes processes that are individually executed.
  • system refers to an entire device including a plurality of devices.
  • a command based on S0AP from the first network based on IEEE 802 is converted into an AV / C command on the second network, so that it is simple and reliable.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Small-Scale Networks (AREA)
  • Selective Calling Equipment (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Communication Control (AREA)

Description

明細書
技術分野
本発明は、 情報処理装置に関し、 特に、 IEEE 8 0 2に基づく第 1のネットヮー クに接続されている機器が、 IEEE 1 3 9 4に基づく第 2のネットワークに接続さ れている機器を制御することができるようにした、 情報処理装置に関する。 背景技術
最近、 IEEE unstitute of Electrical and Electronics Engineers) 1 3 9 4高速シリアルバスを用いたネットワーク （以下、 単に IEEE 1 3 9 4ネットヮー クと称する） が普及してきた。 オーディオ機器やビデオ機器を、 この IEEE 1 3 9 4ネットワークに接続することで、 各機器は、 AV/Cコマンドを用いて、 他の機器 を制御することができる。
一方、 IEEE 8 0 2ネットワークも普及している。 この IEEE 8 0 2は、 主にパー ソナルコンピュータを相互に接続するためのネットワークであり、 uPnP (Univer sal Plag and Play) のプロ トコルに基づいて、 各パーソナルコンピュータは、 他のパーソナルコンピュータを制御することができる。
し力 しながら、 この IEEE 1 3 9 4ネットワークと IEEE 8 0 2ネットワークとは、 それぞれ独立したものであり、 IEEE 8 0 2ネットワークに接続されている機器 （ 以下、 UPnP機器と称する） は、 IEEE 1 3 9 4ネットワークに接続されている機器 (以下、 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に基づくコマンドを、 対応表に基づいて検索レ、 SO APに基づくコマンドに対応するレスポンスを第 1のネットワークに送信すること ができる。
前記変換手段は、 SOAPに基づくコマンドに含まれるトランザクションラベルに 基づいて、 SOAPに基づくコマンドとレスポンスを対応させることができる。
前記変換手段は、 第 1のネットワークに接続されている機器からのリクエスト に対応するファイナルレスポンスが、 予め定められている時間内に、 第 2のネッ トワークに接続されている機器から受信されないとき、 第 1のネットワークに接 続されている機器に対して処理中であることを表すレスポンスを送信することが できる。
前記 S0APに基づくコマンドが、 第 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のネットワークに送信する送 信ステップとを実行させる。
本発明の情報処理装置および方法、 記録媒体、 並びにプログラムにおいては、
IEEE 8 0 2に基づく第 1のネットワークからの S0APに基づくコマンドが、 第 2の ネットワークの AV/Cコマンドに変換される。 図面の簡単な説明 図 1は、 本発明が適用されるネットワークシステムの構成を示す図である。
図 2は、 図 1の UPnPデバイス 2の構成を示すブロック図である。
図 3は、 図 1の UPnPデバイス 2が有するデバイスモデルの構成を示す図である c 図 4は、 AV/Cコマンドフレームの構成を示す図である。
図 5は、 ctypeを説明する図である。
図 6は、 subunit— typeを説明する図である。
図 7は、 図 1のネットワークシステムの処理を説明するフローチヤ一トである c 図 8は、 図 7のステップ S 3において出力されるコマンドの構成を示す図であ る。
図 9は、 図 7のステップ S 2 4の処理で出力されるコマンドの構成を示す図で ある。
図 1 0は、 図 7のステップ S 3 4の処理で出力されるレスポンスの構成を示す 図である。
図 1 1は、 図 7のステップ 2 6の処理で出力されるレスポンスの例を示す図で ある。
図 1 2は、 gl 3 ©root device力 S有する AV/C Proxy Device Descriptionの構成 を示す図である。
図 1 3は、 図 3の 1 3 9 4 proxy service力 S有する AV/C Proxy Service Descr iptionの構成を示す図である。
図 1 4は、 図 3の 1 3 9 4 nodes serviceカ有する AV/C Nodes Service Descr iptionの構成を示す図である。
図 1 5は、 図 3の 1 3 9 4 nodes serviceカ有する AV/C Nodes Service Descr iptionの構成を示す図である。
図 1 6は、 図 3の root device力 S有する AV/C Proxy Device Descriptionの他の 構成を示す図である。
図 1 7は、 図 3の 1 3 9 4 proxy service力 S有する AV/C Proxy Service Descr iptionの他の構成を示す図である。 図 1 8は、 図 3の 1 3 9 4 nodes service力 S有する AV/C Nodes Service Descr iptionの他の構成を示す図である。
図 1 9は、 デバイスモデノレの他の構成を示す図である。
図 2 0は、 図 1 9の root device力 S有する AV/C Proxy Device Descriptionの構 成を示す図である。
図 2 1は、 図 1 9の root device力 S有する AV/C Proxy Device Descriptionの構 成を示す図である。
図 2 2は、 図 1 9の 1 3 9 4 proxy serviceが有する AV/C Proxy Service Des criptionの構成を示す図.である。
図 2 3は、 図 1 9の AV/C node serviceカ有する AV/C Node Service Descripti onの構成を示す図である。
図 2 4は、 デバイスモデルのさらに他の構成を示す図である。
図 2 5は、 図 2 4の root device力 S有する AV/C Proxy Device Descriptionの構 成を示す図である。
図 2 6は、 図 2 4の AV/C proxy service力 S有する AV/C Proxy Service Descrip tionの構成を示す図である。
図 2 7は、 図 2 4の AV/C node service力 S有する AV/C Node Service Descripti onの構成を示す図である。
図 2 8は、 デバイスモデルの他の構成を示す図である。
図 2 9は、 図 2 8の； root device力 S有する AV/C Proxy Device Descriptionの構 成を示す図である。
図 3 0は、 図 2 8 ©root device力 S有する AV/C Proxy Device Descriptionの構 成を示す図である。
図 3 1は、 図 2 8の AV/C proxy service力 S有する AV/C Proxy Service Descrip tionの構成を示す図である。
図 3 2は、 図 2 8の AV/C node serviceカ有する AV/C Node Service Descripti onの構成を示す図である。 図 3 3は、 デバイスモデルの比較を示す図である。 発明を実施するための最良の形態
図 1は、 本発明を適用したネットワークシステムの構成を表している。 この構 成においては、 IEEE 8 0 2ネットワーク 1 1に、 UPnPコントロールポイント 1力 S 接続されている。 IEEE 1 3 9 4ネットワーク 1 2には、 AV/C機器 3， 4が接続さ れている。 IEEE 8 0 2ネットワーク 1 1と、 IEEE 1 3 9 4ネットワーク 1 2は、 UPnPデバイス （UPnP- AV/Cプロキシ） 2にそれぞれ接続されている。
図 2は、 UPnPデバイス 2の構成例を表している。 図 2において、 CPU (Central Processing Unit) 2 1 ま、 ROM (Read Only Memory) 2 2 こ記'慮されて ヽるプ ログラム、 または記憶部 2 8力 ら RAM (Random Access Memory) 2 3にロードさ れたプログラムに従って各種の処理を実行する。 RAM 2 3にはまた、 CPU 2 1が各 種の処理を実行する上において必要なデータなども適宜記憶される。
CPU 2 1 s R0M 2 2、 および RAM 2 3は、 バス 2 4を介して相互に接続されてい る。 このバス 2 4にはまた、 入出力インタフェース 2 5も接続されている。
入出力インタフェース 2 5には、 キーボード、 マウスなどよりなる入力部 2 6 CRTS LCDなどよりなるディスプレイ、 並びにスピーカなどよりなる出力部 2 7、 ハードディスクなどより構成される記憶部 2 8、 モデム、 ターミナルアダプタな どより構成される通信部 2 9が接続されている。 通信部 2 9は、 IEEE 8 0 2ネッ トワーク 1 1または IEEE 1 3 9 4ネットワーク 1 2を介しての通信処理を行う。 入出力インタフェース 2 5にはまた、 必要に応じてドライブ 3 0が接続され、 磁気ディスク 4 1、 光ディスク 4 2、 光磁気ディスク 4 3、 或いは半導体メモリ 4 4などが適宜装着され、 それらから読み出されたコンピュータプログラムが、 必要に応じて記憶部 2 8にインス トーノレされる。
UPnP機器 （図 1の例の場合、 UPnPコントロ一ルポィント 1および UPnPデバイス 2 ) は、 主に、 アドレシング （Addressing) 、 ディスカバリ （Discovery) 、 デ イスクリプシヨン （Decription) 、 コントローノレ (Control) 、 ィべンティング (Eventing) 、 プレゼンテーション （Presentation) の 6つの機能を有している, ァドレシングは、 各 UPnP機器が、 IEEE 8 0 2ネットワーク 1 1上でァドレスを 取得するための機能であり、 DHCP (Dynamic Host Configuration Protocol) ま たは AutoIPが用いられる。
デイスカバリは、 ァドレシングの後に行われ、 これにより UPnPコントロールポ イント 1は、 コントロールしたいターゲット機器を発見することができる。 ここ で用いられるプロ卜コルは、 SSDP (Simple Service Discovery Protocol) であ る。 各機器は、 IEEE 8 0 2ネットワーク 1 1に接続されたとき、 自分自身の中に 有するデバイスやサービスを通知するメッセージを IEEE 8 0 2ネットワーク 1 1 上にマルチキャストする （特に、 相手を指定しないでパケットを送信する） 。 UP npコントロールポィント 1は、 このマノレチキャストされたメッセージを受信する ことで、 IEEE 8 0 2ネットワーク 1 1に、 どのような機器が接続されたのかを知 ることができる。
逆に、 UPnPコントロールポイント 1の方から、 現在 IEEE 8 0 2ネットワーク 1 1に接続されている機器を調べることもできる。 このとき、 UPnPコントロールポ イント 1は、 発見したいデバイスやサービスをキーワードとして、 検索コマンド を IEEE 8 0 2ネットワーク 1 1上にマルチキャストする。 IEEE 8 0 2ネットヮー ク 1 1に接続されている各機器は、 マルチキャストされた検索コマンドに規定さ れている条件に自分自身が適合する場合、 その検索コマンドに対してレスポンス をュニキャス トする （相手側を指定して、 パケットを送信する） 。 これにより、 UPnPコントロールポイント 1は、 IEEE 8 0 2ネットワーク 1 1に接続されている 機器を検知することができる。
また、 各機器は、 IEEE 8 0 2ネットワーク 1 1から外れるときも、 事前にその 旨をブロードキャストする。
ディスカバリにより UPnPコントロールポイント 1が発見したコントロール対象 の機器が出力した SSDPバケツトには、 デバイスディスクリプション （Device Des cription) の URL (Uniform Resource Locator) カ記述されてレヽる。 UPnPコン卜 ロールポイント 1は、 その URLにアクセスすることにより、 その機器のさらに詳 しいデバイス情報をデバイスディスクリプションから得ることができる。 このデ バイス情報には、 アイコン情報、 モデル名、 生産者名、 商品名などが含まれてい る。
また、 このデバイス情報には、 そのデバイスが有するサービス情報が記述され ており、 そのサービスの詳しい情報が記述されているサービスディスクリプショ ン （Service Description) も、 サービス情報に記述されている URLから迪ること ができる。
UPnPコントロールポイント 1は、 これらのデバイス情報 （Device Description ) やサービス情報 （Service Description) 力ゝら、 ターゲットに対するアクセス の方法を知ることができる。
また、 デバイスディスクリプシヨンには、 後述する Presentation URLも記述さ れている。
Device Descriptionおよび Service Descriptionは、 XML (Extensible Markup Language) で表現されている。
Controlは、 アクション （Action) とクエリー （Query) の 2つに大きく分類さ れる。 Actionは、 Service Descriptionのアクション情報に規定された方法で行 われ、 Actionを Invokeすることにより、 UPnPコントローノレポイント 1は、 ターグ ットを操作することができる。
一方、 Queryは、 Service Descriptionの stateVariableの値を取り出すために 用いられる。 stateVariableの値は、 機器の状態を表している。
Controlでは、 SOAP (Simple Object Access Protocol) という トランスポート プロ トコルが利用される。 その表現言語としては、 XMLが用いられる。 .
ィベンティング （Eventing) は、 stateVariableの値が変更されたとき、 その ことをターゲットカ ら、 UPnPコントロールポイント 1に通知させるために用いら れる。 UPnPコントロ一ノレポィント 1は、 Service Description を解析することに より、 stateVariableからターゲットの保持する変数を知ることができる。 UPnP コントロールポィント 1はターゲットに対して、 Subscriptionを出力しておくこ とにより、 その変数のうち、 sendEventsが yesになっている変数に関して、 変数 の変更があつたとき、 ターゲットから通知を受け取ることができる。 Eventingで は、 GENA (General Event Notification Architecture) という トランスポート プロ トコルが利用される。 その表現言語としては、 XMLが用いられる。
プレゼンテーション (Presentation) は、 ユーザにユーザィンタフェース (UI ) を用いたコントロール手段を提供するために用いられる。 Device Description に記述された Presentation URLにアクセスすることで、 HTML (Hyper Text Marku p Language) によって記述された Presentation Pageを得ることができる。 その 機能により、 ターゲットでアプリケーションを用意することができる。
UPnPデバイス （UPnP-AV/Cプロキシ） 2は、 IEEE 8 0 2ネットワーク 1 1と IEE E 1 3 9 4ネットワーク 1 2との間のブリッジとして機能し、 内部に、 図 3に示 されるデバイスモデルを有する。 この例のデバイスモデルは、 1個のルートデバ イス （root device) 6 1で構成され、 このルートデバイス 6 1は、 AV/Cプロキ シサービス （AV/C proxy service) 7 1と AV/Cノードサービス （AV/C nodes ser vice) 7 2とを有している。
AV/Cプロキシサービス （以下、 単に、 プロキシサービスと称する） 7 1は、 IE EE 1 3 9 4ネッ トワーク 1 2のバスリセッ ト発生、 バス ID、 ノードの数、 バスマ ネージャ、 ァイソクロナスリソースマネージャのノードユニーク ID (NUID) 、 ギ ヤップカウント （Gap Count) 、 セルフ IDパケット （Self IDパケット） などを管 理する。
AV/Cノードサービス （以下、 単にノードサービスと称する） 7 2は、 S0APに基 づくコマンドと、 AV/Cに基づくコマンドの変換処理を行う。
図 4は、 この AV/Cコマンドフレームのフォーマットを表している。
CTSフィールドには、 コマンドセッ トの種類が記述される。 その値の 「0 0 0 0」 は、 そのコマンドセットが AV/Cコマンドセットであることを表す。 ctypeブイ一ノレドには、 そのパケットがコマンドであるのか、 レスポンスであ るのか、 コマンドである場合にはコマンドの機能分類、 レスポンスである場合に はコマンドの処理結果の分類が記述される。
図 5は、 このようなコマンドとレスポンスの例を表している。 同図に示される ように、 コマンドとしては、 大きく分けて 4種類のコマンドが用意されている。
CONTROL (ctype= 0 0 0 0 ) は、 機能を外部から制御するコマンドである。
STATUS (ctype= 0 0 0 1 ) は、 外部から状態を問い合わせるコマンドである。 さらに、 制御コマンドのサポートの有無を外部から問い合わせるコマンドとし て、 GENERAL INQUIRY (ctype= 0 1 0 0 ) と SPECIFIC INQUIRY (ctype= 0 0 1 0 ) がある。 前者は、 opcodeサポートの有無を問い合わせるコマンドであり、 後 者は、 opcodeと operandsのサポートの有無を問い合わせるコマンドである。
NOTIFY (ctype= 0 0 1 1 ) は、 状態の変化を外部に知らせるように要求する コマンドである。
レスポンスは、 コマンドの種別に応じて返される。
CONTROLコマンドに対するレスポンスとしては、 以下のようなものがある。
NOT IMPLEMENTED (ctype= 1 0 0 0 ) は、 コマンドが実装されていないことを 通知する。 ACCEPTED (ctype= 1 0 0 1 ) は、 コマンドが実行されたことを通知 する。 REJECTED (ctype= 1 0 1 0 ) は、 コマンドが実行できなかったことを通 知する。 - INTERIM (ctype= 1 1 1 1 ) は、 コマンドが処理中であることを通知する。
STATUSコマンドに対するレスポンスとしては、 NOT IMPLEMENTEDと REJECTEDの 他、 IN TRANSITIONと STABLEがある。
IN TRANSITION (ctype= 1 0 1 1 ) は、 ステータスが遷移中であることを通知 する。 STABLEはステータスが遷移中でなく、 安定していることを通知する。
GENERAL INQUIRYおよぴ SPECIFIC INQUIRYコマンドに対するレスポンスとして は、 IMPLEMENTEDと NOT IMPLEMENTEDがある。 IMPLEMENTED (ctype= 1 1 0 0 ) は、 コマンドが実装されていることを通知する。 NOTIFYコマンドに対するレスポンスとしては、 NOT IMPLEMENTED, REJECTED, I NTERIM, CHANGEDがある。
INTERIMは、 NOTIFYが受け付けられたことをまず通知する。 CHANGED (ctype = 1 1 0 1 ) は、 その後、 ターゲットの状態が変化したことを通知する。
図 4の AV/Cコマンドフレームにおける subunit_typeは、 コマンドの宛先を表す c その具体的な例が、 図 6に示されている。
すなわち、 subunit_typeの値の 「0 0 0 0 0」 は、 この AV/Cコマンドの宛先 （ サブユニット） 力 Video Monitorであることを表す。 また、 その値の 「0 0 1 0 1」 は、 その宛先が Tunerであることを表す。
subunit— typeのィ直の 「1 1 1 1 1」 は、 そのコマンドはユニット宛であること を表す。 これにより、 例えば、 装置の電源のオンオフなどが制御される。
図 4の subunit_typeの次には、 subunit_IDが配置される。 この subunit_IDは、 ュニット内に、 同じ種類のサブュニットが複数個存在する場合の判別を行うため に、 判別番号として用いられる。 従って、 結局、 submiit_typeと subunit_IDの 2 つにより、 コマンドの宛先が特定されることになる。
opcodeは命令動作を表し、 operandは命令の付加的条件を表す。
図 6には、 scbunit_typeが Tunerである場合における opcodeの例が表されてい る。 Tunerの opcodeの場合、 その値の C 8 hは、 DIRECT SELECT INFORMATION TYP Εを表し、 その値の C B hは、 DIRECT SERECT DATAを表す。
このように、 各 subunit毎に、 opcodeのテーブルが用意される。 また、 各 opcod e毎に、 operand力 S定義される。
例えば、 チューナの選局が行われる場合、 opcodeは、 DIRECT SELECT INF0RMAT ION TYPEとされ、 operandで周波数やチャンネル番号などのパラメータが指定さ れる。
次に、 0 7のフローチャートを参照して、 IEEE 8 0 2ネットワーク 1 1に接続 されている UPnPコントロールポイント 1が、 IEEE 1 3 9 4ネットワーク 1 2に接 続されている機器を制御する処理について、 AV/C機器 3の電源をオンさせる場合 を例として説明する。
ステップ S 1において、 UPnPコントロールポイント 1は、 UPnP-AV/Cプロキシ 2を構成するルートデバイス 6 1のプロキシサービス 7 1に、 IEEE 1 3 9 4ネッ トワーク 1 2に変化があった場合、 これを通知してくれるように、 サプスクライ プ （SUBSCRIBE) する。 ステップ S 1 1において、 プロキシサービス 7 1は、 こ のサプスクライブを受け取ると、 それに対応する処理を実行する。
例えば、 今、 AV/C機器 3がステップ S 3 1において、 IEEE 1 3 9 4ネットヮー ク 1 2に接続されたとすると、 ステップ S 3 2において、 AV/C機器 3にバスリセ ットが発生し、 同様に、 ステップ S 2 1において、 ルートデバイス 6 1のノード サービス 7 2に、 バスリセットが発生する。 このとき、 ノードサービス 7 2は、 ステップ S 2 2において、 このバスリセッ トの発生を、 プロキシサービス 7 1に 通知する。
プロキシサービス 7 1は、 ステップ S 1 2において、 ノードサービス 7 2から の通知を検知すると、 ステップ S 1 1において取り込んだ UPnPコントロールポィ ント 1からのサブスクライブに基づいて、 ステップ S 1 3において、 UPnPコント ロールポィント 1に対して、 AV/C機器 3が IEEE 1 3 9 4ネットワーク 1 2に接続 されたことを通知 （NOTIFY) する。
ステップ S 2において、 UPnPコントロールポイント 1は、 プロキシサービス 7 1力、らの通知を受け取る。 これにより、 UPnPコントロールポイント 1は、 IEEE 1 3 9 4ネットワーク 1 2に AV/C機器 3が接続されたことを知ることができる。 そこで、 ステップ S 3において、 UPnPコントロールポイント 1は、 AV/C機器 3 の所定の動作を制御する （いまの場合、 AV/C機器 3の電源をオンする） ためのコ マンドを記述した、 SOAPに基づく Actionの request packetをインボーク (Invoke ) する。
図 8は、 このとき UPnPコントロールポィント 1からノードサービス 7 2に転送 されるメッセージの例を表している。 UPnPコントロールポイント 1は、 ノードサ 一ビス 7 2が有する、 後述する図 1 4と図 1 5に示される AV/C Nodes Service D escriptionを参照して、 このメッセージを作成する。
Transactionに含まれる数字 「5」 は、 コマンドに対応してレスポンスが返送 されてくるので、 そのレスポンスがどのコマンドに対応するものであるのかを認 識させるためのラベルとしてのトランザクションラベルを表している。
Bodyに含まれる nuidは、 このメッセージの送信相手のノードユニーク ID (NUID ) を表す。 今の例の場合、 AV/C機器 3の NUID 「0 8 004 6 000 000 000 0」 を表す。 この NUIDは、 ステップ S 2の処理で、 プロキシサービス 7 1から取 得した通知に記述されていたものである。
command 「00 F F B 2 70」 は、 UPnPコントロールポィント 1がノードサ一 ビス 7 2に対して発生を要求する AV/Cコマンドの内容を表している。
commandに含まれる MSB側の 「0 0 F F」 （ 1 6進数） は、 ノードサービス 7 2 が発生する図 9に示される AV/C POWER control command (2進数） における CTS 「0 000」 、 ctype 「0 0 00」 、 subunit— type 「 1 1 1 1 1」 、 並びに subun it_ID 「 1 1 1」 に対応している。 すなわち、 1 6進数の 「0 0 F F」 を 2進数 で表すと、 「0 0 0 0 00 0 0 1 1 1 1 1 1 1 1」 になる。
次の 「B 2」 は opcodeに対応し、 「7 0」 は、 operandに対応する。
resume 「1」 は、 AV/C機器 3が接続されている機器にバスリセットが発生した 場合、 このコマンドに対応するレスポンスの再送を、 AV/Cノードサービス 7 2に 要求するものである。 ノードサービス 7 2は、 この要求を受けた場合、 バスリセ ットを検知したとき、 このコマンドに対応するレスポンスを再送する処理を行う avcCommandSendは、 このようなコマンドを、 AV/Cコマンドとして IEEE 1 3 9 4 ネットワーク 1 2に出力することをノードサービス 7 2に要求するものである。 これらのコマンドの内容を表す値は全てテキストで表されているため、 どの種 類の AV/Cコマンドも記述することが可能となる。
図 7に戻って、 ノードサービス 7 2は、 ステップ S 2 3において、 図 8に示さ れる Actionのインポークを受け取ると、 ステップ S 24において、 それに対応し て、 図 9に示されるような AV/Cコマンド （AV/C POWER control command) を生成 し、 IEEE 1 3 9 4·ネットワーク 1 2を介して AV/C機器 3に送信する。
AV/Cノードサービス 7 2は、 NUIDとノード IDの対応表を生成、 保持しており、 バスリセット発生の度にそれを更新する。 NUIDは、 この対応表に基づいてノード IDに変換され、 IEEE 1 3 9 4ネットワーク 1 2に転送される。
AV/C機器 3は、 ステップ S 3 3において、 ノードデバイス 7 2より送信されて きた AV/C POWER control commandを受信すると、 そのコマンドの内容に対応して、 装置の電源をオンする。 その後、 ステップ S 3 4において、 AV/C機器 3は、 それ に対応する図 1 0に示されるような AV/Cレスポンス （AV/C POWER response) を 生成し、 ノードサービス 7 2に送信する。
図 1 0に示されるように、 CTSは、 図 9の AV/C POWER control commandと同様 に 「0 0 0 0」 とされる。 responseは、 図 5に示されるように、 ACCEPTEDを表す 値 「9」 （1 0 0 1 ) とされる。
subunit一 typeと subunit— IDは、 図 9の AV/C POWER control com瞧 dと同一の値 とされる。 すなわち、 この場合、 この値は、 送信元を表すことになる。
opcodeと ope進 dも、 図 9の AV/C POWER control commandと同一の値とされる ' ノードサービス 7 2は、 ステップ S 2 5において、 AV/C機器 3から送信されて きた AV/C POWER responseを受信すると、 ステップ S 2 6において、 図 1 1に示 されるような S0APプロトコ/レに基づく Actionとして Responseを生成し、 UPnPコン トロールポイント 1に送信する。
図 1 1 こ示される Transactionこ示されるィ直 「5」 ίま、 図 8の Action (Command ) と対をなす Action (Responce) であることを表すために、 図 8における Transa ctionの値 「5」 に対応して 「5」 （同一の値） とされている。
AV/C機器 3は、 このコマンドを受信すると、 それに対応して、 装置の電源をォ ンし、 ステップ S 3 4で、 図 1 0に示されるような AV/C POWER responseを生成 し、 ノードサービス 7 2に送信する。 ノードサービス 72は、 Transactionの対応関係を保持するためのテーブル （ 対応表） を生成し、 保持している。 すなわち、 ステップ S 23において、 図 8に 示される AV/C POWER control commandを受信し、 ステップ S 24において、 図 9 に示されるような AV/C POWER control commandを出力するとき、 両者が対応する ものであることをテーブルに記憶する。 従って、 このテーブルを参照することで、 ノードサービス 72は、 AV/C機器 3から図 10に示される AV/C POWER response が送信されてきたとき、 それが、 図 8に示される AV/C POWER control commandに 対応するレスポンスであることを認識することができる。
そして、 ノードサービス 72は、 ステップ S 25で AV/C POWER responseを受 信すると、 ステップ S 26で、 図 1 1に示されるような SOAPに基づく actionの re sponseを生成し、 UPnPコントロール 1に送信する。
その response 「09 FFB 270」 は、 図 1 0の AV/C POWER responseに記述され ている 2進数の値 「0000100 1 1 1 1 1 1 1 1 1 10 1000 1001 1 10000」 に対応している。
UPnPコントロールポイント 1は、 ステップ S 4において、 このレスポンスを受 信する。 これにより、 UPnPコントロールポイント 1は、 AV/C機器 3が装置の電源 をオンしたことを知ることができる。
AV/Cの規定によれば、 AV/C機器は、 受信したリクエストに対応する処理を直ち に実行できないとき、 INTERIMをレスポンスとして返すことが規定されている。 その AV/C機器は、 その後、 そのリクエストに対応する処理が完了したとき、 その 時点において、 ファイナルレスポンスをリクエストの送信者に返すことになる。
しかしながら、 リクエストを受信してから、 ファイナルレスポンスが返される までの時間は規定されていない。 そこで、 ノードサービス 72は、 ステップ S 2 4の処理で AV/C機器 3に対して AV/Cコマンドを出力した後、 ステップ S 25の処 理で、 AV/C機器 3から AV/Cレスポンスを受けるまでの時間を管理する。 予め設定 されている所定の時間 （例えば、 30秒間） 以内にレスポンスが受信された場合、 そのレスポンスが INTERIMでなければ （ファイナルレスポンスである場合） 、 Cノードサービス 7 2は、 受信したレスポンスに対応するレスポンスを UPnPコン トロールポィント 1に直ちに転送する。
これに対して、 受信したレスポンスが、 INTERIMである場合、 AV/Cノードサ一 ビス 7 2は、 AV/Cコマンドを送信してから 3 0秒間が経過するまで待機する。 そ して、 3 0秒間が経過する前に、 INTERIM以外のレスポンス （ファイナルレスポ ンス） が受信されたとき、 そのファイナルレスポンスに対応するレスポンスを出 力する。 3 0秒以内にファイナルレスポンスが受信されない場合、 AV/Cノードサ 一ビス 7 2は、 INTERIMをレスポンスとして出力する。 これにより、 UPnPコント 口一ルポィント 1は、 少なくとも 3 0秒間以内に要求した処理が完了できるか否 かを知ることができる。
以上の処理を実行するために、 図 3に示される UPnP-AV/Cプロキシ 2が有する デバイスモデルのルートデバイス 6 1は、 図 1 2に示される AV/C Proxy Device Descriptionを有し、 プロキシサービス 7 1は、 図 1 3に示される AV/C Proxy Se rvice Descriptionを有し、 ノードサ^"ビス 7 2は、 図 1 4と図 1 5に示される A V/C Nodes Service Descriptionを する。
これらの Descriptionは、 その機器が有する機能を実行するとき必要とするパ ラメータ、 その他の条件を記述したものであり、 他の機器は、 その機器に、 その 機能の実行を要求するとき、 その Descriptionを参照することで、 そこに記述さ れている条件を付加して、 その機器にコマンドを送ることになる。
図 1 2における deviceType 「urn : sony - cor ： device： 1394ProxyDevice： 1」 は、 ルートデバイス 6 1の型を表している。 FriendlyName 「proxy for IEEE1394J は、 ルートデバイス 6 1のフレンドリーネームを表している。
UDN 「nuid: upnp_1394proxy一; root一 0800460000000000」 ίま、 ノレ一卜デノ イス 6 1 の固有の番号を表している。
この例においては、 プロキシサービス 7 1とノードサービス 7 2の 2つの serv iceが規定されている。 一方の serviceにおいて、 ServiceType 「urn : sony-corp : service : 1394ProxySer vice : 1 J は、 プロキシサービス 7 1のサービスの型が、 Proxy Serviceであるこ とを表し、 servicelD 「urn : sony— corp : ServiceId: 1394ProxyServicel」 ίま、 フロ キシサービス 7 1の固有名を表している。
SCPDURL 「. /scpd/proxyScpd. xml」 は、 プロキシサービス 7 1が有する AV/C Pr oxy Service Descriptionの URL (具体 0勺 ^l fま、 図 1 3に示される AV/C Proxy Ser vice Descriptionの URし を表してレヽる。
また、 他方の ServiceType 「urn: sony-corp： service： 1394NodeService： 1J は、 ノードサービス 7 2のサービスの型が、 NodeServiceであることを表す。 この ser viceの SCPDURL 「. /scpd/nodeScpd. xml」 は、 ノードサービス 7 2が有する AV/C N odes Service Description (具体白勺こ【ま、 図 1 4と図 1 5 こ示される AV/C Nodes Service Description) の URLを表している。
図 1 3の AV/C Proxy Service Descriptionにおける actionは、 プロキシサービ ス 7 1が実行する各種のアクションを表す。 name 「getNodeNumj は、 アクション の名称を表す。 この actionは、 IEEE 1 3 9 4ネッ トワーク 1 2上のノードの数を 取得するァクションである。
この 「getNodeNum」 の actionは、 「nodeNum」 の名称の direction力 S 「out」 の 引数 （その引数に、 他の機器が値を入れて、 プロクシサービス 7 1に出力してく る引数） を有している。
そして、 この 「n。deNum」 の引数に格納される変数は、 serviceStateTableに関 連付けが規定されている。 すなわち、 この変数は、 状態変数に変化があった場合、 サブスクライブしている機器に対して通知される変数であり、 その型は、 「ui l 」 とされる。
図 1 4と図 1 5の AV/C Nodes Service Descriptionには、 AV/Cコマンドを送る アクションである 「avcCommandSendJ が規定されている。 このコマンドは、 「nu id」 、 「avcCommand」 、 「； resumej 、 「inl ineNuidPositionJ 、 「inlineNuid」 、 および 「avcResponse」 の引数を有している。 最後の 「 ResponseJ は、 direct ionが 「outj なので、 他の機器から出力され、 ノードサービス 7 2に送られてく る。 これに対して、 「avcResponse」 を除く 5個の引数は、 その directionが 「in 」 とされているので、 そこに値がセッ トされ、 ノードサービス 7 2から発行され、 他の機器に入力される。
これらの 6個の引数には、 全て関連付けが serviceStatTableに記述されている c これらの引数は、 stateVariable sendEventesが noである場合 （変数に変化が ない場合） に発生され、 「nuid」 、 「avcCommandJ 、 「inlineNuid」 、 および 「 avcResponce」 fま、 レヽずれもその変数の开$力 S 「bin. hex」 とされる。 「resume」 ίま、 変数の开乡が 「booleanj とされ、 「inlineNuidPositionj は、 変数の开が 「ui 1 」 とされる。
図 1 4における 「inilineNuidJ (揷入された NUID) と、 「inlineNuidPositio nj (願 IDの揷入位置） は、 宛先機器の NUID以外の MJIDを指定する場合に利用さ れる （そのコマンドが他の AV/C機器の NUIDを必要とする場合に用いられる） 。
UPnPコントロールポイント 1は、 この Descriptionに従って、 リクエストを送 つてくる。 そこで、 リクエストを受信した AV/C機器は、 その Descriptionの規定 に基づいて、 リクエストを解釈化することで、 NUIDを検出することができる。 図 1 6は、 root device 6 1カ有する AV/C Proxy Device Descriptionの他の例 を表している。 この例においても、 プロキシサービス 7 1の ServiceType 「urn : s ony-corp： service： 1394Proxy Service： 1 J と、 ノードサービス 7 2の ServiceTyp e 「urn : sony_corp : 1394Node Service : 1」 力 S記述されてレヽる。
図 1 6にお ヽて、 図示【ま省略されてレヽる力 S、 serviceld 「urn: sony— corp : servi ceId: 1394ProxyServicel」 の SCPDURLには、 図 1 7の AV/C Proxy Service Descri ptionの URL力、目 β述される。 また、 serviceld 「urn : sony - corp: serviceld: 1394Nod eServicelJ の SCPDURLに^:、 図 1 8の AV/C NodesServiceDescripitonの URL力 S記 述される。
図 1 7は、 プロキシサービス 7 1が有する AV/C Proxy Service Descriptionの 他の例を表している。 図 1 7の例においては、 ノードの数を取得する 「getNodeNum」 の名称のァクシ ョンが記述されている。
同様に、 図 1 8は、 ノードサービス 72が有する AV/C Nodes Service Descrip tionの他の ί列を表している。
図 1 8の例においては、 AV/Cコマンドを送る 「avcCotmnandSend」 のアクション 力 3つの引数 「nuid」 、 「command」 、 「； responsej を有するように規定されて いる。
以上においては、 図 3に示されるように、 1個のルートデバイス 6 1に、 プロ キシサービス 7 1とノードサービス 72を保持させるようにしたが、 例えば、 図 1 9に示されるように、 プロキシサービス 71をルートデバイス 6 1— 1に保持 させるとともに、 IEEE1 394ネットワーク 1 2上の個々のノードに対するサー ビスを各ルートデバイス毎に定義するようにすることもできる。 図 1 9の例にお いては、 ノレートデバイス （root device) 6 1— 2に、 ノードサービス 72— 1 が保持され、 root device 61— 3に、 ノードサービス 72— 2が保持される。 図 20と図 21は、 図 1 9の root device 61一 1乃至 61— 3が有する AV/C Proxy Device Descriptionの例を表し、 図 22は、 図 1 9のプロキシサービス 7 1が保持する AV/C Proxy Service Descriptionの例を表し、 図 2 '3は、 図 1 9の ノ一ドサ一ビス 72— 1, 72- 2が有する /C Node Service Descriptionの 例を表す。
図 20と図 2 1の列においては、 deviceType ι urn： scheraas-upnp-org '■ device： 1394ProxyDevice: 1」 力 root device 6 1— 1に対応して記述され、 deviceType 「u:rn: sony— corp: device: 1394NodeDevice: 1」 力、 root device 6 1— 2に对 、し て 述され、 deviceType 「urn: sony— corp: device: 1394NodeDevice: 1」 カヽ root device 6 1— 3に対応して記述されている。
図示は省略されているが、 deviceType 「urn:scheraas -upnp-org- device "· 1^94Pr oxyDevice:lJ の SCPDURUこは、 図 22の AV/C Proxy Service Descriptionの URL 力51 述され、 deviceType 「urn: sony - corp: device : 1394ProxyDevice: 1」 と device Type 「urrT- sony - corp : device : 1394NodeDevice : l」 の SCPDURUこは、 それぞれ図 2 3の AV/C Nodes Service Descriptionの URLカ記述される。
図 2 2においては、 serviceStateTableに 「nodeNum」 の変数の定義がなされて いる。 この変数の定義は、 Queryにより調べることができる。
図 2 3においては、 AV/Cコマンドを送るアクションである 「avcCommandSend」 が記述されている。
図 2 4は、 デバイスモデルのさらに他の構成例を表す。 この例においては、 図 1 9の例と同様に、 ノードサービス 7 2— 1， 7 2— 2が、 ノード毎に設けられ ているが、 図 1 9の例と異なり、 これらのサービスは、 全て、 プロキシサービス 7 1とともに、 1個の root device 6 1に保持されている。
図 2 5は、 図 2 4の例における root device 6 1が有する AV/C Proxy Device D escriptionの構成を表し、 図 2 6は、 図 2 4のプロキシサービス 7 1が保持する AV/C Proxy service Descriptionの構成例を表し、 図 2 7は、 図 2 4のノードサ 一ビス 7 2— 1， 7 2— 2が有する AV/C Node Service Descriptionの構成例を 表す。
図 2 5の例においては、 3つのサービスが規定されている serviceld 「urn: son y - corp : serviceld: 1394ProxyServicel」 の SCPDURLには、 図 2 6の AV/C Proxy Se rvice Descriptionの URLカ目己述され、 serviceld 「urn: sony—corp : serviceld: 139 4NodeServicel」 と 「urn : sony-corp : serviceld: 1394NodeService2j の SPCDURUこ は、 図 2 7の AV/C Node Service Descriptionの URI^記述される。
図 2 6の例においては、 「nodeNum」 の変数が規定されている。
図 2 7の例においては、 AV/Cコマンドを送るァクションが規定されている。 図 2 8は、 デバイスモデルのさらに他の構成例を表している。 この構成例にお いては、 root device 6 1にプロキシサービス 7 1が保持されている。 また、 ノ ードサービス 7 2— 1 , 7 2— 2は、 それぞれノード毎に設けられる他、 root d evice 6 1の内部に开成されたェンべデッドデバイス （embedded device) 8 1— 1， 8 1— 2に、 それぞれ保持される。 図 2 9と図 3 0は、 図 2 8における root device 6 1が保持する AV/C Proxy De vice Descriptionの構成例を表し、 図 3 1は、 図 2 8のプロキシサービス 7 1が 保持する AV/C Proxy Service Descriptionの構成例を表し、 図 3 2は、 図 2 8の ノ一ドサ一ビス 7 2— 1， 7 2 - 2が有する AV/C Node Service Descriptionの 構成例を表す。
図 2 9と図 3 0の例にぉレヽて、 serviceld ι urn '- sony-corp' serviceld'- l394Pro xyServicelJ は、 図 2 8のプロキシサービス 7 1に対応し、 その SCPDURLには、 図 3 1の AV/C Proxy Service Descriptionの URL力 S記述される。
serviceld ι urn: sony - corp : serviceld: 1394NodeSe:rvicel」 は、 図 2 8の AV/C node service 2— 1に対応し、 「urn: sony - corp: service工 d: 1394NodeService2 」 は、 AV/C node service 7 2— 2に対応し、 それぞれの SCPDURLには、 図 3 2の AV/C node Service Descriptionの亂カ S記述される。
図 3 1の例においては、 「N0DE Num」 の変数が定義されている。
図 3 2の例においては、 AV/Cコマンドを送るアクション 「avcCommandSend」 力 規定されている。 '
次に、 図 3、 図 1 9、 図 2 4および図 2 8に示すデバイスモデルを比較する。 図 3の例においては、 1つの root device 6 1に、 プロキシサ一ビス 7 1とノ ードデバイス 7 2が、 それぞれ 1つずつ定義される。
図 1 9の例においては、 プロキシサービス 7 1が 1つの root device 6 1 - 1 に定義されるとともに、 1 3 9 4上の個々のノードに対するノードサービス 7 2 — 1 , 7 2— 2力 root device 6 1— 2， 6 1— 3毎に定義される。
図 2 4の例においては、 プロキシサービス 7 1が、 1つの root device 6 1に 設けられる他、 ノードサービスが各ノード毎に対応して設けられ、 それらのノー ドサービス 7 2— 1 , 7 2— 2は、 プロキシサービス 7 1と同様に、 1つの root device 6 1に保持される。
図 2 8の例においては、 1 3 9 4上のノードが全て root device 6 1の embedde d device 8 1 - 1 , 8 1— 2として定義される。 図 3 3は、 図 3、 図 1 9、 図 2 4、 および図 2 8のデバイスモデルの特徴の比 較結果を表している。 なお、 図 3 3において、 タイプ A、 タイプ B、 タイプ C、 およびタイプ Dは、 それぞれ図 3、 図 1 9、 図 2 4、 または図 2 8のデバイスモ デルに対応している。
タイプ Aからタイプ Dまでを比較すると、 SSDPのパケット量が大きく異なって いることがわかる。 すなわち、 root deviceが 1個のとき、 SSDPの数は、 3 + 2 d + kとなる。 ここで、 dは embedded deviceの数、 kはサービスタイプの数を意 味する。 従って、 1 3 9 4ネットワーク 1 2上のノードの数を Nとするとき、 SS DPのパケットの量は、 タイプ Aのとき 5個、 タイプ Bのとき 4 + 4 N個、 タイプ Cのとき 4 + N個、 タイプ Dのとき 4 + 3 N個となる。 特に、 タイプ B (図 1 9 ) とタイプ D (図 2 8 ) の場合には、 ノード数の数倍になる数のパケットが流れ ることになる。 そこで、 ネットワークのトラフィックの観点から考えた場合、 SS DPのパケットの量が少ないタイプ A (図 3 ) の例が望ましい。
パスの構成の変更の通知は、 タイプ Aの場合、 GENAにより行われ、 タイプ B , C , Dの場合、 SSDPにより行われる。
presentation URLの構成の単位は、 タイプ Aとタイプ Cがバス単位とされ、 タ イブ Bとタイプ Dがノード単位とされる。 ノード毎に URLを持つことが可能なタ イブ B (図 1 9 ) とタイプ D (図 2 8 ) が分かりやすいが、 タイプ A (図 3 ) と タイプ C (図 2 4 ) に関しても、 プロキシサービス 7 1が、 各ノードに対するリ ンクページのようなものを用意すれば、 実質的に対応する機能は実現できると考 兄られる。
NOTIFYの通知の単位は、 タイプ Aの場合、 バス単位とされ、 タイプ B， C , D の場合、 ノード単位とされる。
以上を総合すると、 タイプ A (図 3 ) の例が最適と考えられる。
以上においては、 IEEE 8 0 2ネットワーク 1 1に接続されている機器から、 IE EE l 3 9 4ネットワーク 1 2に接続されている機器を制御するようにしたが、 後 者から前者を制御することも可能である。 上述した一連の処理は、 ハードウェアにより実行させることもできるが、 ソフ トウエアにより実行させることもできる。 一連の処理をソフトウエアにより実行 させる場合には、 そのソフトウェアを構成するプログラムが、 専用のハードゥエ ァに組み込まれているコンピュータ、 または、 各種のプログラムをインス トール することで、 各種の機能を実行することが可能な、 例えば汎用のパーソナルコン ピュータなどに、 ネッ トワークや記録媒体からインス トールされる。
この記録媒体は、 図 2に示すように、 装置本体とは別に、 ユーザにプログラム を提供するために配布される、 プログラムが記録されている磁気ディスク 4 1 ( フロッピディスクを含む） 、 光ディスク 4 2 (CD-ROM (Compact Disk-Read Only Memory) , DVD (Digital Versatile Disk)を含む） 、 光磁気ディスク 4 3 (MD (M ini-Disk) を含む） 、 もしくは半導体メモリ 4 4などよりなるパッケージメディ ァにより構成されるだけでなく、 装置本体に予め組み込まれた状態でユーザに提 供される、 プログラムが記録されている R0M 2 2や、 記憶部 2 8に含まれるハー ドディスクなどで構成される。
なお、 本明細書において、 記録媒体に記録されるプログラムを記述するステツ プは、 記載された順序に沿って時系列的に行われる処理はもちろん、 必ずしも時 系列的に処理されなくとも、 並列的あるいは個別に実行される処理をも含むもの である。
また、 本明細書において、 システムとは、 複数の装置により構成される装置全 体を表すものである。 産業上の利用可能性
以上のように、 本発明によれば、 IEEE 8 0 2に基づく第 1のネットワークから の S0APに基づくコマンドを、 第 2のネットワークの AV/Cコマンドに変換するよう にしたので、 簡単かつ確実に、 第 1のネットワークに接続されている機器から、 第 2のネットワークに接続されている機器を制御することが可能となる。

Claims

請求の範囲
1 . IEEE 8 0 2の SOAPに基づく第 1のフォーマツトで通信する第 1のネットヮ ークと、 IEEE 1 3 9 4の AV/Cコマンドに基づく第 2のフォーマツトで通信する第 2のネットワークとの間でデータを授受する情報処理装置において、
前記第 1のネットワークからの前記第 1のフォーマツトのデータを取り込む取 り込み手段と、
前記取り込み手段により取り込まれた前記第 1のフォーマツトの前記 SOAPに基 づくコマンドを、 前記第 2のネットワークの前記 AV/Cコマンドに変換して前記第 2のフォーマツトに格納する変換手段と、
前記変換手段により変換された前記第 2のフォーマットを、 前記第 2のネット ワークに送信する送信手段と
を備えることを特徴とする情報処理装置。
2 . 前記変換手段は、 前記 SOAPに基づくコマンドに記述されている前記第 2の ネットワークに接続されている機器を指定するノードユニーク IDとノード IDの対 応表を有し、 前記 SOAPに基づくコマンドに記述されている前記第 2のネットヮー クに接続されている機器を指定するノードユニーク IDを、 前記対応表に基づいて ノード IDに変換する
ことを特徴とする請求の範囲第 1項に記載の情報処理装置。
3 . 前記変換手段は、 前記 SOAPに基づくコマンドと、 それに基づいて前記第 2 のネットワークに送信されるコマンドとの対応表を有し、 前記第 2のネットヮー クを介して受信したレスポンスに対応する前記 S0APに基づくコマンドを、 前記対 応表に基づいて検索し、 前記 S0APに基づくコマンドに対応するレスポンスを前記 第 1のネットワークに送信する
ことを特徴とする請求の範囲第 1項に記載の情報処理装置。
4 . 前記変換手段は、 前記 S0APに基づくコマンドに含まれるトランザクション ラベルに基づいて、 前記 S0APに基づくコマンドとレスポンスを対応させる ことを特徴とする請求の範囲第 3項に記載の情報処理装置。
5 . 前記変換手段は、 前記第 1のネットワークに接続されている機器からのリ タエストに対応するファイナルレスポンスが、 予め定められている時間内に、 前 記第 2のネットワークに接続されている機器から受信されないとき、 前記第 1の ネットワークに接続されている機器に対して処理中であることを表すレスポンス を送信する ·
ことを特徴とする請求の範囲第 1項に記載の情報処理装置。
6 . 前記 SOAPに基づくコマンドが、 前記第 2のネッ トワークのバスリセッ ト時 に再送を要求するコマンドである場合、 前記第 2のネットワークのバスリセット を検知し、 前記第2のネットワークにバスリセットが発生したとき、 前記コマン ドを送信する検知手段を
さらに備えることを特徴とする請求の範囲第 1項に記載の情報処理装置。
7 . 前記変換手段は、 さらに前記第 2のネットワークの前記 AV/Cコマンドを、
- 前記第 1のフォーマツトの前記 SOAPに基づくコマンドに変換して前記第 1のフォ 一マツトに格納し、
前記送信手段は、 さらに前記変換手段により変換された前記第 1のフォーマツ トの前記 SOAPに基づくコマンドを、 前記第 1のネットワークに送信する
ことを特徴とする請求の範囲第 1項に記載の情報処理装置。
8 . IEEE 8 0 2の SOAPに基づく第 1のフォーマットで通信する第 1のネットヮ ークと、 IEEE 1 3 9 4の AV/Cコマンドに基づく第 2のフォーマツトで通信する第 2のネットワークとの間でデータを授受する情報処理装置の情報処理方法におい て、
前記第 1のネットワークからの前記第 1のフォーマツトのデータを取り込む取 り込みステップと、
前記取り込みステップの処理により取り込まれた前記第 1のフォーマットの前 記 S0APに基づくコマンドを、 前記第 2のネットワークの前記 AV/Cコマンドに変換 して前記第 2のフォーマツトに格納する変換ステップと、
前記変換ステップの処理により変換された前記第 2のフォーマツトを、 前記第 2のネットワークに送信する送信ステップと
を含むことを特徴とする情報処理方法。
9 . IEEE 8 0 2の SOAPに基づく第 1のフォーマットで通信する第 1のネッ トヮ ークと、 IEEE 1 3 9 4の AV/Cコマンドに基づく第 2のフォーマツトで通信する第 2のネットワークとの間でデータを授受する情報処理装置のプログラムであって、 前記第 1のネットヮ一クからの前記第 1のフォーマツトのデータを取り込む取 り込みステップと、
前記取り込みステップの処理により取り込まれた前記第 1のフォーマツトの前 記 SOAPに基づくコマンドを、 前記第 2のネットワークの前記 AV/Cコマンドに変換 して前記第 2のフォーマットに格納する変換ステップと、
前記変換ステップの処理により変換された前記第 2のフォーマツトを、 前記第 2のネットワークに送信する送信ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録され ている記録媒体。
1 0 . IEEE 8 0 2の SOAPに基づく第 1のフォーマットで通信する第 1のネット ワークと、 IEEE 1 3 9 4の AV/Cコマンドに基づく第 2のフォーマツトで通信する 第 2のネットワークとの間でデータを授受する情報処理装置を制御するコンビュ ータに、
前記第 1のネットワークからの前記第 1のフォーマツトのデータを取り込む取 り込みステップと、
前記取り込みステップの処理により取り込まれた前記第 1のフォーマツトの前 記 SOAPに基づくコマンドを、 前記第 2のネットワークの前記 AV/Cコマンドに変換 して前記第 2のフォーマットに格納する変換ステツプと、
前記変換ステップの処理により変換された前記第 2のフォーマツトを、 前記第 2のネットワークに送信する送信ステップと
を実行させるプログラム。
PCT/JP2002/004835 2001-05-24 2002-05-20 Appareil de traitement d'informations WO2002096037A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR10-2003-7001005A KR20030024806A (ko) 2001-05-24 2002-05-20 정보 처리 장치
EP02726442A EP1300989A1 (en) 2001-05-24 2002-05-20 Information processing apparatus

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2001154751 2001-05-24
JP2001-154751 2001-05-24
JP2001-226390 2001-07-26
JP2001226390A JP3661936B2 (ja) 2001-05-24 2001-07-26 情報処理装置および方法、記録媒体、並びにプログラム

Publications (1)

Publication Number Publication Date
WO2002096037A1 true WO2002096037A1 (fr) 2002-11-28

Family

ID=26615608

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2002/004835 WO2002096037A1 (fr) 2001-05-24 2002-05-20 Appareil de traitement d'informations

Country Status (6)

Country Link
US (1) US20030177270A1 (ja)
EP (1) EP1300989A1 (ja)
JP (1) JP3661936B2 (ja)
KR (1) KR20030024806A (ja)
CN (1) CN1463521A (ja)
WO (1) WO2002096037A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007136195A1 (en) * 2006-05-19 2007-11-29 Lg Electronics Inc. Method for managing and processing information of an object for presentation of multiple sources and apparatus for conducting said method

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10302477A1 (de) * 2003-01-23 2005-02-24 Deutsche Thomson-Brandt Gmbh Verfahren zur Verfügbarmachung eines Eingabeparameters einer Netzwerkstation eines Netzwerks eines ersten Typs in einem Netzwerk eines zweiten Typs sowie Verbindungseinheit zur Verbindung der Netzwerke des ersten und zweiten Typs
JP2004272632A (ja) 2003-03-10 2004-09-30 Sony Corp 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
KR100565060B1 (ko) * 2003-03-14 2006-03-30 삼성전자주식회사 언어 정보에 따라 적응적으로 재생가능한 데이터 구조로기록된 정보저장매체, 그 재생 방법 및 장치
JP4197517B2 (ja) 2003-03-31 2008-12-17 富士通株式会社 バスブリッジ装置、バスブリッジ方法および入出力制御装置
KR100493896B1 (ko) 2003-04-18 2005-06-10 삼성전자주식회사 디지털 콘텐트 메타데이터 변환 방법 및 장치, 그리고이를 이용한 네트워크 시스템
JPWO2004095293A1 (ja) * 2003-04-24 2006-07-13 三菱電機株式会社 映像情報システム、およびモジュールユニット
CN100521636C (zh) 2003-06-30 2009-07-29 皇家飞利浦电子股份有限公司 在URI中嵌入UPnP AV媒体服务器的对象ID
KR101015811B1 (ko) * 2003-09-23 2011-02-22 엘지전자 주식회사 UPnP 기반의 미디어 콘텐츠 재생을 제어하는 전자기기 및 그 방법
CN1620060B (zh) * 2003-11-17 2010-04-28 国际商业机器公司 把浏览器不兼容的信息整合在网络内容中以及显示该信息的方法和设备
US20050144137A1 (en) * 2003-12-24 2005-06-30 Kumar B. V. Protocol processing device and method
DE602004023582D1 (de) * 2004-02-26 2009-11-26 Research In Motion Ltd Verfahren und Vorrichtung zur Aggregation von Webdiensten
JP4337591B2 (ja) 2004-03-19 2009-09-30 株式会社日立製作所 情報処理装置、ネットワークシステムおよびネットワークシステムの制御方法
JP4645165B2 (ja) * 2004-11-12 2011-03-09 セイコーエプソン株式会社 ネットワーク型プラグアンドプレイに対応したネットワーク装置の制御
KR100639970B1 (ko) 2004-12-16 2006-11-01 한국전자통신연구원 ＵＰｎＰ ＡＶ 시스템 및 미디어 렌더러와 재생 모듈간의통신 수행 방법
JP4164490B2 (ja) * 2004-12-17 2008-10-15 キヤノン株式会社 通信装置、プロファイル情報取得方法、及び、プログラム
US8156505B2 (en) * 2005-01-27 2012-04-10 Infosys Limited Protocol processing including converting messages between SOAP and application specific formats
KR100643296B1 (ko) * 2005-05-11 2006-11-10 삼성전자주식회사 웹 서비스 기술을 지원하는 ａ/ｖ 네트워크에서 컨텐츠서비스 제공 방법 및 장치
KR100739743B1 (ko) * 2005-10-19 2007-07-13 삼성전자주식회사 홈 네트워크에서 디바이스를 독점적으로 제어하기 위한방법 및 장치
US7788409B2 (en) * 2005-10-28 2010-08-31 Sony Corporation System and method for achieving interoperability in home network with IEEE 1394 and UPnP devices
JP2007150853A (ja) 2005-11-29 2007-06-14 Toshiba Corp 供給装置と処理装置及び指示方法
JP2007156691A (ja) * 2005-12-02 2007-06-21 Seiko Epson Corp ネットワーク型プラグアンドプレイに対応したネットワーク中継制御
KR100714708B1 (ko) * 2006-01-12 2007-05-04 삼성전자주식회사 홈 네트워크에서 디바이스 간 호환성을 지원하는 미들웨어장치 및 그 방법
US7813823B2 (en) * 2006-01-17 2010-10-12 Sigmatel, Inc. Computer audio system and method
KR100772865B1 (ko) * 2006-01-31 2007-11-02 삼성전자주식회사 Ａｖ 세션 복원 방법 및 이를 위한 컨트롤 포인트
US7873059B2 (en) 2006-03-01 2011-01-18 Mitsubishi Electric Corporation Gateway device
CN101325530B (zh) * 2008-07-04 2011-11-30 海信集团有限公司 一种二级网络及其通信方法
KR101669672B1 (ko) * 2009-08-17 2016-11-10 삼성전자주식회사 단말의 원격 관리 방법 및 장치

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10145420A (ja) * 1996-11-12 1998-05-29 Sony Corp 異なるシステムに接続された機器の制御方法及び変換機器
JPH11187061A (ja) * 1997-05-06 1999-07-09 Toshiba Corp 通信装置、通信制御方法、サービス登録方法、サービス提供方法及び装置制御プログラム登録方法
JP2000196618A (ja) * 1998-12-28 2000-07-14 Toshiba Corp 通信ノ―ド

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6813651B1 (en) * 2000-02-18 2004-11-02 Controlnet, Inc. Interface device for ethernet transceiver and 1394 controller
US20020174236A1 (en) * 2001-03-26 2002-11-21 Sanjay Mathur Methods and apparatus for processing data in a content network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10145420A (ja) * 1996-11-12 1998-05-29 Sony Corp 異なるシステムに接続された機器の制御方法及び変換機器
JPH11187061A (ja) * 1997-05-06 1999-07-09 Toshiba Corp 通信装置、通信制御方法、サービス登録方法、サービス提供方法及び装置制御プログラム登録方法
JP2000196618A (ja) * 1998-12-28 2000-07-14 Toshiba Corp 通信ノ―ド

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HIROYUKI NAKAYAMA: "XML on windows CE", KABUSHIKI KAISHA SHOEISHA, XML MAGAZINE 03, vol. 7, no. 2, 1 January 2001 (2001-01-01), pages 182 - 190, XP002955038 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007136195A1 (en) * 2006-05-19 2007-11-29 Lg Electronics Inc. Method for managing and processing information of an object for presentation of multiple sources and apparatus for conducting said method

Also Published As

Publication number Publication date
JP2003046535A (ja) 2003-02-14
US20030177270A1 (en) 2003-09-18
KR20030024806A (ko) 2003-03-26
EP1300989A1 (en) 2003-04-09
JP3661936B2 (ja) 2005-06-22
CN1463521A (zh) 2003-12-24

Similar Documents

Publication Publication Date Title
WO2002096037A1 (fr) Appareil de traitement d'informations
JP4456095B2 (ja) ホームネットワークで第３の装置のイベントを処理する方法及び装置
US8423671B2 (en) Middleware device and method of supporting compatibility of devices in home network
US7698467B2 (en) Method for transforming contents in the DLNA system
US7844738B2 (en) Method of and apparatus for bridging a UPnP network and a rendezvous network
US20040120344A1 (en) Device discovery application interface
EP1058422A1 (en) Methods for bridging a HAVi sub-network and a UPnP sub-network and device for implementing said methods
US20040205172A1 (en) Control point server system and method thereof enabling efficient access to home network devices
JP3525435B2 (ja) 情報処理装置および方法、並びに通信システム
US20040133896A1 (en) Network device application interface
JP3661935B2 (ja) 情報処理装置および方法、記録媒体、並びにプログラム
JP2003008610A (ja) 情報処理装置および方法、記録媒体、並びにプログラム
US8150916B2 (en) Method, apparatus, and system for transmitting information
US9338022B2 (en) Method of processing action, method of controlling controlled device, controlled device, and control point
EP2168305B1 (en) Method of receiving/transmitting event message, controlled device, and control point
JP2004104839A (ja) 情報処理装置および方法、並びに通信システム
KR100639970B1 (ko) ＵＰｎＰ ＡＶ 시스템 및 미디어 렌더러와 재생 모듈간의통신 수행 방법
KR100952280B1 (ko) 댁내에 설치되는 주거 게이트웨이의 재부팅을 원격으로제어하는 방법
Kim et al. Seamless network bridge for supporting interoperability upnp-zigbee
KR101250810B1 (ko) ＤＬＮＡ네트워크에 접속된 ＩＥＥＥ1394 ＡＶ/Ｃ 기기를ＵＰｎＰ기기로 인식하는 정보처리 방법 및 장치
JP2005122619A (ja) クライアント装置

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CN KR US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

WWE Wipo information: entry into national phase

Ref document number: 2002726442

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 028018176

Country of ref document: CN

Ref document number: 10333708

Country of ref document: US

Ref document number: 1020037001005

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 1020037001005

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2002726442

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2002726442

Country of ref document: EP