The present invention relates to an apparatus and method for transmitting commands and, more particularly, to an apparatus and method for transmitting commands in a network to which a plurality of communication protocols may be applied.
Along with the advance of the digital computer technology, even in office devices and general home appliances which have simple functions and cannot be organically connected to each other, functions such as connection of these devices, cooperation of processes, and the like can be implemented via a network. In order to connect a plurality of devices to each other via a network and to attain data transfer and operation control, a device control protocol is required. Device control protocols with various specifications have been proposed.
Office devices and home electronic appliances can be controlled via a network. As a result, device control applications which appropriately remotely control these devices to add new values continue to come on the market.
When a plurality of device control protocols of different types are used together, a device control application must individually support these device control protocols. As a technique that weakens coupling between such device control application processes and device control protocol processes, a prior art disclosed in, e.g., Japanese Patent Laid-Open No. 2001-306416 is known. In this prior art, even when there are differences depending on different vendors and versions (e.g., different communication protocols, different axial configurations of robots, and the like), common application software can be developed by simple replacement of processing commands.
However, in the aforementioned device control protocols, various specifications and proposals are available. That is, in device control protocols, specifications and bylaws are specified in correspondence with the types of devices to be controlled and the contents of expected cooperation processes. For this reason, with increasing number of classes of devices having cooperation functions via a network, the number of types of device control protocols increases. On the other hand, as shown in
It is an object of the present invention to make it unnecessary for a device control application to individually support a plurality of device control protocols.
It is another object of the present invention to implement an appropriate device cooperation process.
According to the present invention, an apparatus and method for transmitting commands in a network to which a plurality of communication protocols may be applied are provided. A first command that supports a plurality of communication protocols is input. One of the plurality of communication protocols is selected in accordance with the input first command. The first command is converted into a second command in the selected communication protocol. The converted second command is transmitted using the selected communication protocol.
Other features and advantages of the present invention will be apparent from the following description taken in conjunction with the accompanying drawings, in which like reference characters designate the same or similar parts throughout the figures thereof.
The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the invention and, together with the descriptions, serve to explain the principle of the invention.
Preferred embodiments of the present invention will be described hereinafter with reference to the accompanying drawings. In the following description, a practical arrangement example will be explained. However, the present invention is not limited to such practical arrangement example.
In this embodiment, the device control application 101 and device control protocols 103A to 103C have an indirect connection relationship via a virtual protocol 104. That is, a device control request output from the device control application 101 is supplied to the virtual protocol processor 105 via the virtual protocol 104 that generalizes functions required for device control, and is then supplied from the processor 105 to the devices 102A to 102C to be controlled via the plurality of device control protocols 103A to 103C.
Note that the device control apparatus is an information processing apparatus which comprises a CPU, ROM, RAM, and the like, and components 202 to 204 of the device control apparatus to be described below correspond to functions which are implemented when the CPU executes a control program stored in the ROM.
In
Modules 202 to 205 form the virtual protocol processor 105 shown in
Reference numeral 202 denotes a virtual protocol providing module which provides a virtual protocol (corresponding to the virtual protocol 104 in
Reference numeral 203 denotes a virtual protocol execution module which receives and interprets a device control request sent from the device control application 201 using the virtual protocol (corresponding to the virtual protocol 104 in
Reference numeral 204 denotes a virtual protocol conversion module, which converts the processing contents of the virtual protocol into those of a device control protocol used in device control. A plurality of virtual protocol conversion modules 204 are present in correspondence with the number of devices to be controlled, and can be arbitrarily added or deleted at the time of startup and during operation of the device control apparatus.
Reference numeral 205 denotes a virtual protocol transfer module which transfers the control contents determined by the virtual protocol execution module 203 to the virtual protocol conversion module 204. If there are a plurality of virtual protocol conversion modules 204, the virtual protocol transfer module 205 transfers the control contents determined by the virtual protocol execution module 203 to a corresponding one of the virtual protocol conversion modules 204.
As a communication protocol used in a communication route between each virtual protocol conversion module 204 and device to be controlled (corresponding to devices 102A to 102C to be controlled in
Reference numeral 301 denotes a status information holding unit which holds status information that indicates the status of a device to be controlled.
Reference numeral 302 denotes a profile information holding unit which holds profile information indicating the specifications of a device to be controlled.
Reference numeral 303 denotes a set information holding unit which holds information of a set of devices that can be manipulated in a device network.
Reference numeral 304 denotes an interpretation unit which interprets processing contents (a device control request sent from the device control application 201) expressed by the virtual protocol.
Reference numeral 305 denotes a determination unit which determines actual control contents on the basis of the interpretation result of the interpretation unit 304.
The virtual protocol aims at providing means that generalizes functions required for device control, and is specified by extracting and reconstructing functions which may be required in device control from those of various protocols.
The virtual protocol includes a set of commands that command device control. Each command includes a plurality of pieces of information: a command name, input parameter list, output parameter list, and processing attribute. The command name is an identification name of a command as the most basic element that forms the virtual protocol. The input parameter list is a list of information required on the device control application side upon executing a command. The output parameter list is a list of information of processing results obtained after execution of a command. The processing attribute guide information upon developing a command to a plurality of actual device control protocols. A command is developed by the determination unit 305 shown in
For example, UPnP, JXTA, and the like have common functions such as search and the like, but these functions are processed using different names and parameters.
In
In
In
In
The status information is used to indicate the status of a device, and includes a ready flag and busy flag.
The ready flag indicates whether or not a corresponding device is ready to use. For example, if a device is ON, the ready flag is “OK”; otherwise, it is “NO”.
The busy flag indicates whether or not the process of a corresponding device is now in progress. For example, if a device is a printer and its print process is in progress, the busy flag is “NG”; otherwise, it is “OK”.
The profile information is used to publish the specification indicating performance and the like of a device, and includes, e.g., ID, model name, model number, vendor, address, and owner data.
The ID data is a character string used to uniquely identify a physical entity of a device. For example, the ID data is “urn:abc-magnet:12345678”.
The model name data is a character string indicating the type of device. For example, the model name data is “printer”.
The model number data is a character string indicating the model number of a device. For example, the model number data is “ABC Printer X123”.
The vendor data is a character string indicating the vendor of a device. For example, the vendor data is “ABC corporation”.
The address data indicates an address of the device n the device network. For example, when TCP/IP is used, the address data is “150.61.1.2”.
The owner data indicates the owner of a device. For example, if an e-mail address is used, the owner data is “User-name@abc.co.jp”.
In step S701, a processing request (device control request) sent from the device control application 201 is accepted using the virtual protocol provided by the virtual protocol providing module 202.
In step S702, the virtual protocol execution module 203 interprets the processing request (processing contents expressed by the virtual protocol) sent from device control application 201 via the virtual protocol. Especially, this process is executed by the interpretation unit 304 in the virtual protocol execution module 203. For example, when a “status acquisition” command is issued as the virtual protocol from the device control application 201, the unit 304 determines with reference to the virtual protocol table shown in
In step S703, the virtual protocol execution module 203 determines actual control contents on the basis of the interpretation result of the interpretation unit 304. Especially, this process is executed by the determination unit 305 in the virtual protocol execution module 203. That is, in the above example, on the basis of the interpretation result, i.e., “input=device ID” and “output=status information” in the status acquisition command interpreted by the interpretation unit 304, the unit 305 searches the set information holding unit 303 using the device ID to determine a device control protocol actually used by the device with that ID, and determines that the corresponding virtual protocol conversion module 204 is selected to issue a status acquisition processing request according to the determined device control protocol.
In step S704, the control contents determined by the determination unit 305 are converted into the processing contents of the device control protocol used in actual device control. This process is executed by a corresponding one of the plurality of virtual protocol conversion modules 204, which receives the control contents via the virtual protocol transfer module 205.
It is checked in step S705 on the basis of the control contents determined in step S703 if an end condition is met. If the end condition is not met, the flow advances to step S704 to execute the same process for another device control protocol. On the other hand, if the end condition is met, this device control process ends.
Note that the end condition reflects the contents (parallel, independent, serial) of the processing attribute shown in
For example, if there are two device control protocols, i.e., UPnP and JXTA, and if a “player list acquisition” command, which instructs to “list up currently ready devices”, as one of device information acquisition commands, is issued, both the UPnP and JXTA protocols are selected. The corresponding protocol conversion modules 204 convert the device information acquisition command into a UPnP device discovery command and JXTA peer discovery command. At this time, since an action to “discover a device” has no order of superiority between the protocols, both the UPnP and JXTA protocols “simultaneously (parallelly)” issues device discovery commands (UPnP device discovery command and JXTA peer discovery command).
By contrast, when a “search” command, which instructs to “search for a device”, as one of the device information acquisition commands, is issued, both the UPnP and JXTA protocols are selected. However, if the corresponding device is found, the process can be aborted at that time. Hence, the process is “sequentially (serially)” executed so that a search is conducted using the UPnP protocol as one of the selected protocols, and a search is conducted using the other JXTA protocol if a device cannot be found. Or if a command (profile acquisition) that instructs to “acquire predetermined information of a device” comes from the virtual protocol, since this command need only be issued by the protocol that can connect the device, a process is independently (if the protocol that can connect the device is UPnP, UPnP alone) (the process is done based on the processing attribute of
In this manner, in an environment in which a plurality of device control protocols of different types are used together, when a process is converted from one virtual protocol into a plurality of actual protocols (device control protocols), these actual protocols are executed parallelly, serially, or independently, thereby controlling the order or contents of processes.
In this embodiment, virtual protocol conversion modules 204, which respectively correspond to three different device control protocols “plug & play”, “peer 2 peer”, and “directory server”, are prepared.
The list 801 corresponds to the device ID list which is input to the output parameter list upon execution of the “player list acquisition” command shown in
The user selects and designates a desired device from a list of controllable devices displayed as the list 801, and can enjoy a service provided by that device.
A plurality of device control protocols have different properties and performances. A user interface suited to the user who wants to manipulate the device control application while utilizing the characteristics unique to each individual device control protocol is that shown in
In this manner, the user can select a device in consideration of the profile/status information of devices to be controlled in addition to the identification information of the device control protocol.
As described above, since the relationship between the device control protocol and device control application is changed to loose coupling via the virtual protocol, devices which support different types of device control protocols can form a device network.
Since the order and contents of processes in an environment in which a plurality of device control protocols of different types are used together can be controlled, more appropriate device cooperation processes can be realized.
Furthermore, the device control application need not independently support a plurality of device control protocols of different types.
The present invention has been described by way of its preferred embodiments. However, the present invention is not limited to the above embodiment, and various modifications can be made within the scope of the claims.
In the above embodiment, Internet protocol (IP) is used as the communication protocol used in the communication route between each virtual protocol conversion module 204 and device to be controlled. Instead of this protocol, other communication protocols that can connect devices each other may be used. For example, IPX may be used.
In the above embodiment, a single device control apparatus controls a plurality of devices to be controlled. Alternatively, a plurality of device control apparatuses and a plurality of devices to be controlled may be present on a single device network.
In the above embodiment, one device control protocol corresponds to one virtual protocol conversion module 204. Alternatively, a plurality of device control protocols may correspond to one virtual protocol conversion module 204. Or an arrangement that allow a plurality of virtual protocol conversion modules 204 to implement control of one device control protocol may be adopted.
Note that the present invention may be applied to either a system constituted by a plurality of devices (e.g., an AV device, home electronic appliance, computer device, interface device, and the like), or a single apparatus.
The objects of the present invention are also achieved by supplying a storage medium, which records a program code of a software program that can implement the functions of the above-mentioned embodiments to the system or apparatus, and reading out and executing the program code stored in the storage medium by a computer (or a CPU or MPU) of the system or apparatus.
In this case, the program code itself read out from the storage medium implements the functions of the above-mentioned embodiments, and the storage medium which stores the program code constitutes the present invention.
As the storage medium for supplying the program code, for example, a flexible disk, hard disk, optical disk, magneto-optical disk, CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW, magnetic tape, nonvolatile memory card, ROM, and the like may be used.
The functions of the above-mentioned embodiments may be implemented not only by executing the readout program code by the computer but also by some or all of actual processing operations executed by an OS (operating system) running on the computer on the basis of an instruction of the program code.
Furthermore, the functions of the above-mentioned embodiments may be implemented by some or all of actual processing operations executed by a CPU or the like arranged in a function extension board or a function extension unit, which is inserted in or connected to the computer, after the program code read out from the storage medium is written in a memory of the extension board or unit.
As many apparently widely different embodiments of the present invention can be made without departing from the spirit and scope thereof, it is to be understood that the invention is not limited to the specific embodiments thereof except as defined in the claims.
This application claims priority from Japanese Patent Application No. 2003-320261 filed on Sep. 11, 2003, which is hereby incorporated by reference herein.
Number | Date | Country | Kind |
---|---|---|---|
2003-320261 | Sep 2003 | JP | national |
Number | Name | Date | Kind |
---|---|---|---|
4855905 | Estrada et al. | Aug 1989 | A |
4937825 | Ballard et al. | Jun 1990 | A |
4991133 | Davis et al. | Feb 1991 | A |
5187708 | Nakatani et al. | Feb 1993 | A |
5710761 | Scott | Jan 1998 | A |
6157465 | Suda et al. | Dec 2000 | A |
6222855 | Kimber et al. | Apr 2001 | B1 |
6477570 | Takayama et al. | Nov 2002 | B1 |
6549937 | Auerbach et al. | Apr 2003 | B1 |
6667810 | Jeyachandran et al. | Dec 2003 | B1 |
6775023 | Fukunaga et al. | Aug 2004 | B1 |
7068663 | Adler | Jun 2006 | B1 |
7467018 | Callaghan | Dec 2008 | B1 |
7701958 | Abrol et al. | Apr 2010 | B2 |
20020052966 | Isomura et al. | May 2002 | A1 |
20020118800 | Martinez et al. | Aug 2002 | A1 |
20020161907 | Moon | Oct 2002 | A1 |
20020165975 | Abbott | Nov 2002 | A1 |
20020181497 | Mano et al. | Dec 2002 | A1 |
20030093541 | Lolayekar et al. | May 2003 | A1 |
20030204612 | Warren | Oct 2003 | A1 |
20040015409 | Chittenden et al. | Jan 2004 | A1 |
Number | Date | Country |
---|---|---|
2001-306416 | Nov 2001 | JP |
2002-196990 | Jul 2002 | JP |
Number | Date | Country | |
---|---|---|---|
20050060419 A1 | Mar 2005 | US |