JP2007156691A - Network relay compatible with network-type plug and play - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a technique capable of reducing drop in communication efficiency, when a service device is not operated normally, in a network compatible with a network-type plug and play. <P>SOLUTION: A device unit has the N-number (N is an integer of 1 or larger) of service devices. A network relay device, compatible with the network-type plug and play, is provided with a description preparing part for preparing a device description for describing the service devices included in the network-type plug and play, and for supplying the device description, in response to a request from a client over a network. The description preparing part prepares the device description that does not include the description of the inoperable service device to be supplied to the client, when one or more of the service devices are inoperable from among the N-number of service devices included in the device unit. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a control technology for a network relay device that supports network type plug and play.

  As is well known, plug and play is a technique that allows a peripheral device to be connected to or disconnected from a computer at an arbitrary timing after the computer is started. In recent years, Universal Plug and Play (hereinafter referred to as “UPnP”, UPnP is a trademark of UPnP Implementers Corporation) has been developed as an application of plug and play technology to a network. When UPnP is used, the network device can be connected to the network or disconnected from the network at an arbitrary timing. In this specification, an architecture that implements plug and play in a network, such as UPnP, is referred to as “network type plug and play”.

JP 2001-290724 A

  A UPnP-compatible network device can function as various service devices. Here, “service device” means a device that provides a service in response to an external request. The service device can be realized as various devices (referred to as “device units”) such as a printer, a scanner, a facsimile, a copier, a storage device, a camera, and a clock. It is also possible to realize the functions of a plurality of service devices with one device unit.

  By the way, a device unit that does not support UPnP is also desired to be used as a device that supports UPnP protocol by using a network relay device that supports UPnP protocol. However, in the past, the actual situation is that there has been no sufficient study on how to implement such a relay device. For example, when the service device is not operating normally, how to notify the situation to other clients has not been sufficiently devised. As a result, there is a problem that even when the service device is not operating normally, useless communication occurs because the client tries to use the service device, thereby reducing the communication efficiency of the network.

  An object of the present invention is to provide a technique capable of reducing a decrease in communication efficiency when a server device is not operating normally in a network compatible with network type plug and play.

The apparatus of the present invention is a network for relaying between a device unit having N (N is an integer of 1 or more) service devices that provide a service in response to a request from a client on the network and the network. Network relay device that supports plug-and-play
A description creation unit that creates a device description describing a service device included in the device unit connected to the network relay device and supplies the device description in response to a request from a client on the network; ,
The description creation unit creates a device description that does not include a description of an inoperable service device when one or more service devices of the N service devices of the device unit are inoperable. To the client.

  According to this apparatus, since a device description that does not include a description of an inoperable service device is created and supplied to the client, the client can recognize the inoperable service device from the device description. Therefore, when the server device is not operating normally, it is possible to prevent the client from accessing the service device, so that a reduction in communication efficiency can be reduced.

  The description creation unit may create the device description so as to have only a basic device having no service to be provided to the client when all of the N service devices cannot be operated.

  According to this configuration, since the client can recognize from the device description that all the service devices in one device unit cannot be operated, unnecessary access can be prevented and a reduction in communication efficiency can be reduced.

The inoperable service device is
(I) powering off the device unit;
(Ii) loss of connection between the device unit and the network relay device;
(Iii) Inability of the service device to operate due to the occurrence of a failure in each service device;
It may be generated by any of the above.

The network relay device is:
A device control unit that includes the description creation unit and operates the device unit by exchanging information with the device unit;
Network protocol control connected between the network and the device control unit, receiving a message having a message header and a message body from a client on the network, and transferring information of the message body to the device control unit And
With
The network protocol control unit interprets the message header according to the network type plug and play protocol without interpreting the content of the message body received from the client, and is different from the network type plug and play protocol. Sending the message body to the device controller according to a communication protocol;
The device control unit may interpret the content of the message body received from the network protocol control unit and cause the service device to execute a service according to the result of the interpretation.

  According to this configuration, the network protocol control unit interprets the header without interpreting the content of the message body and transmits the message body to the device control unit. Therefore, the control in the network protocol control unit is implemented in the device unit. It does not depend on the type or number of service devices. As a result, the control in the network protocol control unit can be simplified.

  Note that the present invention can be realized in various forms, for example, a network device, a network protocol control device, a control method and control device for those devices, and a function of those methods or devices. The present invention can be realized in the form of a computer program, a recording medium recording the computer program, a data signal including the computer program and embodied in a carrier wave, and the like.

Next, embodiments of the present invention will be described in the following order.
A. Explanation of terms:
B. System overview:
C. Device configuration of device and device description:
D. First embodiment:
E. Second embodiment:
F. Third embodiment:
G. Variation:

A. Explanation of terms:
The meanings of the terms used in the following description are as follows.
DHCP (Dynamic Host Configuration Protocol): Dynamic host configuration protocol. A protocol that dynamically assigns IP addresses.
GENA (General Event Notification Architecture): General event notification architecture. Used when issuing events in the UPnP architecture.
HTTP (HyperText Transfer Protocol): Hypertext transfer protocol.
HTTP MU (HTTP Multicast over UDP): HTTP multicast using UDP (User Datagram Protocol).
HTTPPU (HTTP (unicast) over UDP): HTTP unicast using UDP.
MFP (Multi Function Peripheral): a composite peripheral device having a plurality of device functions
SOAP (Simple Object Access Protocol): Simple object access protocol. In UPnP architecture, it is used for requesting and responding to actions by RPC (Remote Procedure Call).
SSDP (Simple Service Discovery Protocol): Simple service discovery protocol. In the UPnP architecture, it is used for service discovery.
UPnP (Universal Plug and Play): Universal Plug and Play (UPnP is a trademark of UPnP Implementers Corporation).
URI (Uniform Resource Identifier): Uniform resource identifier. An identifier that is a superordinate concept of URL (Uniform Resource Locator) and indicates a unique position of a resource.
XHTML (eXtensible HyperText Markup Language): An extended hypertext markup language. It is a kind of document description language compatible with HTML, and is a form of XML implementation. XHTML-print described later is a specification for printing an XHTML document.
XML (eXtensible Markup Language): An extensible markup language.

  Although many of the above-described protocols are used in UPnP, these are hereinafter collectively referred to as “UPnP protocol”.

B. System overview:
FIG. 1 is a conceptual diagram showing a configuration of a network system to which an embodiment of the present invention is applied. This network system has a configuration in which a personal computer 100, a digital camera 110, a digital TV set 120, an image server 130, and a relay unit 600 are connected to each other via a LAN. The relay unit 600 is connected to the multi-function device 800. The MFP 800 itself does not support the UPnP protocol, but the relay unit 600 executes processing according to the UPnP protocol. Therefore, the device 900 including the relay unit 600 and the multifunction device 800 can function as a UPnP compatible network device. The LAN may be a wired network such as IEEE 802.3 or a wireless network such as IEEE 802.11b / g / a. The digital camera 110 and the digital TV set 120 are UPnP compatible network devices. The digital camera 110 and the TV set 120 include control points 110C and 120C in the UPnP architecture. The UPnP architecture and control points will be described later. The personal computer 100 and the image server 130 are also components of this network system, but do not support UPnP.

  The personal computer 100 has a function of creating print data of an image using the printer driver 100D, and transferring the print data to the multi-function device 800 via the relay unit 600 via the LAN to execute printing. . During this printing process, the multi-function device 800 functions as a normal network printer. On the other hand, when printing is performed in accordance with a request from a control point (for example, 110C), the network device 900 including the multifunction device 800 and the relay unit 600 functions as a UPnP compatible printer device.

  The relay unit includes an MFP server 300 and an MFP device control unit 700. The MFP server 300 has a function as a network protocol control unit 302 that mediates messages exchanged between other devices on the LAN and the MFP device control unit 700. As will be described later, in a typical case, the MFP server 300 interprets the UPnP protocol with respect to the message header during message transfer, but does not interpret or process the message body.

  The MFP device control unit 700 has a description creation module 710 and a Web application module 720. The description creation module 710 has a function of creating a device description and a service description used in the UPnP protocol and providing these descriptions in response to a request from a client (control point). The web application module 720 has a function of creating various web pages for use in setting and using the network device 900 and providing web pages in response to requests from clients. These modules 710 and 720 are implemented as computer programs, but can also be implemented as hardware circuits.

  The MFP server 300 and the MFP device control unit 700 are connected by USB (Universal Serial Bus), and the MFP device control unit 700 and the multi-function device 800 are also connected by USB. However, various physical interfaces other than USB can also be used. Further, the MFP server 300 and the MFP device control unit 700 can be connected with a communication protocol different from the UPnP protocol.

  The multi-function device 800 includes service devices 810, 820, and 830 for providing services to clients, and a control unit 840. Here, a print engine 810, a scanner engine 820, and a PC card interface 830 are mounted as service devices. Note that the multi-function device 800 only needs to have at least one service device, and is generally configured to have N service devices (N is an integer equal to or greater than 1). The multi-function device 800 is also referred to as a “device unit”.

  The print engine 810 is a printing mechanism that executes printing according to given print data. In this embodiment, when the control points 110C and 120C transmit XHTML data to the multi-function device 800 according to the UPnP protocol and perform printing, the MFP device control unit 700 interprets the XHTML data and performs color conversion and halftone processing. It executes to create print data, and supplies this print data to the print engine 810. However, instead of the MFP device control unit 700, the control unit 840 or the print engine 810 may be configured to have color conversion and halftone processing functions. On the other hand, when printing from the personal computer 100, the MFP device control unit 700 analyzes the page description language generated by the printer driver 100D, creates print data, and supplies the print data to the print engine 810. In this specification, “print data” means data representing a printed matter by dot data indicating a dot formation state on a print medium. The print data is composed of printer-specific control commands. XHTML does not correspond to print data, and is a document description language for describing a document. The scanner engine 820 is a mechanism that scans an image and generates image data.

  UPnP is an architecture that realizes connecting or disconnecting a network device to a network at an arbitrary timing. The UPnP network includes control points 110C and 120C and service devices 810, 820, and 830. Here, “service device” means a device that provides a service. In this specification, unless otherwise specified, “device” and “service device” are used as synonyms. The “control point” means a controller that detects and controls other devices on the network, and functions as a client for the service device. Various functions of the UPnP-compatible network device will be described later.

  FIG. 2 is a block diagram showing internal configurations of the MFP server 300 and the MFP device control unit 700 in the relay unit 600. The MFP server 300 includes a central control unit (CPU) 310, a RAM 320, a ROM 330, a network control unit 340, and a USB host control unit 350. The network control unit 340 is connected to a wired network via the connector 342. The USB host control unit 350 has a root hub 352, and two USB connectors 354 and 356 are provided on the root hub 352. The first USB connector 354 is connected to the USB connector 462 of the MFP device control unit 700 via a USB cable. An additional device (for example, a wireless communication circuit for communicating with a wireless LAN network) can be connected to the second USB connector 356.

  The MFP device control unit 700 includes a central control unit (CPU) 410, a RAM 420, a ROM 430, a USB device control unit 460, and a USB host control unit 510. The first USB device control unit 460 is connected to the USB host control unit 350 of the MFP server 300 via the USB connector 462. The USB host control unit 510 has a root hub 512, and the root hub 512 is provided with a USB connector 514. A multi-function device 800 (device unit) is connected to the connector 514.

  The central control unit 310, the network control unit 340, and the USB host control unit 350 of the MFP server 300 realize the function as the network protocol control unit 302 in FIG. More specifically, the network control unit 340 transmits and receives messages according to various network protocols. The central control unit 310 interprets the UPnP protocol and determines the transfer destination. USB host control unit 350 transfers a message to and from MFP device control unit 700. These control units 310, 340, and 350 transfer messages without interpreting or processing the message body.

  The USB device control unit 460 of the MFP device control unit 700 transmits and receives messages according to the USB transfer protocol. The central control unit 410 interprets the content of the message transferred via the MFP server 300, executes processing according to the content of the message, creates control data, and transfers the control data to the multi-function device 800. To do. The operations of the service devices 810, 820, and 830 in the multi-function device 800 are controlled according to this control data. The functions of both MFP server 300 and MFP device control unit 700 may be realized by a single unit without separating MFP server 300 and MFP device control unit 700.

  The multifunction device 800 is provided with an operation panel and a display unit (monitor) that are used when the user performs various settings, but these are not shown.

  FIG. 3 is a block diagram illustrating a hierarchical structure of various protocols of the MFP server 300. The MFP server 300 includes a service protocol interpreter 1000 for interpreting various network protocols. The service protocol interpretation unit 1000 includes a lower layer of the network architecture and a lower layer of the USB architecture. As a lower layer of the network architecture, a UPnP device architecture 1100 and three non-UPnP device function units 1210, 1220, and 1230 are provided. Below these are a UDP or TCP layer, an Internet Protocol (IP) layer, a driver layer, and a network interface layer.

  As a lower layer of the USB architecture of the service protocol interpreter 1000, a D4 packet processor 1300, a USB printer class driver 1310, a USB scanner class driver 1320, and a USB storage class driver 1330 are provided. Below these three device drivers 1310, 1320, and 1330 are USB system software and a USB host interface (hardware). As can be understood from this figure, the USB printer class driver 1310 uses the so-called “D4 packet” (packet structure conforming to IEEE1284.4) to transfer data, whereas the scanner class driver 1310 The D4 packet is not used in 1320 or the storage class driver 1330. This is because, among the standard USB device classes, the D4 packet is adopted as the upper protocol in the printer class, but in the scanner class and the storage class, the control stack that does not use the D4 packet (from the application layer to the physical layer). This is because the architecture up to is the standard of the OS.

  The UPnP device architecture is configured according to various protocols such as HTTPMU, HTTPPU, SOAP / HTTP, and HTTP. UPnP uses these protocols to implement the following various processes.

(1) Addressing:
When a UPnP device (hereinafter simply referred to as “device”) is connected to a network, a network address (IP address) is acquired by addressing. For addressing, a DHCP server or Auto-IP is used. If a DHCP server is provided in the network, the device uses an IP address assigned by the DHCP server. If there is no DHCP server, the device determines its own address using an automatic IP addressing function called Auto-IP. In this embodiment, only one IP address is assigned to the network device 900 composed of the relay unit 600 and the multifunction device 800, and the entire device 900 is recognized as a single network device.

(2) Discovery (detection):
Discovery is a process in which the control point finds out where the device is. Discovery can be realized by the control point multicasting the discovery message, or can be realized by advertising the fact to the control point when the device joins the network. Discovery is performed using HTTPMU / SSDP or HTTPPU / SSDP. As a result of the discovery, the control point and the device can be processed peer-to-peer.

(3) Description:
Details of the device configuration are described in XML as a device description. The details of the device service are described in XML as a service description. These descriptions are owned by the device and provided to the control point. The control point can know the details of the device and service by referring to these descriptions. An example of the device description will be described later.

(4) Control:
Control is a process in which a control point controls a device by transferring a control message including an action request to the device. Control is performed using HTTP / SOAP.

(5) Event:
When a predetermined event occurs, a service in the device notifies the control point of the occurrence of the event. A control point that receives notification of an event occurrence “subscribes” to the service. Events are forwarded to subscribing control points. Notification of an event is performed using HTTP / GENA.

(6) Presentation:
The presentation is a process of acquiring a presentation page whose control point is described in HTML from the URL for presentation registered in the device description. With this presentation, for example, the control point can display various states of the device.

  The present invention can also be applied to future versions of UPnP. As network type plug and play, any control point and device can communicate peer-to-peer by addressing (automatic IP address determination) and device discovery, and the control point and device exchange messages. If it is an architecture, the present invention can be applied to network type plug and play specifications other than UPnP.

  FIG. 4 is a block diagram showing a hierarchical structure of various protocols of the MFP device control unit 700. The MFP device control unit 700 has a UPnP device function unit 2400 and three non-UPnP device function units 2210, 2220, and 2230. The UPnP device function unit 2400 includes three UPnP device modules (corresponding to the three devices 810, 820, and 830 in FIG. 1). Each device module includes a service module for executing a service, but is not shown here. Below the UPnP device function unit 2400 and the non-UPnP printer function unit 2210 are a D4 packet processing unit 2300 and a USB printer class driver 2310. A USB scanner class driver 2320 and a USB storage class driver 2330 exist below the non-UPnP scanner function unit 2220 and the non-UPnP storage function unit 2230. Below the three device drivers 2310, 2320, and 2330 are a USB logical device and a USB device interface (hardware). As can be understood from this hierarchical structure, when the UPnP scanner device or UPnP storage device provides services to the control point, the USB printer class driver 2310 is used between the MFP server 300 and the MFP device control unit 700. Data transfer. Therefore, the D4 packet can also be used when transferring data for UPnP scanner devices and UPnP storage devices.

  As shown in FIG. 4, seven types of UPnP bidirectional communication channels are provided between the USB printer class driver 1310 of the MFP server 300 and the USB printer class driver 2310 of the MFP device control unit 700. These are logical channels using D4 packets, and are used when the multi-function device 800 functions as a UPnP device. There are also seven types of UPnP logical channels corresponding to the seven types of logical channels between the printer class drivers 1310 and 2310 between the service protocol interpreter 1000 and the UPnP device function unit 2400. FIG. It is omitted. In the following, a logical channel using D4 packets will be described first.

  FIG. 5 is an explanatory diagram showing an interface / endpoint configuration and a logical channel configuration in USB connection between the MFP server 300 and the MFP device control unit 700. Generally, a USB device has an interface and an endpoint. USB transfer is performed between the USB host and the endpoint. In other words, the “end point” is a logical resource that communicates with the host. In the example of FIG. 5A, seven end points EP # 0 to EP # 6 are shown. The control end point EP # 0 is an end point for transmitting / receiving a standard device request. A “standard device request” is a basic request that needs to be supported by all USBs. Therefore, one control endpoint EP # 0 is always provided for one USB device.

  The printer bulk-out endpoint EP # 1 and bulk-in endpoint EP # 2 are endpoints for receiving and transmitting messages for the print engine 810. Similarly, the bulk-out endpoint EP # 3 and the bulk-in endpoint EP # 4 for the scanner are endpoints for receiving and transmitting a message for the scanner engine 820. The storage endpoints EP # 5 and EP # 6 are endpoints for receiving and transmitting messages for the memory card (PC card interface 830). In general, in a USB device, endpoints other than the control endpoint EP # 0 are classified by a logical interface. In the example of FIG. 5A, a printer interface IF # 0, a scanner interface IF # 1, and a storage interface IF # 2 are provided as logical interfaces.

  In this embodiment, as shown in FIG. 5B, nine logical channels are provided in the printer interface IF # 0. The function of each of these channels is as follows.

(1) PRINT-DATA channel CH # 11:
A channel for transmitting / receiving print data transferred from the printer driver 100D (FIG. 1) from the personal computer 100 on the network using a print port (port number or port number 9100 according to the LPR port). It is not shown in FIG.

(2) PRINT-STATUS channel CH # 12:
The MFP server 300 is a channel for transmitting and receiving information indicating the state of the print engine 810, and is provided from the MFP server 300 to the personal computer 100 on the network by a protocol such as SNMP. It is not shown in FIG.

(3) UPNP-LOCALCONTROL channel CH # 21:
A UPnP channel for performing communication between the MFP server 300 and the MFP device control unit 700 with the MFP server 300 as a requester and the MFP device control unit 700 as a responder. The MFP server 300 can acquire various types of information from the MFP device control unit 700 using this channel.

(4) UPNP-LOCALEVENT channel CH # 22:
A UPnP channel for performing communication between the MFP server 300 and the MFP device control unit 700 with the MFP device control unit 700 as a requester and the MFP server 300 as a responder. Using this channel, the MFP device control unit 700 can notify the MFP server 300 of the contents of setting changes made by the user on the multifunction device 800, and when the multifunction device 800 is turned off, UPnP A request to end the protocol can be notified to the MFP server 300.

(5) UPNP-PRESENTATION channel CH # 23:
A channel for transmitting and receiving UPnP presentation data (Web page data). A channel (down channel) for transmitting presentation data from the MFP device control unit 700 to the control point in response to a control point request, and a new presentation data for uploading from the control point to the MFP device control unit 700. A channel (up channel) may be provided separately.

(6) UPNP-CONTROL channel CH # 24:
In UPnP, a channel for transmitting and receiving data related to an action transmitted from a control point. The reason why the above-mentioned UPNP-LOCALCONTROL channel is prefixed with “LOCAL” is that the UPNP-LOCALTONTROL channel is not used for transferring action contents from the control point. In other words, the UPNP-CONTROL channel CH # 24 is used only for transmission / reception of data related to the action transmitted from the control point.

(7) UPNP-EVENT channel CH # 25:
In UPnP, a channel for sending events to subscribing control points. The reason why the above-mentioned UPNP-LOCALEVENT channel is prefixed with “LOCAL” is that this UPNP-LOCALEVENT channel is not used for sending events to the control point. In other words, the UPNP-EVENT channel CH # 25 is used only for transmitting an event generated in the multi-function device 800 to the control point.

(8) UPNP-DOWNCONTENTx channel CH # 26x:
In UPnP, a transmission / reception channel used when content data is downloaded from a control point to the MFP device control unit 700. Here, the suffix “x” means the x-th channel among Ndown (Ndown is an integer of 2 or more) UPNP-DOWNCONTENT channels. The number NUP of available UPNP-DOWNCONTENTx channels can be arbitrarily set to 1 or more, but is preferably set to a value of 2 or more. If Ndown is set to a value of 2 or more, it is possible to receive content data of a plurality of controls in parallel.

(9) UPNP-UPCONTENTx channel CH # 27x:
In UPnP, a transmission / reception channel used when uploading content data from the MFP device control unit 700 to a control point. The suffix “x” means the x-th channel among Nup (Nup is an integer of 2 or more) UPNP-UPCONTENT channels. The number Ndown of UPNP-DOWNCONTENTx channels and the number Nup of UPNP-UPCONTENTx channels may be the same or different. It can be understood that the actual number of UPnP logical channels in FIG. 5B is (5 + Ndown + Nup).

  Each logical channel can perform bidirectional communication using both the bulk-out endpoint EP # 1 and the bulk-in endpoint EP # 2. The identification information of the logical channel is registered in the header of the USB packet.

  As described above, the nine types of logical channels shown in FIG. 5 are used for USB connection between the MFP server 300 and the MFP device control unit 700. On the other hand, in the USB connection between the MFP device control unit 700 and the multifunction device 800, only two logical channels of the PRINT-DATA channel CH # 11 and the PRINT-STATUS channel CH # 12 are used. Preferably it is. This is because the MFP device control unit 700 interprets various messages received in accordance with the UPnP protocol and converts them into control data for the multi-function device 800, and the control data (mainly) via the PRINT-DATA channel CH # 11. This is because it has a function of transferring to the multifunction device 800. However, the same nine types of logical channels as shown in FIG. 5 may also be used in the USB connection between the MFP device control unit 700 and the multifunction device 800. Also in the USB connection between the MFP server 300 and the MFP device control unit 700, a smaller number of logical channels than in FIG. 5 may be used.

  FIG. 6 is an explanatory diagram showing the structure of a D4 packet used for USB transfer via the printer interface IF # 0. This is a packet structure conforming to IEEE1284.4. This D4 packet is composed of a header part of 12 bytes and a message part of 0 bytes or more. The header part has a 6-byte D4 standard header, a 4-byte ID field, and a 2-byte error code field. In the D4 standard header, socket IDs (logical channel IDs) for identifying nine types of (7 + Ndown + Nup) logical channels shown in FIG. 5B are registered. A request ID is registered in the ID field. This request ID is used to identify packets constituting the same message in data transfer between the MFP server 300 and the MFP device control unit 700 (particularly the UPNP-DOWNCONTENTx channel and the UPNP-UPCONTENTx channel). The request ID is assigned by the MFP server 300 and assigned by the MFP device control unit 700. Therefore, it is preferable to provide a bit (for example, the most significant bit) that can uniquely identify which of the MFP server 300 and the MFP device control unit 700 is assigned to the request ID. The request ID is also referred to as “job ID”.

  In the D4 packet, since various logical channels can be configured using the header portion, various data transfers can be realized using various logical channels. In addition, since header information other than the D4 standard header can be set arbitrarily to some extent, there is an advantage that the degree of freedom of contrivance for executing various controls is high.

  When a request is transferred using the D4 packet according to the present embodiment, a URI (notice that the message is sent from the sender of the message to the receiver (receiver)) at the head of the message after the error field (also called “message header”) Usually, a relative URI) is added. The recipient of the message can easily determine the content and destination of the request from this URI.

  As shown in FIG. 5B, in this embodiment, logical ports CH # 11 to CH # 12 for print ports are used as logical channels for USB transfer between the MFP server 300 and the MFP device control unit 700. And logical channels CH # 21 to CH # 27x for UPnP are provided separately. Accordingly, the print data transferred to the MFP device control unit 700 via the network print port, and the content data (for example, XHTML data for printing) transferred to the MFP device control unit 700 via the UPnP port Can be easily identified. Further, in this embodiment, a plurality of logical channels CH # 21 to CH # 27x having different uses are provided for USB transfer of messages using the UPnP protocol, so that message content processing is performed on the message receiving side. It is possible to process at higher speed. In particular, in this embodiment, in addition to the logical channels CH # 23 to CH # 27x used for communication with the control point, local information transfer between the MFP server 300 and the MFP device control unit 700 is performed. Are separately provided with logical channels CH # 21 and CH # 22. Accordingly, for example, a message sent from a client (control) and specific information notified between the MFP server 300 and the MFP device control unit 700 can be easily distinguished, and processing suitable for each can be quickly executed. Is possible.

  FIG. 7 is a sequence diagram illustrating a typical example of processing using the UPnP architecture. Here, a case where a message is transferred among the control point 110C, the MFP server 300, and the MFP device control unit 700 is shown. Actually, control data and status information are exchanged between the MFP device control unit 700 and the multi-function device 800, but the illustration is omitted in FIG. 7 for convenience. In step [1], the control point 110C transfers the HTTP request message F1 to the MFP server 300. The header of the message F1 includes a request command method (such as POST or GET), a URI indicating a destination in the MFP device unit 400, and a network device 900 (FIG. 1) including the relay unit 600 and the multi-function device 800. The host name (IP address “169.254.100.100” in this example) is described. Since only one IP address is assigned to the network device 900, this IP address is the IP address of the MFP server 300, the IP address of the MFP device control unit 700, or the IP address of the multifunction device 800. It is also possible to think.

  In step [2], the MFP server 300 analyzes the request message F1. Here, only the header portion of the message F1 is analyzed (interpreted), and the content of the transmission data (that is, the message body) is not interpreted. More specifically, in step [2], the URI of the message F1 is analyzed to determine which logical channel should be used to transfer the message to the MFP device control unit 700. Note that some messages F1 have no substantial message body.

  In step [3], the MFP server 300 transfers the message F2 including the URI and the message body (if present) to the MFP device control unit 700 via USB. In this transfer, a logical channel selected according to the URI is used.

  In step [4], the MFP device control unit 700 executes processing according to the URI and message body (if any) in the received message F2. Specifically, for example, the MFP device control unit 700 interprets the content of the message body to create control data for the multi-function device 800, and transfers the control data to the multi-function device 800 for operation. In step [5], the MFP device control unit 700 transfers the message R1 including the response data to the MFP server 300 via USB. In step [6], the MFP server 300 adds an HTTP header to the transmission data. This HTTP header includes a status code indicating the processing result of the HTTP request. For example, if the processing result is OK, the status code is set to “200”, and if it is an error, it is set to “500”. In step [7], the HTTP response message R2 thus created is transferred from the MFP server 300 to the control point 110C.

  As described above, in this embodiment, the MFP server 300 analyzes (interprets) the header in the request message received from the control point, but does not interpret the content of the message body, and the message body is the MFP device. Processed by the control unit 700. This configuration has the following advantages. The first advantage is that the MFP server 300 does not need to grasp the device configuration of the device unit (multifunction device 800) and the contents of the service, and transfers a message sent to a device unit having an arbitrary configuration. It can function as a network protocol control unit. The second advantage is that even if the device configuration of the device unit and the contents of the service are changed, it is not necessary to change the configuration and functions of the MFP server 300. A third advantage is that since it is not necessary to mount an interpretation unit (parser) that interprets the content of the message body in the MFP server 300, the configuration of the MFP server 300 can be simplified.

C. Device configuration of device and device description:
FIG. 8 is an explanatory diagram illustrating a device configuration of the MFP 800 on the UPnP protocol. In the configuration of the MFP 800 (more precisely, the network device 900) of this embodiment as a UPnP device, a printer device (Printer device) and a scanner device (Scnanner) are included in the basic device (Basic device) as the root device. Device) and storage device (Storage device). In other words, the printer device, the scanner device, and the storage device are embedded devices in the basic device. The basic device is a standard device standardized by UPnP, and is a device that does not have a unique service that is executed by itself.

  The printer device has two print services “PrintBasic” and “PrintEnhanced”. These two services are standard print services standardized by UPnP. The scanner device has a scan service “Scan”, and the storage device has a storage service “Storage”. Each service includes a state table, a control server, and an event server. In the status table, a status variable indicating the status of the service is registered. The control server receives the action request from the control point and executes the process. When the value of the state variable is changed, the event server notifies the control point of the change as an event. The target of notification is a control point that subscribes to the service in advance.

  In this specification, a device including a service is called a “service device”. As can also be seen from FIG. 8, each service device may include any number of one or more services. It is also possible to construct a device configuration so that a certain service device includes other service devices.

  Instead of using a basic device, for example, a printer device can be set as a root device, and other devices (scanner and storage) can be configured as an embedded device of the printer device.

  As shown in FIG. 8, in this embodiment, only one IP address is assigned to the entire network device 900, so that the control point uses the one IP address to perform various services of the multi-function device 800. The advantage is that the device can be accessed.

  A UPnP-compatible device holds its configuration and functions in the form of a device description in advance, and has a function of providing a device description in response to a request from a control point. The contents of the service are held in the device in the form of a service description and provided to the control point. In the example of FIG. 8, device descriptions of three devices and service descriptions of four services are created and held by the description creation module 710 in the MFP device control unit 700.

  FIG. 9 shows an example of the device description of the entire multifunction device 800. The device description is described in XML. A portion with an underline indicates a setting specific to the present embodiment. The content “http://169.254.100.100:80” of the element <URLBase> includes a host name (IP address here) of the network device 900 and a port number when using HTTP. Various URIs in the description are described as relative addresses to this IP address. In the present specification, the term “URI” (or URL) includes both the case of being described by an absolute address and the case of being described by a relative address. Hereinafter, a relative address with respect to the IP address is referred to as a “path name”.

  One element <device> exists under the element <root>, and three more elements <device> are included in this element. The first element <device> is a basic device (root device), and the three lower devices are a printer device, a scanner device, and a storage device.

The following contents are described in the description for the printer device.
<Presentation URL>: URL when the control point acquires a page for presentation of the printer device. This URL is composed of a path name “/ PRESENTATION / PRINTER”.
<ServiceList>: A list of services provided by the printer device.
<ServiceType>: Type of service provided by the printer. “PrintBasic” and “PrintEnhanced” are both standard print services of the UPnP architecture.
<SCPDURL>: The path name of the printer device description.
<ControlURL>: Control server path name in the printer device. The control server is a server that provides a control point function (a process in which the control point transfers a control message including an action request to the device to control the device), and is generally included in the service of the UPnP device. Is provided.
<EventSubURL>: Path name of the event server in the printer device. The event server is a server that issues events to subscribing (subscribing) control points, and is generally provided in a device service.

  In the descriptions for the scanner and the storage, items similar to those for the printer are described. In the device description, various other properties such as a friendly name of the device, a manufacturer name, a model name, and an icon are described, but the illustration is omitted here.

  The device description is preferably configured to include at least information indicating the URI (URLBase) of the entire device unit and the device type (Basic or Printer), and is usually described in XML. . When the device includes a service, the device description preferably includes information indicating a service type (PrintBasic or PrintEnhanced), a service control server destination, and an event server destination.

D. First embodiment:
FIG. 10 is a sequence diagram showing a processing sequence in the first embodiment. In the first embodiment, a process when the power of the multi-function device 800 is turned off or when the USB connection between the multi-function device 800 and the relay unit 600 is disconnected will be described.

  In step [1], the MFP 800 notifies the MFP device control unit 700 that the MFP 800 has been turned off or that the USB connection between the MFP 800 and the relay unit 600 has been disconnected. The Instead of notifying the multifunction device 800, the MFP device control unit 700 may periodically poll the status of the multifunction device 800 to detect power-off of the multifunction device 800 or disconnection of the USB connection. The disconnection of the USB connection is also referred to as “loss of USB connection”. Here, “loss of USB connection” has a broad meaning including not only physical disconnection of a cable or connector but also a case where communication becomes impossible for a predetermined period or more.

  When the MFP device control unit 700 knows that the multifunction device 800 is powered off, it transmits a reset request to the MFP server 300 in step [2]. In step [3], the MFP server 300 transmits a shutdown notification to the MFP device control unit 700 as a response to the reset request. In step [4], the MFP server 300 multicasts a ByeBye notification to the control point. The shutdown notification is a notification for notifying that the MFP server 300 is to be restarted. The ByeBye notification is a notification for notifying all control points that the MFP device is leaving the network in the UPnP protocol. The reason why the MFP server 300 performs restart by multicasting the ByeBye notification is that, in the UPnP standard, it is determined that these operations are performed when a device description is recreated. Thereafter, the MFP server 300 is restarted. The MFP device control unit 700 may be restarted together with the MFP server 300. Note that steps [2] to [4] and restart of the MFP server 300 may be omitted.

  In step [5] in FIG. 10, the MFP server 300 requests device information from the MFP device control unit 700. This request for device information is a process performed when the MFP server 300 is activated. The number of devices included in the UPnP-compatible network device 900, the number of services, the device type of each device, and the service type of each service Is performed in order for the MFP server 300 to acquire various types of device information including. In step [6], the MFP device control unit 700 requests a service device and service information that can be provided by the MFP 800 by transferring a status request to the MFP 800 in response to the device information request. However, since the MFP 800 is powered off, no response is returned to the status request. When a predetermined time elapses from the status request, the MFP device control unit 700 determines that an error due to timeout has occurred (step [7]). Further, the MFP device control unit 700 notifies that the number of devices is 1 as a response to the device information request (step [8]). Here, the reason that the number of devices is 1 is that the description generation unit 710 in this embodiment creates a device description that includes only a basic device as a device description when the MFP 800 is powered off. (Step [13]).

  FIG. 11 is an explanatory diagram illustrating an example of a device description when the MFP 800 is powered off. As can be understood by comparing with the device description during normal operation in FIG. 9, the description of the device (printer, scanner, storage) that provides the service is deleted when the power is turned off, and the device does not include the service. Only the basic device remains. Even when the power is turned off, it is preferable to describe the presentation URL of the basic device (the URL of the Web page provided to the client) in order to display a screen related to the multifunction device 800 on the client. In the example of FIG. 11, the relative address “/ PRESENTATION / BAIC” is described as the presentation URL of the basic device.

  FIG. 12 is an explanatory diagram showing a comparison of device configurations of the network device 900 during normal operation and when the multifunction device 800 is powered off. As can be understood from this figure, when the multifunction device 800 is powered off, a device description is generated on the assumption that the network apparatus 900 is configured only with basic devices that do not have services to be provided to clients.

  In step [8] in FIG. 10, in addition to the number of devices being 1, it is also notified that the device type is “Basic” and the number of services is 0. Note that the request and reply may be repeated a plurality of times in steps [5] to [8] in order for the MFP server 300 to acquire a plurality of types of information. The processes up to step [8] are performed when the multifunction device 800 is powered off.

  In the example of FIG. 10, in the subsequent step [9], the M-Search request is multicast from the control point 120C. The M-Search request is issued by the control point for searching for devices in the UPnP protocol. In response to this request, all UPnP-compatible network devices connected to the network return responses to the control point 120C that issued the request (step [10]).

  Thereafter, the control point 120C requests each network device to transfer the device description (step [11]). When the MFP server 300 transfers this request to the MFP device control unit 700 (step [12]), the MFP device control unit 700 recreates the device description described in FIG. 11 (step [13]). Note that the MFP device control unit 700 may re-create the device description at an earlier time.

  The device description thus created is transferred from the MFP device control unit 700 to the MFP server 300 in step [14], and further transferred to the control point 120C in step [15]. FIG. 13A shows an example of a screen displayed on the control point 120C (digital TV set 120 in FIG. 1) in accordance with the device description. This screen includes various buttons 910 to 950 for using services (printer, scanner, storage (PC card memory)) of the multi-function device 800. However, since the device description shown in FIG. 11 does not include any device that provides a service, the buttons 920, 930, and 940 for selecting these services cannot be selected on the screen of FIG. 13A. It is displayed in the form. The digital TV set 120 has a function of adjusting the display form of the display screen according to the device description. However, instead of implementing this function in the digital TV set 120, data representing such a screen (for example, a Web page) is created by the MFP device control unit 700 (or the MFP server 300) and transferred to the control point 120C. You may do it.

  When the user clicks a button 910 for requesting “top page” on the screen in FIG. 13A, the request for the presentation screen is transferred from the control point 120C to the MFP server 300 (step [16] in FIG. 10). This presentation request is a page transfer request specified by the relative address “/ PRESENTATION / BASIC” described in the presentation URL described in the device description shown in FIG. This presentation request is transferred from the MFP server 300 to the MFP device control unit 700, and in response thereto, a Web page describing the presentation screen is returned as a response (steps [18] and [19]).

  FIG. 13B shows an example of the presentation screen transferred to the control point 120C in step [19] of FIG. In this example, it is described that the multi-function device 800 cannot be used because the power is turned off.

  Note that communication in steps [2] and [3] of FIG. 10 is performed using the UPNP-LOCALEVENT channel (FIG. 5), and steps [5], [8], [12], [14], Communication in [17] and [18] is performed using the UPNP-LOCALCONTROL channel. However, these communications may be performed using logical channels other than these.

  As described above, the first embodiment includes only a basic device that does not have a service to be provided to a client when the MFP 800 is powered off or when the connection between the relay unit 600 and the MFP 800 is lost. Thus, a device description (FIG. 11) is created. Therefore, when the client (control point) receives this device description, it is possible to grasp that the MFP 800 cannot provide the service. In addition, since the client does not perform useless access for requesting various services to the network device 900, it is possible to improve communication efficiency in the network.

E. Second embodiment:
FIG. 14 is a sequence diagram showing a processing sequence in the second embodiment. In the second embodiment, a process in the case where a malfunction exists in the multi-function device 800 when the relay unit 600 is activated will be described.

  When the relay unit (the MFP server 300 and the MFP device control unit 700) is activated, the MFP server 300 requests device information from the MFP device control unit 700 in step [1]. This device information request is the same as the request in step [5] in FIG. In response to this device information request, the MFP device control unit 700 transfers a status request to the multi-function device 800 (step [2]), and the multi-function device 800 returns a response (step [3]). Here, various device information including the number of active devices N (N is an integer of 1 or more) is returned. For example, it is assumed that a problem has occurred in the print engine 810 among the three devices 810, 820, and 830 (FIG. 1) that can be used during normal operation. In this case, N = 2 is returned as the number of operating devices, and a scanner and a PC card interface (storage) are returned as operating device types. Such a response is also transferred from the MFP device control unit 700 to the MFP server 300 (step [4]).

  The processes in steps [5] to [15] in FIG. 14 are basically the same as the processes in steps [9] to [19] in FIG. FIG. 15 is an explanatory diagram illustrating a device configuration when a problem has occurred in the print engine 810 in comparison with a device configuration during normal operation. In this example, since the print engine 810 is in a state where it cannot be used due to a problem, the printer device and its service are not included, and the basic device includes only the scanner device and the storage device. . Note that the device description created in step [9] of FIG. 14 is obtained by deleting the printer device portion from that shown in FIG.

 FIG. 16A shows an example of a screen displayed on the digital TV set 120 in response to the response of step [11] in FIG. In this screen, the button 920 corresponding to the device in which the malfunction has occurred cannot be selected from among the three buttons 920, 930, and 940 for selecting the service of the multifunction device 800.

  FIG. 16B shows an example of a presentation screen transferred to the digital TV set 120 in response to the response of step [15] in FIG. In this example, it is explained that the printer cannot be used because maintenance is required.

  In addition, problems that make the print engine 810 unusable include overflow of ink waste liquid, sticking of the carriage of the print head (inoperable), and the like. Further, as a problem that the scanner engine 820 becomes unusable, a scanner lamp failure (lamp out) or the like can be considered. When these presumed failures occur, the multi-function device 800 notifies the MFP device control unit 700 of the occurrence of the failure in the response to the status request (steps [3] and [22] in FIG. 14). .

  As described above, in the second embodiment, when the relay unit 600 is activated, when some of the devices 810, 820, and 830 included in the multi-function device 800 are defective and cannot be operated, A device description with the device deleted is created. Therefore, when the client receives this device description, it is possible to recognize that some devices cannot provide the service.

F. Third embodiment:
FIG. 17 is a sequence diagram showing a processing sequence in the third embodiment. In the third embodiment, a process will be described in the case where a failure occurs in a device in the multifunction device 800 while both the relay unit 600 and the multifunction device 800 are operating.

  In step [1], the multi-function device 800 notifies the MFP device control unit 700 that a problem has occurred in a device in the multi-function device 800. At this time, it is preferable that the MFP device control unit 700 cancels the process being executed in the multifunction device 800 and causes the multifunction device 800 to transition to the idle state.

  The processes after step [2] in FIG. 17 are basically the same as those after step [2] in FIG. That is, the MFP server 300 is restarted to re-create a device description that reflects the operating state of the multifunction device 800, and a UPnP service is provided in accordance with this device description. If several devices in the multifunction device 800 are operable in the third embodiment, status information is returned from the multifunction device 800 to the MFP device control unit 700 in step [7] in FIG. This is different from the processing in FIG. Since the other points are almost the same as those of the first embodiment (FIG. 10) and the second embodiment (FIG. 14), detailed description is omitted.

  As described above, in the third embodiment, when a malfunction occurs in at least some of the plurality of devices 810, 820, and 830 included in the multi-function device 800 during operation and the devices cannot be operated, The deleted device description is created. Therefore, when the client receives this device description, it is possible to grasp that the inoperable device cannot provide the service.

G. Variation:
The present invention is not limited to the above-described examples and embodiments, and can be implemented in various modes without departing from the gist thereof. For example, the following modifications are possible.

G1. Modification 1:
In the above embodiment, the UPnP-compatible network device 900 is a device having the multi-function device 800 including a plurality of devices. Instead, a single-function network device including only one device (for example, a printer) is employed. It is also possible to do. In other words, the network device may have at least one device.

G2. Modification 2:
In the above embodiment, a part of the configuration realized by hardware may be replaced with software, and conversely, a part of the configuration realized by software may be replaced by hardware.

It is a conceptual diagram which shows the structure of the network system to which the Example of this invention is applied. FIG. 2 is a block diagram showing an internal configuration of an MFP server and an MFP device control unit in a relay unit. 3 is a block diagram showing a hierarchical structure of various protocols of the MFP server. FIG. It is a block diagram which shows the hierarchical structure of the various protocols of an MFP device control unit. 3 is an explanatory diagram showing an interface / endpoint configuration and a logical channel configuration in USB connection between an MFP server and an MFP device control unit. FIG. It is explanatory drawing which shows the structure of the packet used for USB transfer via a printer interface. It is a sequence diagram which shows the typical example of the process using UPnP architecture. It is explanatory drawing which shows the UPnP device structure of an Example. FIG. 11 is an explanatory diagram illustrating an example of a device description of a multifunction peripheral. It is a sequence diagram which shows the process sequence in 1st Example. It is explanatory drawing which shows an example of the device description produced in 1st Example. 3 is an explanatory diagram showing a comparison of device configurations of a network device during normal operation and when a multifunction device is powered off. FIG. It is explanatory drawing which shows the example of the screen displayed on a digital TV set in 1st Example. It is a sequence diagram which shows the process sequence in 2nd Example. 2 is an explanatory diagram showing a comparison of device configurations of a network apparatus during normal operation and when a malfunction occurs in a multifunction peripheral. FIG. It is explanatory drawing which shows the example of the screen displayed on a digital TV set in 2nd Example. It is a sequence diagram which shows the process sequence in 3rd Example.

Explanation of symbols

DESCRIPTION OF SYMBOLS 100 ... Personal computer 100D ... Printer driver 110 ... Digital camera 110C ... Control point 120 ... Digital TV set 120C ... Control point 130 ... Image server 300 ... MFP server 302 ... Network protocol control part 310 ... Central control part 320 ... RAM
330 ... ROM
340 ... Network control unit 342 ... Connector 350 ... USB host control unit 352 ... Root hub 354, 356 ... USB connector 410 ... Central control unit 420 ... RAM
430 ... ROM
460 ... USB device control unit 462 ... USB connector 510 ... USB host control unit 512 ... Root hub 514 ... USB connector 600 ... Relay unit 700 ... MFP device control unit 710 ... Description creation module 720 ... Web application module 800 ... Multifunction device 810 ... Print engine 820 ... Scanner engine 830 ... PC card interface 840 ... Control unit 900 ... Network device 910-950 ... Button 1000 ... Service protocol interpretation unit 1100 ... UPnP device architecture 1210, 1220, 1230 ... Non-UPnP device function unit 1310 ... USB printer Class driver 1320 USB scanner class driver 1330 USB storage class driver 2210 ... Non-UPnP printer function part 2220 ... Non-UPnP scanner function part 2230 ... Non-UPnP storage function part 2310 ... USB printer class driver 2320 ... USB scanner class driver 2330 ... USB storage class driver 2400 ... UPnP device function part

Claims (5)

Supports network type plug-and-play for relaying between a device unit having N service devices (N is an integer of 1 or more) that provides a service in response to a request from a client on the network, and the network Network relay device,
A description creation unit that creates a device description describing a service device included in the device unit connected to the network relay device and supplies the device description in response to a request from a client on the network; ,
The description creation unit creates a device description that does not include a description of an inoperable service device when one or more service devices of the N service devices of the device unit are inoperable. A network relay device to be supplied to the client. The network relay device according to claim 1,
The description creation unit creates the device description so as to have only a basic device having no service to be provided to a client when all of the N service devices cannot be operated. The network relay device according to claim 2,
The inoperable service device is
(I) powering off the device unit;
(Ii) loss of connection between the device unit and the network relay device;
(Iii) Inability of the service device to operate due to the occurrence of a failure in each service device;
A network relay device generated by any of the above. The network relay device according to any one of claims 1 to 3,
A device control unit that includes the description creation unit and operates the device unit by exchanging information with the device unit;
Network protocol control connected between the network and the device control unit, receiving a message having a message header and a message body from a client on the network, and transferring information of the message body to the device control unit And
With
The network protocol control unit interprets the message header according to the network type plug and play protocol without interpreting the content of the message body received from the client, and is different from the network type plug and play protocol. Sending the message body to the device controller according to a communication protocol;
The network relay device, wherein the device control unit interprets the content of the message body received from the network protocol control unit, and causes the service device to execute a service according to the interpretation result. A method of relaying between a device unit having N (N is an integer of 1 or more) service devices that provide a service in response to a request from a client on the network and the network according to a network type plug and play protocol Because
(A) a network relay device connected between the network and the device unit creating a device description describing a service device included in the device unit connected to the network relay device;
(B) the network relay device supplying the device description in response to a request from a client on the network;
With
The step (a) creates a device description that does not include a description of an inoperable service device when one or more of the N service devices of the device unit are inoperable. A method characterized by that.

Images