Information processor, control method of information processor, and computer program
7 claims: 3 independent, 4 dependent
- 1It is a device search device A receiving means for receiving a search request for searching a device and including specific information for identifying a device search device to which the search request has been transferred. A search means for searching for a device satisfying a search condition included in a search request received by the receiving means, a storage means for storing information indicating another device search device, and the storage means for storing based on the specific information. Among the other device search devices indicated by the information, the search request received by the receiving means is transferred to the device search device to which the search request has not been transferred, and the search request is received by the transferred device search device. A device search device comprising:a transfer means that does not transfer a search request received by the means. デバイス検索装置であって、 デバイスを検索するための検索要求であって、検索要求を転送済みのデバイス検索装置を特定するための特定情報を含む検索要求を受信する受信手段と、 前記受信手段が受信した検索要求に含まれる検索条件を満たすデバイスを検索する検索手段と、他のデバイス検索装置を示す情報を記憶する記憶手段と、前記特定情報に基づいて、前記記憶手段が記憶している情報が示す前記他のデバイス検索装置のうち、検索要求が転送されていないデバイス検索装置に前記受信手段が受信した検索要求を転送し、検索要求を転送済みのデバイス検索装置に前記受信手段が受信した検索要求を転送しない転送手段とを備えることを特徴とするデバイス検索装置。
- 5Claims 1 to 4, wherein the device search device is connected to a network composed of a plurality of subnets, and the device search device and the other device search device are connected to different subnets. The device search device according to any one of the above items. 前記デバイス検索装置は、複数のサブネットによって構成されたネットワークに接続されており、前記デバイス検索装置と前記他のデバイス検索装置はそれぞれ異なるサブネットに接続されていることを特徴とする請求項1乃至4の何れか1項に記載のデバイス検索装置。
- 6It is a control method of the device search device. A receive step that receives a search request for searching for a device, including specific information for identifying the device search device to which the search request has been transferred. Based on the specific information, the search step for searching for a device satisfying the search condition included in the search request received by the reception step, the storage step for storing information indicating another device search device in the storage means, and the specific information. Among the other device search devices indicated by the information stored in the storage means, the search request received in the receiving step is transferred to the device search device to which the search request has not been transferred, and the device search to which the search request has been transferred is performed. A method for controlling a device search device, which comprises a transfer step in which the receiving means does not transfer the received search request to the device. デバイス検索装置の制御方法であって、 デバイスを検索するための検索要求であって、検索要求を転送済みのデバイス検索装置を特定するための特定情報を含む検索要求を受信する受信ステップと、 前記受信ステップによって受信された検索要求に含まれる検索条件を満たすデバイスを検索する検索ステップと、他のデバイス検索装置を示す情報を記憶手段に記憶する記憶ステップと、前記特定情報に基づいて、前記記憶手段が記憶している情報が示す前記他のデバイス検索装置のうち、検索要求が転送されていないデバイス検索装置に前記受信ステップで受信した検索要求を転送し、検索要求を転送済みのデバイス検索装置に前記受信手段が受信した検索要求を転送しない転送ステップとを有することを特徴とするデバイス検索装置の制御方法。
Independent claims3
99 paragraphs, as filed
The present invention relates to a device search device for searching for a device, a control method for the device search device, and a computer program.
Conventionally, each client such as a personal computer connected to a network can search for and use a device such as a printer connected to the network. As a search method for searching a device, there is a method in which a client transmits search request data by multicast and receives a response to the search request from each device. Further, there is a method in which a search server (Discovery Proxy, hereinafter referred to as DP) that holds information of each device is installed on the network, and the client receives the search result from the search server.
Usually, a network constructed by a LAN (Local Area Network) or the like is composed of a plurality of subnets. Each subnet is connected via a router, and the router often prohibits the data transmitted by broadcasting or multicast received from one subnet from passing through the other subnet as it is. In this case, the search request data sent by the client by broadcast or multicast is sent only within the subnet in which the client exists. Therefore, according to the above-mentioned search method, the client can search only the devices existing in the subnet in which the own device exists.
In order to solve such a problem, that is, to enable searching for devices existing in other subnets, the following methods have been considered (see, for example, Patent Document 1).
Provide a server device that acquires device information from the device. The server device acquires device information from a device on a subnet different from the subnet in which the own device exists. The client acquires information on devices existing in other subnets from the server device.
According to this method, the client can acquire not only the information of the device on the subnet in which the own device exists but also the information of the device on the other subnet.<patcit num="1"><text>Japanese Unexamined Patent Publication No. 2003-6133</text></patcit>
<p> However, in the above-mentioned conventional technique, since the server device needs to manage not only the information of the subnet in which the server device itself exists but also the information of the devices existing in other subnets, the load on the server device increases. On the other hand, in order to distribute the load of the server device, a method of preparing a plurality of server devices and installing the server device for each subnet can be considered. Then, the server device installed in each subnet manages only the device information on the subnet in which the own device exists. In this case, the client sends a search request to the server device installed in the other subnet in order to search for a device on another subnet different from the subnet in which the own device exists. However, as described above, when transmitting by multicast, it is not transmitted to other subnets, so the client must send a search request to this server device using unicast. Therefore, the client needs to know the address of the server device, and the address of the server device must be registered in the client in advance.</p><p> Since a large number of clients are usually connected to each subnet as compared with the server device, registering the address of the server device for these many clients is a complicated task for the user.</p><p> An object of the present invention is to solve such a problem and enable a client to search for a device existing in another subnet more efficiently in a network system having a plurality of subnets connected via a router. And.</p>
<p> In order to solve the above problem, the device search device in the present invention receives a search request for searching a device and includes a search request including specific information for identifying the device search device to which the search request has been transferred. Based on the specific information, the receiving means for searching, the search means for searching for a device satisfying the search condition included in the search request received by the receiving means, the storage means for storing information indicating another device search device, and the specific information. Among the other device search devices indicated by the information stored in the storage means, the device for which the search request has been transferred by transferring the search request received by the receiving means to the device search device to which the search request has not been transferred. The search device is provided with a transfer means that does not transfer the search request received by the receiving means.</p>
<p> According to the present invention, even in a network system having a plurality of subnets connected via a router, devices existing in other subnets can be searched.</p>
(Example 1) FIG. 1 is a diagram showing a configuration of a device search system to which the present invention is applied. The network system of FIG. 1 is composed of three subnets, subnets 1, 2, and 3. Each subnet is configured by a LAN (Local Area Network), and each device connected to the network of FIG. 1 communicates according to TCP / IP.
A Discovery Proxy (hereinafter referred to as DP) 101 is connected to the subnet 1. The IP address of DP101 is 192.168.2.110. In subnet 2, the DP 102, the client PC 104, and the image forming apparatus 108 are connected. The IP address of the DP102 is 192.168.1.10, the IP address of the client PC104 is 192.168.1.1100, and the IP address of the image forming apparatus 108 is 192.168.1.1. The DP103, the client PC 109, and the image forming devices 105 and 110 are connected to the subnet 3. The IP address of DP103 is 192.168.0.10. The IP address of the client PC 109 is 192.168.0.100, the IP address of the image forming apparatus 105 is 192.168.0.1, and the IP address of the image forming apparatus 110 is 192.168.0.2. is there.
Subnet 1 and subnet 2 are connected to each other by router 106. Further, the subnet 1 and the subnet 3 are connected to each other by the router 107. As a result, terminals connected in all subnets can communicate with each other. However, the routers 106 and 107 are set so that the data transmitted by broadcasting or multicast from one subnet is not passed to the other subnet as it is. Therefore, data transmitted by broadcast or multicast is communicated only within each subnet.
Next, in the system configuration shown in FIG. 1, the hardware and software configurations of DP101, DP102, DP103, client PC104, 109, and image forming apparatus 105, 108, 110 will be described. Hereinafter, unless otherwise specified, the symbol 102 is used as a representative for DP, the symbol 104 is used for the client PC, and the symbol 105 is used for the image forming apparatus.
FIG. 2 is a block diagram showing a hardware configuration of the image forming apparatus 105.
The reader unit (image input device) 201 optically reads the original image and converts it into image data. The reader unit 201 includes a scanner unit 202 having a function of reading a document and a document feeding unit 203 having a function of transporting document paper.
The printer unit (image output device) 204 conveys the recording paper, prints the image data as a visible image on the recording paper, and discharges the paper to the outside of the device. The printer unit 204 sorts and staples the paper feed unit 205 having a plurality of types of recording paper cassettes, the print unit 206 having a function of transferring and fixing image data to the recording paper, and the printed recording paper to the outside of the machine. It is composed of a paper ejection unit 207 having an output function.
The control device 210 is electrically connected to the reader unit 201 and the printer unit 204, and is further connected to the client PC 104 via the network 220. The control device 210 includes a CPU, which controls the reader unit 210 and the printer unit 204 by executing a program stored in a storage unit such as a hard disk 260 or a ROM. As a result, the control device 210 provides the following functions. First, the control device 210 controls the reader unit 201 to read the image data of the original, stores the image data in the hard disk 260, controls the printer unit 204, outputs the image data to the recording paper, and performs a copy function. provide. It also provides a scanner function that converts the image data read from the reader unit 201 into code data and transmits it to the client PC 104 via the network 220. It also provides a printer function that converts code data (print data) received from the client PC 104 via the network 220 into image data and outputs the code data to the printer unit 204.
The operation unit 250 is connected to the control device 210, is composed of a liquid crystal touch panel, and provides a user I / F for operating the image input / output system.
The image forming apparatus 105 (device) of FIG. 2 has been described by taking an MFP (Multifunction Peripheral) having a printer function, a scanner function, and a copy function as an example. However, the image forming apparatus (device) in this embodiment is not limited to the MFP, and may be an image forming apparatus such as a printer, a scanner, a copier, or a facsimile apparatus.
FIG. 3 is a block diagram showing the hardware configurations of the DP102 and the client PC104. The DP102 and the client PC104 can use a general-purpose PC (personal computer), and the following description is common. DP101 and DP103 have the same configuration.
In FIG. 3, 301 is a CPU, which controls various devices connected to the system bus 304. Reference numeral 302 denotes a ROM for storing the BIOS and the boot program, and reference numeral 303 denotes a RAM used as the main storage device of the CPU 301. Reference numeral 305 is a keyboard controller (KBC), which performs processing related to input of information and the like from a pointing device 309a such as a mouse (registered trademark) and a keyboard 309b. Reference numeral 306 is a display control unit (CRTC), which has a video memory inside, draws the image data in the video memory according to an instruction from the CPU 301, and outputs the image data drawn in the video memory to the CRT display device 310 as a video signal. To do. Although a CRT is illustrated as a display device in FIG. 3, the type of the display device such as a liquid crystal display device does not matter. Reference numeral 307 is a disk controller (DKC), which accesses a hard disk 311 and a floppy (registered trademark) disk 312. Reference numeral 308 denotes a network interface card (NIC), which connects to a network and performs information communication via the network. The hard disk 311 has an OS (Operating). System) and various application programs running on the OS are stored.
In the above configuration, when the power of the present device is turned on, the CPU 301 reads the OS from the hard disk 311 into the RAM 303 according to the boot program stored in the ROM 302, and functions as an information processing device.
FIG. 4 is an example of a screen displayed on the display device of DP103. In this embodiment, each DP has a function of transferring the search request received from the client PC to another DP. The screen shown in FIG. 4 is a screen for the user to register the DP as the transfer destination to which the DP 103 transfers the search request. The area 401 is an area in which an IP address is input to the DP to be registered. The user inputs the IP address of the desired DP into the area 401 using a keyboard or the like. Then, when the registration button shown in 402 is pressed, the IP address input in 401 is registered as the DP that is the transfer destination for transferring the search request. The registered DP is displayed in the area of 403. In the example of FIG. 4, the case where DP102 is already registered is shown. In the area 403, the name and IP address of the registered DP, and an icon indicating the DP are displayed. The displayed information may be other information.
The user may register a plurality of DPs for the DP 103 using the screen of FIG. In that case, a plurality of DPs will be displayed in the area of 403. Buttons 404 and 405 are buttons that can be pressed when a plurality of DPs are registered. If any of the registered DPs is selected and the 404 button (up arrow button) is pressed, the display order of the selected DPs is moved up by one. Conversely, when the 405 button (down arrow button) is pressed, the display order of the selected DP moves down by one. When a plurality of DPs are registered in the DP 103, the DP 103 determines the order of forwarding the search request according to the display order displayed in the area of 403. That is, the search request is transferred in order from the DP displayed at the top of the area of 403.
FIG. 5 is a block diagram showing software modules of the DP 103, the client PC 109, and the image forming apparatus 105. Each software module shown in FIG. 5 is executed by a CPU included in each device.
In the DP 103, the device information notification receiving unit 511 receives the Hello message or the Bye message transmitted from the image forming apparatus 105. Details of the Hello message and the Bye message will be described later. Then, the device information notification receiving unit 511 processes the device information held by the device information holding unit 514 based on the type of the received message. For example, in the case of a Hello message, it is determined that it is necessary to acquire device information. In that case, the device information acquisition unit 512 transmits a device information acquisition request to the image forming apparatus 105 that has transmitted the Hello message, and holds the responded device information in the device information holding unit 514. On the other hand, if it is a Bye message, it is determined that the device information held in the device information holding unit 514 needs to be deleted. In that case, the device information holding unit 514 deletes the device information of the image forming apparatus 105 that has transmitted the Bye message.
The device information search processing unit 513 receives the search request transmitted from the client PC 109 or another DP. The search request includes search conditions. The device information search processing unit 513 searches for device information satisfying the search condition from the device information held by the device information holding unit 514. Then, the search result is transmitted to the client PC 109. The search request transmitted from the client PC 109 is transmitted by multicast. On the other hand, search requests sent from other DPs are sent by unicast. The search request transfer unit 515 partially rewrites the received search request and transmits it to another DP. The details of the device information held by the device information holding unit 514 will be described later.
In the client PC 109, the device search request processing unit 523 transmits a search request for searching the device by multicast. After that, when the search result transmitted from the DP is received, the search information display unit 524 displays the search result on the display device.
In the image forming apparatus 105, the device information management unit 534 manages the device information of the image forming apparatus 105 itself. The device information notification unit 533 transmits a Hello message or a Bye message. When the device information transmission unit 535 receives the device information acquisition request via the network, the device information transmission unit 535 transmits the device information managed by the device information management unit 534 to the transmission source of the device information acquisition request. The device search processing unit 536 transmits a search response when it receives a search request transmitted by multicast.
FIG. 6 is an example of device information held by the device information holding unit 514 of the DP 103. This device information is stored in a storage unit such as ROM 302 or HD311 included in the DP103. In the example of FIG. 6, the device information holding unit 514 of the DP 103 shows a case where the device information of the image forming devices 105 and 110 is held.
ID601 indicates an ID for identifying device information in DP103. UUID 602 indicates a UUID that globally identifies the device. Version 603 indicates the version of the device information. Device type 604 indicates the type of device such as "MFP" which means a multifunction device and "Printer" which means a printer. The model name 605 indicates the model name of the device such as "LBPXXXX". The device name 606 indicates a name set for the device by the administrator (user). URL 607 indicates a URL for acquiring device information.
Next, a method of registering the device information of the image forming apparatus 105 in the DP 103 will be described. There are two registration methods, and the first method will be explained first.
The image forming apparatus 105 transmits a Hello message as shown in FIG. 7 when the image forming apparatus is activated or when the setting information of the own machine is changed. In this embodiment, the Hello message is described by XML (Extension Markup Language), but may be described by other markup languages such as HTML (HyperText Markup Language). This also applies to other messages described in the following XML format.
The Hello message of FIG. 7 is composed of a header part 701 surrounded by a <Header> tag and a body part 702 surrounded by a <Body> tag, and has a structure in which the whole is surrounded by a <Envelope> tag. This structure is common to all the messages used in this embodiment.
The header section 701 serves as a common header that does not depend on the content of the message, and has a <Action> tag, a <MessageID> tag, and a <To> tag. The <Action> tag is for identifying the type of message. The <MessageID> tag is an identifier for uniquely identifying a message. The <To> tag is for identifying the destination of this message. On the other hand, the structure of the body unit 702 changes according to the content of the message. In FIG. 7, the <Hello> tag exists directly under the <Body> tag, indicating that this message is a Hello message. Among the <Hello> tags, there are <EndpointReference> tag, <Types> tag, <XAddrs> tag, and <MedataVersion> tag. The <Address> tag exists in the <EndpointRefence> tag, and has address information for identifying the device. The <Types> tag has device type information. The <XAddrs> tag has a URL for acquiring device information. The <MedataVersion> tag has a version of device information.
DP103 receives the Hello message. Then, the value of the EndpointReference / Address tag is extracted as the UUID that globally identifies the device from the Hello message, and the value of the Types tag is extracted as the device type. Further, the value of the Metadata Version tag is extracted as the version of the device information, and the value of the XAddrs tag is extracted as the URL for acquiring the device information. Then, the device information holding unit 514 stores the extracted value in the storage unit.
After that, DP103 unicasts a Get message in XML format as shown in FIG. 8 to the URL described by the XAddrs tag. The Get message in FIG. 8 is a message having only a header part. The <Action> tag in the header section indicates that this message is a Get message.
When the device information transmission unit 535 of the image forming apparatus 105 receives the Get message transmitted from the DP 103, the device information transmission unit 535 transmits a Get Response message in XML format as shown in FIG. As a result, more detailed device information of the image forming apparatus 105 will be transmitted to the DP 103.
The Get Response message of FIG. 9 has a structure having device information indicated by a <Metadata> tag in the body part. Among the <Metatatta> tags, there are the MetadataSection units 901, 902, and 903 indicated by the <MetadataSection> tag. The type of information contained in each MetadataSection section is specified by the tag directly below it. The MetadataSection unit 901 has a <ThisDevice> tag, and different information is stored for each device. The <FriendlyName> tag indicates the name given to this device, the <FirewareVersion> tag indicates the firmware version of this device, and the <SerialNumber> tag indicates the serial number of this device. The MetadataSection unit 902 has a <ThisModel> tag, and different information is stored for each model of the device. The <Manufacturer> tag indicates the device manufacturer name, the <Manufacturer> tag indicates the URL of the device manufacturer, the <Presentation URL> indicates the URL indicating the device information, and the <ModelName> tag indicates the model name of the device. The MetadataSection unit 903 has a <Relationship> tag, and stores information on internal services possessed by the device. In this embodiment, the internal service is a print service provided by the image forming apparatus. The <Relationship> tag further has a <Hosted> tag directly under it, and a <EndpointReference> tag, a <Types> tag, and a <ServiceId> tag are present therein. There is an <Address> tag in the <EndpointRefence> tag, and it has address information for using the service. The <Types> tag has service type information. The <ServiceId> tag has an identifier to identify the service in the device.
The DP103 extracts the value of the FriendlyName tag as the device name and the value of the ModelName tag as the model name from the received GetResponse message. Then, the device information holding unit 514 stores the extracted value in the storage unit.
The image forming apparatus 105 transmits a Hello message to the DP 103 when the image forming apparatus is activated or when the setting information of the own machine is changed. The DP 103 may acquire device information as described above each time it receives a Hello message. However, if the previously acquired device information exists in the device information holding unit 514, the version information of Metadata included in the Hello message is compared, and if there is no change, the device information is not newly acquired again. You may.
Next, the second registration method will be described.
The DP103 transmits an XML format probe message as shown in FIG. 11 by multicast at a predetermined timing. The Probe message is an example of a search request in this embodiment. In the Probe message of FIG. 11, a <Probe> tag exists in the body portion, indicating that this message is a Probe message. A <Types> tag can be set in the <Probe> tag, and the <Types> tag specifies the type of device to be searched. That is, the information described in the <Types> tag is the search condition in this embodiment. In the example of FIG. 11, the type is empty, and all devices are searched.
When the image forming apparatus 105 receives the Probe message, the image forming apparatus 105 transmits the XML format Probe Match message as shown in FIG. 12 to the DP 103. In this embodiment, the ProbeMatch message is an example of information indicating a search result. In the ProbeMatch message of FIG. 12, a <ProbeMatches> tag exists in the body part, indicating that this message is a ProbeMatch message. In the <ProbeMatches> tag, there is a ProbeMatch portion indicated by the <ProbeMatch> tag. Each ProbeMatch section corresponds to the search result. That is, the information included in the ProbeMatch unit is the device information that satisfies the search conditions. In the example of FIG. 12, it is shown that one search result is returned. The structure in the ProbeMatch section is the same as in the <Hello> tag in the Hello message of FIG. 7.
DP103 receives a ProbeMatch message. Then, the value of the EndpointReference / Address tag is extracted as the UUID that globally identifies the device from the ProbeMatch message, and the value of the Types tag is extracted as the device type. Further, the value of the Metadata Version tag is extracted as the version of the device information, and the value of the XAddrs tag is extracted as the URL for acquiring the device information. Then, the device information holding unit 514 stores the extracted value in the storage unit.
After that, DP103 unicasts a Get message in XML format as shown in FIG. 8 to the URL described by the XAddrs tag. The device information transmission unit 535 of the image forming apparatus 105 transmits a Get Response message as shown in FIG. The DP103 extracts the value of the FriendlyName tag as the device name and the value of the ModelName tag as the model name from the received GetResponse message. Then, the device information holding unit 514 stores the extracted value in the storage unit.
The DP 103 transmits a probe message at a predetermined timing, and as a result, acquires device information from the image forming apparatus 105. However, if the previously acquired device information exists in the device information holding unit 514, the version information of Metadata included in the ProbeMatch message is compared, and if there is no change, the device information is not newly acquired again. You may.
Next, a method of deleting the device information registered in the DP 103 will be described. When the image forming apparatus 105 stops providing services to client PCs existing in the network, such as when its own machine shuts down, the image forming apparatus 105 transmits an XML format Bye message as shown in FIG. 10 by multicast.
In the Bye message of FIG. 10, a <Bye> tag exists in the body part, indicating that this message is a Bye message. The <EndpointRefence> tag exists in the <Bye> tag. The <Address> tag exists in the <EndpointRefence> tag, and has address information for identifying the device. When the DP103 receives the Bye message, it extracts the UUID information included in the Bye message. Then, the device information holding unit 514 deletes the device information corresponding to the extracted UUID information from the storage unit.
Next, a method in which the client PC 109 searches for an image forming apparatus using the DP 103 will be described.
The client PC 104 transmits an XML format probe message as shown in FIG. 14 by multicast. The Probe message is an example of a search request in this embodiment. In the Probe message of FIG. 14, a <Probe> tag exists in the body portion, indicating that this message is a Probe message. A <Types> tag can be set in the <Probe> tag, and the <Types> tag specifies the type of device to be searched. That is, the information described in the <Types> tag is the search condition in this embodiment. In the example of FIG. 14, "Printer" is specified in the Type tag as an example of the search condition for searching the image forming apparatus. That is, the image forming apparatus whose device type is Printer is searched as a device satisfying the search condition.
When the DP103 receives the Probe message, it extracts the Types tag and searches for a device that matches the search condition from the device information held by the device information holding unit 514. Then, an XML format ProbeMatch message as shown in FIG. 15 is transmitted to the client PC 109. In the ProbeMatch message of FIG. 15, a <ProbeMatches> tag exists in the body part, indicating that this message is a ProbeMatch message. Among the <ProbeMatches> tags, there are ProbeMatch units 1501 and 1502 indicated by the <ProbeMatch> tag. Each ProbeMatch unit corresponds to one search result, and in the example of FIG. 15, it is shown that two search results are returned. That is, it indicates that two image forming devices satisfying the search condition "device type is Printer" have been searched. The structure in the ProbeMatch section is the same as in the <Hello> tag in the Hello message of FIG. 7.
After that, the DP 103 rewrites the received Probe message as shown in FIG. Then, the rewritten Probe message is unicastly transmitted to the DP102 registered by the registration method described with reference to FIG. The address of the client PC 109 of the transmission source that sent the Probe message to the DP 103 is set in the ReplyTo tag of FIG.
When the DP102 receives the Probe message from the DP103, it extracts the Types tag, searches for a device that matches the search condition from the device information held by the device information holding unit 514 of the DP102, and generates a ProbeMatch message. Then, the ReplyTo tag included in the Probe message received from DP103 is extracted. The DP102 transmits the generated ProbeMatch message to the client PC 109 which is the destination of the extracted RepeatTo.
As a result, the client PC 109 can receive the search result of searching for the image forming apparatus existing in the subnet 3 from the DP103, and can receive the search result of searching for the image forming apparatus existing in the subnet 2 from the DP102. ..
After that, if necessary, the client PC 109 can send a Get message to the searched image forming apparatus to acquire more detailed device information.
FIG. 13 is an example of a screen displayed on the display device of the client PC 109. The screen shown in FIG. 13 is an example of a screen displayed when the client PC 109 searches for an image forming apparatus.
In FIG. 13, the area 1301 is an area for the user to input search conditions. In this embodiment, the type of device to be searched is specified. That is, keywords such as "MFP" and "Printer" can be specified. The input method may be directly input by the user using a keyboard or the like, or a pull-down menu may be displayed so that the user can select one of the predetermined candidates. If nothing is entered in region 1301, all image forming devices are searched. When the button 1302 is pressed, a search request is sent. That is, the above-mentioned Probe message is transmitted by multicast. The searched result is displayed in the area 1303. Specifically, when the ProbeMatch message as the search result is received, the device type, model name, and device name are displayed at the same time. In the example of FIG. 13, an example when two image forming devices are searched is shown.
Next, the processing contents of the DP when searching for the image forming apparatus will be described using a flowchart. FIG. 17 is a flowchart showing a search process of the image forming apparatus executed in the DP. The flowchart of FIG. 17 is executed in any of the DPs 101, 102, and 103. Each step in FIG. 17 is processed by the CPU 301 included in the DP executing a program stored in the ROM 302 or HD311.
In step S1701, the DP receives the Probe message transmitted over the network. In step S1702, the device search processing unit 513 extracts the Types tag included in the received Probe message. That is, the search conditions included in the search request are extracted. In step S1703, the device search processing unit 513 searches for the device information satisfying the extracted search condition from the device information held by the device information holding unit 514. Specifically, whether or not the device information including the information matching the information of the Types tag (information indicating the type of the device) extracted in step S1702 is included in the device information held by the device information holding unit 514. To judge. If the device information that matches the conditions is found as a result of the determination in step S1703, the process proceeds to step S1704. On the other hand, if no device information that matches the conditions is found, the process proceeds to step S1707. If the Types tag is not extracted, all the device information held by the device information holding unit 514 becomes the device information that matches the search condition.
In step S1704, the device search processing unit 513 determines whether or not the received Probe message includes the RepeatTo tag. As a result of the determination, if the RepeatTo tag is included, the process proceeds to step S1705. On the other hand, if the ReplyTo tag is not included, the process proceeds to step S1707. In step S1705, the device search processing unit 513 generates a ProbeMatch message, which is a response to the Probe message. The ProbeMatch message contains device information that satisfies the search condition. Here, the device search processing unit 513 sets the destination of the ProbeMatch message to the destination described in the RepeatTo tag, not to the device that is the source of the Probe message. In step S1706, the device search processing unit 513 transmits the generated ProbeMatch message by unicast. If the destination is not set in step S1705 (No in step S1704), the destination of the ProbeMatch message is the sender that transmitted the Probe message.
In step S1707, the device search processing unit 513 determines whether or not another DP is registered as the transfer destination of the search request in the own device. Registration of other DPs is performed by the method of FIG. 4 described above. If it is determined that another DP is registered, the process proceeds to step S1708. On the other hand, if it is determined that another DP is not registered, the process is terminated.
In step S1708, the search request transfer unit 515 generates a transfer probe message in order to transfer the probe message to another DP registered in the own device. Specifically, the ReplyTo tag is added to the Probe message. The address of the device (in this case, the client PC) that is the source of the Probe message is set in the RepeatTo tag. If the Probe message already contains the RepeatTo tag, a new Probe message for transfer will not be generated. In step S1709, the search request transfer unit 515 unicasts the generated probe message for transfer (or the probe message received in step S1701) to another registered DP. If a plurality of other DPs are registered, a Probe message is transmitted to these plurality of other DPs.
Next, the search request transfer unit 515 of the DP describes the conditions for transferring the search request to another DP.
In the example of FIG. 17, if another DP to which the search request is transferred is registered in the DP, the search request is unconditionally transferred to the other registered DP. Therefore, if another DP to be the transfer destination is registered in the other DP of the transfer destination, the search requests will continue to be transferred one after another. Therefore, one search request may continue to be forwarded one after another without limitation.
In order to prevent such a situation, in this embodiment, the condition for the search request transfer unit 515 of the DP to transfer the search request to another DP is set in the search request transfer unit 515. Hereinafter, some of the methods will be specifically described.
The first method in which the search request transfer unit 515 of the DP transfers the search request to another DP is only the DP existing in the upper layer (or lower layer) than the subnet in which the DP receiving the search request exists. This is a method of forwarding a search request to.
The system in this embodiment is composed of a plurality of subnets as shown in FIG. In the first method, it is assumed that a hierarchical structure is set for each of these plurality of subnets. Here, it is assumed that subnet 1 is set as a higher-level subnet of subnet 2 in FIG. 1, and subnet 1 is set as a higher-level subnet of subnet 3. Then, subnet 2 and subnet 3 have the same hierarchy. Then, the hierarchical relationship of each subnet is registered in advance in the DP existing in each subnet.
The first method will be described with reference to the example of FIG. 1 set in this way. First, the client PC 109 transmits the Probe message by multicast. FIG. 18 is an example of a Probe message transmitted by the client PC 109. The Probe message of FIG. 18 includes a Condition tag, and "UpperLayer" is specified in the Condition tag. The Connection tag indicates the transfer conditions when the search request transfer unit transfers the Probe message. In the example of FIG. 18, it is specified that the Probe message is transferred only to the DP existing in the upper layer.
The DP 103 receives the Probe message shown in FIG. Then, the search request transfer unit 515 of the DP 103 refers to the Connection tag and recognizes that the Probe message should be transferred to the DP existing in the subnet higher than the subnet in which it exists. Then, by referring to the information set in the search request transfer unit 515 in advance, it is recognized that the subnet in the upper layer of the user is subnet 1. Then, according to the method of FIG. 4, the DP existing in the subnet 1 which is the subnet of the upper layer is extracted from the DP registered in advance as the DP of the transfer destination. For example, when DP101 and DP102 are registered, DP101 existing in subnet 1 will be extracted. Then, the search request transfer unit 515 of the DP 103 transfers the Probe message to the DP 101 existing in the subnet 1. At this time, as described in S1708 of FIG. 17, the search request transfer unit 515 generates a probe message for transfer, that is, a probe message in which the address of the client PC 109 (192.168.0.100) is set in the RepeatTo tag. ,Send.
As described above, according to the first method, it is possible to prevent the Probe message transmitted from the client PC from being continuously transferred to the DP one after another without limitation.
The second method in which the search request transfer unit 515 of the DP transfers the search request to another DP is a method of transferring the search request according to a specified number of times.
A specific example of the second method will be described based on the system of FIG. The client PC 109 transmits the Probe message shown in FIG. 19 by multicast. The Probe message of FIG. 19 includes a TTL tag, and "1" is specified for the TTL tag. The TTL tag is a value indicating a limit value of the number of times of forwarding of the Probe message. If it is 1, it means that the transfer can be performed only once. If it is 10, it means that the transfer can be performed 10 times. That is, the Probe message in which "1" is specified in the TTL tag will be transmitted to a maximum of two DPs in a system in which one DP exists in one subnet.
The DP 103 receives the Probe message shown in FIG. Then, the search request transfer unit of the DP 103 refers to the TTL tag included in the Probe message and recognizes that the value is "1". Then, it is determined whether or not another DP of the transfer destination is registered. If registered, the search request transfer unit 515 generates a probe message for transfer. FIG. 20 is an example of a probe message for transfer generated by the search request transfer unit 515. Unlike the Probe message of FIG. 19, first, the ReplyTo tag is added. The address (192.168.0.100) of the client PC 109, which is the source of the Probe message, is set in the ReplyTo. Further, the value of the TTL tag is set to "0". That is, the search request transfer unit 515 sets the value obtained by subtracting 1 from the Ttl value of the received Probe message as the Ttl value. When a plurality of transfer destination DPs are registered in the DP 103 and a Probe message is transferred to a plurality of transfer destination DPs, the TTL value is subtracted by the number of DPs. If the TTL value of the received Probe message is 1 even though the DPs of a plurality of forwarding destinations are registered, the DP of the one forwarding destination having the highest priority is selected. Transfer the Probe message only to that DP. Here, the priority order can be determined according to the registration order of FIG. 4, as described with reference to FIG.
The search request transfer unit 515 of the DP 103 transmits the generated probe message for transfer to another DP. After that, when the DP that receives the transferred Probe message recognizes that the value of Ttl included in the Probe message is 0, it is controlled not to transfer the Probe message thereafter.
In this way, according to the second method, it is possible to prevent the Probe message transmitted from the client PC from being continuously transferred to the DP one after another without limitation. Not only that, you can specify in the Probe message how many DPs you should forward to.
In the second method, the Ttl value was counted as the number of DPs. However, the value of Ttl may be counted as the number of subnets. That is, the value of Ttl may be calculated by counting the number of routers passing through when transmitting the Probe message and subtracting the value from Ttl.
The third method in which the search request transfer unit 515 of the DP transfers the search request to another DP is to notify the DP that has already been transferred and transfer the search request only to the DP that has not yet been transferred. The method.
A specific example of the third method will be described with reference to the flowchart of FIG. FIG. 21 is a flowchart showing the operation of the DP that receives the Probe message from the client PC, and the same processes as those in FIG. 17 are designated by the same reference numerals, and detailed description thereof will be omitted.
The flowchart of FIG. 21 is a flowchart showing the processing of DP102 in the system shown in FIG. The case where the DP 103 transfers the probe message transmitted from the client PC 109 of FIG. 1 and the DP 102 receives the transferred probe message will be described as an example. An example of the Probe message received by the DP 102 is shown in FIG. As a premise, it is assumed that DP102 (192.168.1.10) is registered in DP103 as the transfer destination DP. Further, it is assumed that DP101 (192.168.2.10) and DP103 (192.168.0.10) are registered in DP102 as the transfer destination DP. Registration of the DP of the transfer destination is performed by using the method of FIG. 4 described above.
The Probe message of FIG. 22 contains a DpList tag. This DpList tag indicates the DP for which the Probe message has already been sent. In the example of FIG. 22, since the addresses have already been transmitted to the DP 103 and the DP 102, the addresses of the two DPs are described.
In step S1701, the DP 102 receives the Probe message shown in FIG. 22 from the DP 103. Since the processes from steps S1702 to S1707 are the same as those described with reference to FIG. 17, the description thereof will be omitted here.
In step S2101, the search request transfer unit 515 of the DP 102 determines whether or not the received Probe message includes the DpList tag. If it is included, the process proceeds to step S2102, and if it is not included, the process proceeds to step S2105. In step S2102, the search request transfer unit 515 determines whether or not there is a DP not described in DpList among the DPs registered as the transfer destination DPs. In this example, DP101 (192.168.2.10) and DP103 (192.168.0.10) are registered as transfer destination DPs in DP102. On the other hand, DP102 (192.168.1.10) and DP103 (192.168.0.10) are described in the DpList of the received Probe message. Comparing these, it means that DP101 is not described in DpList.
In step S2103, the search request transfer unit 515 extracts the DP not described in DpList from the DP registered as the transfer destination DP, and describes the address in DpList. In the case of the example of FIG. 21, DP102 adds the address (192.168.2.10) of DP101 not described in DpList to DpList. Then, in step S2104, the search request transfer unit 515 sets the address added to DpList in step S2103 as the destination address of the Probe message. In the case of the example of FIG. 21, the address of DP101 (192.168.2.10) is set as the destination address of the Probe message.
Step S1708 is the same as the process of step S1708 in FIG. That is, if the received Probe message does not include the ReplyTo tag, the ReplyTo tag is added and the address of the client PC that is the source of the Probe message is described in the ReplyTo tag. If there is already a ReplyTo tag as in the example of FIG. 22, the process of step S1708 is omitted. In step S1709, the search request transfer unit 515 transmits the generated Probe message.
Further, step S2105 is a process performed when the received Probe message does not include the DpList tag. In step S2105, the search request transfer unit 515 sets another DP registered in advance as the transfer destination DP as the destination address of the Probe message.
In step S2102, the search request transfer unit 515 also determines at the same time whether or not its own address is described in DpList. In the example of FIG. 21, its own address (192.168.1.10) is described in DpList. In that case, the own address is not described in DpList again. However, if its own address is not described in DpList, the search request transfer unit 515 describes its own address in DpList in step S2103.
In this way, according to the third method, it is possible to prevent the Probe message transmitted from the client PC from being continuously transferred to the DP one after another without limitation. Not only that, the same Probe message will not be sent twice for the same DP.
As another method, a method of deciding whether or not to transfer the Probe message is also conceivable based on the IP address of the client PC that is the source of the Probe message. For example, in the system shown in FIG. 1, an environment in which a VLAN (Virtual LAN) that sets a virtual group according to an IP address is used can be considered. In such an environment, for example, when a VLAN is provided for each department to divide the network and access is restricted, it is necessary to control so that a search from a client PC belonging to another VLAN is not performed.
Therefore, when the DP transfers the search request to the DP of another subnet, the search request is transferred to the DP belonging to the same VLAN based on the IP address of the client PC, and the DP does not belong to the same VLAN. Controls not to transfer. It is also possible to control that only the search request from the client PC belonging to a specific VLAN can be transferred to the DP of another subnet.
The unit of the group set by the VLAN can be appropriately determined. For example, a VLAN group can be set for each department in the office, for each building, for each floor, and the like.
Further, when a plurality of other DPs are registered in the DP as the transfer destination of the search request, it is also possible to control the order in which the search request is transferred. For example, it is assumed that there is a DP-X in which three DPs, DP-A, DP-B, and DP-C, are registered in this order as the transfer destination DP of the search request. The DP-X controls the transfer request according to the registration order of the transfer destination DP, such as first transfer to DP-A, then transfer to DP-B, and finally transfer to DP-C. In such control, when the DP-C has a further transfer destination DP and the number of transfer destination DPs is large, many transfer requests are generated in the DP-C, and the client PC acquires all the search results. It will take time. Therefore, it is possible to change the registration order of the transfer destination DP. As a result, the DP that holds a large number of transfer destination DPs can be changed to a higher rank in the registration order, so that the transfer order can be accelerated and the response to the search result can be accelerated as much as possible.
(Other Examples) In the above embodiment, the image forming apparatus and the information processing apparatus operating as the DP have been described as separate devices, but these may be provided as one device. That is, for example, in the example of FIG. 1, the image forming apparatus 108 may have the function of the DP 102. Similarly, the client PC may have the function of DP in the above embodiment. Alternatively, the image forming apparatus and the client PC in the above embodiment may be provided by one apparatus.
Further, the present invention may supply a storage medium in which a computer program code of software for realizing the flowchart of the above-described embodiment is recorded to a system or an apparatus. It can also be achieved by the computer (CPU or MPU) of the system or device reading and executing the program code stored in the storage medium.
In this case, the program code itself read from the storage medium realizes the function of the above-described embodiment, and the storage medium storing the program code constitutes the present invention.
As a storage medium for supplying the program code, for example, a floppy disk, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM, a CD-R, a DVD-ROM, a magnetic tape, a non-volatile memory card, a ROM, or the like is used. be able to.
<figref num="1">It is a figure which shows the structure of the network search system in this Example.</figref><figref num="2">It is a block diagram which shows the hardware structure of the image forming apparatus in this Example.</figref><figref num="3">It is a block diagram which shows the hardware configuration of DP and a client PC in this Example.</figref><figref num="4">This is an example of a screen displayed on the DP display device in this embodiment.</figref><figref num="5">It is a figure which shows the software module in this Example.</figref><figref num="6">This is an example of device information held by the device information holding unit in this embodiment.</figref><figref num="7">This is an example of a Hello message in this embodiment.</figref><figref num="8">This is an example of a Get message in this embodiment.</figref><figref num="9">This is an example of the GetResponse message in this embodiment.</figref><figref num="10">This is an example of a Bye message in this embodiment.</figref><figref num="11">This is an example of a Probe message in this embodiment.</figref><figref num="12">This is an example of a ProbeMatch message in this embodiment.</figref><figref num="13">It is a figure which shows the example of the UI when the client PC in this Example searches for an image forming apparatus.</figref><figref num="14">This is an example of a Probe message in this embodiment.</figref><figref num="15">This is an example of a ProbeMatch message in this embodiment.</figref><figref num="16">This is an example of a Probe message in this embodiment.</figref><figref num="17">It is a flowchart which shows the processing of DP in this Example.</figref><figref num="18">This is an example of a Probe message in this embodiment.</figref><figref num="19">This is an example of a Probe message in this embodiment.</figref><figref num="20">This is an example of a Probe message in this embodiment.</figref><figref num="21">It is a flowchart which shows the processing of DP in this Example.</figref><figref num="22">This is an example of a Probe message in this embodiment.</figref>
Code description
301 CPU 302 ROM 303 RAM 304 system bus 305 KBC 306 CRTC 307 DKC 308 NIC 309a PD 309b KB 310 CRT 311 HD 312 FD
22 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22
4 members in 2 offices
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 2008141056 | Japan | A | |
| JP20080141056 | – | – | – |
Members4
| Document | Office | Kind | |
|---|---|---|---|
| US2009300175A1 | United States of America | A1 | |
| JP2009289041A | Japan | A | |
| US8346916B2 | United States of America | B2 | |
| JP5558681B2This record | Japan | B2 |
13 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 | |
| Notification of change of attorneyJAPANESE INTERMEDIATE CODE: A7421RD01 | RD01 | |
| Notification of resignation of power of attorneyJAPANESE INTERMEDIATE CODE: A7424RD04 | RD04 |
Numbers
- Publication, DOCDB
- 5558681
- Publication, EPODOC
- JP5558681B
- Application
- 141056
- Application, DOCDB
- 2008141056
- Application, EPODOC
- JP20080141056
Titles
- English
- The control method of a device retrieval device and a device retrieval device, and a computer program
Classification
- CPC, 6
- G06F3/1288
- G06F3/1204
- G06F3/1226
- G06F3/1231
- G06F3/1236
- H04L41/12
- IPC, 4
- G06F13 00
- G06F3 12
- H04L12 28
- H04L12 70
