Communication system and communication apparatus and control method thereof

ES 2 335 238 T3

DESCRIPTION

Communication system and communication apparatus and its control procedure.

Background of the invention

Invention sector

The present invention relates to network communication apparatuses, a communication system including the apparatuses and a control method for the communication system and apparatuses.

Description of Related Art

Conventionally, a service provider apparatus or a system is known which provides various types of services in response to requests for services from client apparatuses in a network. For example, with the rapid expansion of communication over the Internet, various types of devices have been developed, apart from conventional personal computers, as network devices. In addition to user interactive devices such as PDAs (Personal Digital Assistants) and mobile phones, various types of image processing apparatus and electrical household accessories have become network compatible.

According to this trend, software has been proposed to search for network devices that provide various types of services in order to improve the comfort and ease of use in the use of these network devices. Furthermore, various types of protocols and architectures have been proposed that provide automatic means of installation for application software, utility software, operating systems, and the like to control such network devices (Japanese Patent Laid-Open Nos. 2004-038956 and 2004-362594).

Several companies and standardization organizations have made efforts to develop specifications to extend the "plug and play" function, which applies to devices with local input / output connections, as well as network devices. These efforts include, for example, UPnp (trademark) (see UPnP Device Architecture v1.0 at http://www.upnp.org/specs/arch/UPnP-DevieArchitecture-v1.0-20060720.pdf) that Microsoft is primarily developing, and BM-Links (“BMLinks”, the Japan Association of Office Machinery and Information Systems Industries, Internet address (http://www.jbmia.or.jp/bmlinks/eng/ index.htm) that has been promoted by WSD: Web Services for Devices (WS-Discovery / WS-MetadataExchange / WS-Eventing, Web Service Dynamic Discovery: WSDiscovery address: http://specs.xmlsoap.org/ws/2005/04/discovery/wsdiscovery.pdf WS address -MetadataExchange: http://specs.xmlsoap.org/ws/2004/09/mex/WS-MetadataExchange.pdf WS -Eventing http://msdn.microsoft.com/ webservices / webservices / understanding / specs / default.aspx ? pull = / library / en-us / dnglobspec / html / ws-eventing.asp).

The network service systems exemplified above use protocols for the notification of events typified by GENA: General Notification of Events, WS-Eventing and the like. This allows a client device to detect, in real time, a change in the state of a device that provides a service, that is, the processed state of a job that the device has requested to execute, an error state, a state change , such as, updating the configuration information ("occurrence of an event"), or the like.

The above-mentioned conventional techniques, however, have the following problems. According to an event notification protocol, a client device needs to issue an event notification request to a service provider device in advance. The service provider device must maintain and manage all pieces of information regarding notification requests received from all client devices. When an event occurs, the service provider device must notify all client devices from which notification requests have been received of the occurrence of the event. Of these events, events associated with changes in status accompanying the execution of a job may possibly include a job start, job advance, job completion, error, and the like. In order to transmit notifications of the occurrence of these events to clients from which notification requests have been received, it is necessary to ensure a network connection that includes error recovery and the like. This places a heavy burden on service provider devices. Furthermore, this heavy load has caused, for example, the problem of failure to report an important and urgent event which will greatly delay the notification of the event to the network management tools.

On the other hand, it is possible that even if the service provider device notifies a client device, from which an event notification request has been received, the client device does not have the event processing function, that is, it does not have the function of analyzing the content of the event and notifying the user of the resulting information. Furthermore, on the client device, a function, application, utility or the like that processes an event may not be activated (for example, it may be invalidated). In that case, the information of the reported event and the process performed for the notification are wasted.

In a service provider device with limited hardware resources, a device used in a home network environment in particular, or in an environment such as an office where there are multiple client devices, some strategy is required to minimize excessive processing of data. events and excessive event notification.

ES 2 335 238 T3

US 6734985 discloses a system comprising a printer and a host computer in which the host computer sends periodic registration requests to the printer and the printer registers the host in response to the registration requests. If the printer does not receive a registration request during a hold time, the printer unregisters the host computer.

Brief description of the invention

It is an object of the present invention to address the above-described problems of conventional technology.

An advantage of the present invention is that unnecessary event notifications are substantially eliminated by notifying client appliances, of client appliances whose event notification requests have been logged, that they are ready to perform event processing.

According to the present invention, it is possible to eliminate unnecessary notification of the occurrence of events by notifying client apparatuses, of client apparatuses whose event notification requests have been logged, that they are ready to perform event processing. This can reduce the load on an event communication process. Also, this can improve the real-time performance of event notification that event notification is supposed to have.

According to a first aspect of the present invention, a communication system is disclosed as specified in claims 1-6.

According to a second aspect of the present invention, a communication apparatus is disclosed as specified in claims 7 to 9.

According to a third aspect of the present invention, a control method is disclosed as specified in claims 10 to 17.

Additional features of the present invention will be apparent from the following description of exemplary embodiments with reference to the accompanying drawings.

Brief description of the drawings

The accompanying drawings, which are incorporated in and constitute a part of the description, illustrate an embodiment of the invention and an illustrative example and, together with the description, serve to explain the principles of the present invention.

FIG. 1 is a block diagram showing the arrangement of a plug and play network system in accordance with an exemplary embodiment of the present invention;

Figures 2A and 2B are flow charts for explaining control processing in a client device according to the first embodiment of the present invention;

Fig. 3 is a flow chart for explaining control processing in a network device according to the first embodiment;

Figure 4 shows the XML data describing the format of a management table according to the embodiment;

Figure 5 shows the format of a status notification message according to this embodiment;

Fig. 6 is a flow chart showing a control processing procedure in a case where an event has occurred in the network device according to the first embodiment;

Figures 7A and 7B are flow charts for explaining control processing in a client device according to the illustrative example; and Fig. 8 is a flow chart for explaining the control processing in the network device according to the illustrative example.

Description of the achievements

An embodiment of the present invention and an illustrative example will now be described in detail with reference to the accompanying drawings. The following embodiment is not intended to limit the claims of the present invention, and not all combinations of elements described in the embodiment are essential to the present invention. Furthermore, it should be noted that it is not intended to limit the scope of the present invention to protocols, versions, addresses, other numerical values ​​and the like described in the embodiment, unless otherwise specified.

FIG. 1 is a block diagram showing the arrangement of a plug and play network system in accordance with an exemplary embodiment of the present invention.

ES 2 335 238 T3

Referring to Figure 1, reference numeral 100 indicates a client device, which has a communication function corresponding to Ethernet. The client device (100) comprises a TCP / UDP / IP protocol stack (1) and an HTTP processor (2) in the protocol stack (1). The client device (100) parses an HTTP request and performs response processing. The client device (100) comprises a SOAP (Simple Object Access Protocol) processor (3) in the upper layer of the TCP / UDP / IP protocol stack (1) and of the HTTP processor (2). Furthermore, a plug and play controller (4), an event manager (5), utilities (6) and applications (7) implement a bidirectional communication of data described in XML.

The plug and play controller (4) executes a response processing corresponding to a "Hello" message notified from a network device through the SOAP processor (3) based on the WS-Discovery specifications that have been developed by Microsoft and other companies. In addition, the plug and play controller (4) issues a “Probe” polling message to search for a network device. The plug and play controller (4) also executes the acquisition processing of the attribute information of a network device by issuing a "GetMetadata" message based on the WS-MetadataExchange specifications.

If a network device (200) comprises an event notification function, the attribute information of the network device (200) records the destination information of the log of an event notification request. The event manager (5) issues an event notification request (“Subscribe” message) to the destination of the record of this event notification request through the SOAP processor (3) based on the WSEventing specifications that have been developed by Microsoft and other companies. Alternatively, the event manager (5) issues a cancellation request ("UnSubscribe" message) for event notification. The event manager (5) verifies the presence / absence of event notification requests from the utilities (6) and applications (7). If one of the utilities (6) or applications (7) that are in active state requires an event notification request, the event manager (5) issues a status message to the network device (200) through the processor (3) SOAP. Furthermore, the event manager (5) has a function to issue a status message to the network device (200) through the SOAP processor (3) when all the utilities (6) and applications (7) that require a notification of events are not in active state.

The event manager (5) receives the information of the notified events from the network device (200) through the SOAP processor (3). Next, the event manager (5) notifies the utilities (6) and the applications (7), which have previously issued requests to notify the event. In this case the utilities (6) and the applications (7) include software that has functions of processing events reported from the network device (200), for example, a printer driver dialog, a view of the queue of printing and an application for network management.

The network device 200 will be described below.

In this embodiment, the network device 200 has a communication function corresponding to Ethernet. The network device (200) comprises a TCP / UDP / IP protocol stack (8) and an HTTP processor (9) in the protocol stack (8). The network device 200 analyzes the HTTP requests and performs response processing. The network device 200 includes a SOAP processor 10 in the upper layer of the TCP / UdP / IP protocol stack 8 and the HTTP processor 9. A WSD module (11), an event manager (12) and a printer driver (13) implement a bidirectional communication of data described in XML through the SOAP processor (10).

When connected to a network (300), a WSD module (11) transmits a "Hello" message through the SOAP processor (10) based on WS-Discovery specifications that have been developed by Microsoft and other companies. Furthermore, the WSD module (11) executes response processing with respect to a "Probe" message issued by the client device (100). The WSD module (11) also returns attribute information, which the network device (200) (a network printer in this embodiment) has, according to the "GetMetadata" message issued from the client device (100) based on the WS-MetadataExchage specifications.

The event manager (12) has a function of managing a request for notification of events (Active) and a request for cancellation of notification of events (InActive) notified from the client device (100) for each of a series of client devices including the client device (100). The event manager (12) manages information on the status of the printer reported from the printer controller (13), and generates data corresponding to the event. The event handler (12) also has a function of transmitting an event message to the client device (100) through the SOAP processor (10).

A control procedure of the plug and play network system according to this embodiment will now be described with reference to the flow diagrams of Figures 2A, 2B and 3.

First Realization

Figures 2A and 2B are flow charts for explaining control processing in a client device (100) according to the first embodiment. Fig. 3 is a flow chart for explaining control processing in a network device (200) according to the first embodiment.

ES 2 335 238 T3

First, in step S101, a plug and play controller (4) of the client device (100) searches for a service provider device that can be used in a network (300), that is, the network device (200). . In this case, the plug and play controller (4) issues a network device search packet (Probe packet) defined by the WS-Discovery specifications through the SOAP processor (3) in step S101. In step S102, the plug and play controller (4) determines whether or not a response has been received. In the affirmative case in step S102, the process advances to step S103 to obtain the profile of the device that has transmitted the response.

On the other hand, the network device (200) transmits a "Hello" message in step (S200) in figure 3, and then in step (S201), the network device waits for the reception of the transmitted "Probe" packet. from the client device (100) in step (S101) described above. When the network device (200) receives this packet in step (S201), the process proceeds to step (S202), in which the WSD module (11) of the network device (200) transmits address information to acquiring profile information to the client device (100) in response to the packet. In this case the network device (200) describes the information in a "ProbeMatch" response and returns it to the client device (100) as a response packet defined by the WSDiscovery specifications through the SOAP processor (10).

Through this operation, the plug and play controller (4) of the client device (100), which has received said "ProbeMatch" response in step S102, obtains the profile information of the network device (200) that has issued the response. in step S202. In this case, the client device (100) issues a "GetMetadata" request defined by the WS-MetadataExchange specifications for the address described in the "ProbeMatch" response previously received through the SOAP processor (3). It should be noted that there may be a number of network devices on the network (300). For this reason, the client device (100) selects the devices to be used from the devices that have returned the "ProbeMatch" responses. The client device (100) subsequently obtains the profile information of all the selected network devices.

Through this operation, if the network device (200) receives the request "GetMetadata" in step S203 of Figure 3, the process advances to step S204, in which the WSD module (11) causes that the SOAP processor (10) transmits the profile information to the client device (100).

By this operation, the client device (100) obtains the profile information from the network device (200). The plug and play controller (4) subsequently notifies the event manager (5) of the registration address of the event notification request described in the profile information. By means of this operation, the event manager (5) issues an event notification registration request ("Subscribe" request) defined by the WSEventing specifications with respect to the address through the SOAP processor (3) (step -S104- ).

By this operation, in step S205, the network device 200 receives this "Subscribe" request. The process subsequently advances from step S205 to step S206, in which the event manager (12) generates a "SubscribeID" to uniquely identify the client device (100). The network device (200) stores the "SubscribeID" and the address information of the event notification destination of the client device (100) which is described in the "Subscribe" request as a management table.

Figure 4 represents a view showing XML data describing the format of this management table.

In this case, the value of "SubscribeID" that the event manager (12) assigns to the client device (100) is described in the tag (400) <SubscribeID> as an attribute value. In the tag (401) <EventPort>, the notification address information of an event of the client device (100) is described in the form of URLs. In addition, <Status> (402) is used to store the operation status of the event processing software in the client device (100) (which will be described later) and is described as "Active" or "InActive ”(Out of service) in relation to the state of operation. Part of the information corresponding to the respective registered client devices is stored as a table in that format.

The process advances to step S207, where the event manager 12 describes the "SubscribeID" generated in the response packet "Subscribe" defined by the WS-Event specifications. The event manager (12) subsequently transmits the "Subscribe" response to the client device (100) through the SOAP processor (10).

By means of this operation, in step (S105), the client device (100) receives this response "Subscribe", and the process advances to step (S106), where the event manager (5) stores the "SubscribeID" described in this package. Subsequently, the process advances to step S107.

In step S107, the event manager (5) of the client device (100) determines whether the utilities (6) and applications (7), which operate in the upper layer, are active. In this case, the event manager (5) determines whether at least one element of the software, the utilities (6) or the applications (7), which process the event notified from the network device (200), for For example, a driver dialog, a print queue view, and network device management software is active. In this case, if at least one element of the software is active, they operate to register an event notification request in the event manager (5).

If the event manager (5) determines in step (S107) that one of the utilities (6) or applications (7) is active and receives the record of the event notification request from these software elements, the process

ES 2 335 238 T3 proceeds to step S108, where the event manager (5) determines if a "SubscribeID" has been obtained. If the "UnSubscribeID" has already been obtained from the network device 200, the process proceeds from step S107 to step S109 (FIG. 2B). In step S109, the event manager (5) determines if the total number of utilities (6) and applications (7) that have issued the event notification requests and that are active is equal to or greater than "1" . If the answer is YES in step 109, the process proceeded to step S110. In step S110, the event manager (5) determines whether a status notification message has been previously issued. If the answer is NO in step (S110), the process advances to step (S111), where the event manager (5) issues a status notification message (Active) to the network device (200) through the processor (3) SOAP. The process subsequently advances to step S113.

If the event manager (5) determines in step (S109) that the total number of utilities (6) and applications (7) that have issued the event notification requests and that are active is "0", or it determines in In step S110 that a status notification message has been issued previously, the process proceeds to step S113 without issuing any status notification message. If the event manager (5) determines in step (S108) (figure 2A) that the "SubscribeID" has not been obtained, the process advances to step (S112), in which the event manager (5) notifies an error to utilities (6) or applications (7). Subsequently, the process advances to step S113.

Fig. 5 shows a view for explaining the format of a status notification message. The SOAP processor (3) converts this message into a SOAP "envelope" and subsequently transmits it to the network device (200).

In this case, in <"SubscribeID"> (500), the identifier (SubscriptionID) obtained from the network device (200) in step (S106) (FIG. 2A) is described. In <Status> (501), the operation status of the utility (6) or application (7) that issued the event notification request is described. When the utility (6) or the application (7) are in service, their operating status is defined as "Active".

If the network device (200) receives this status notification message in step (S208) in Figure 3, the process advances to step (S209), in which the event manager (12) refers to the " SubscribeID ”described in the status notification message using the aforementioned management table. Subsequently, the event manager (12) searches, in the management table, the information of the corresponding client device and updates the <Status> field in the management table according to the content of the <Status> (501) received (figure 5) . Subsequently, the process advances to step S210.

On the other hand, if the event manager (5) determines in step (S107) in figure 2A that none of the elements of the software, utilities and applications that process an event from a network device, for For example, a controller dialog, print queue view, and network device management software are active, the process proceeds to step S113 (Figure 2B). The software element notifies the event manager (5) of the deregistration of the event notification request. If the event manager (5) receives the cancellation of the registration of the event notification request from any of the utilities (6) and from the applications (7) in step (S113), the process advances to step (S114 ). In step S114, the event manager (5) determines whether the total number of utilities (6) and applications (7) that have issued the event notification requests and that are active is "0". If the result is YES in step S114, the process advances to step S115 to issue a status notification message to the network device (200) through the SOAP processor (3) and subsequently, the process advances to step S116. In this case, the event manager (5) introduces "Inactive" in the <Status> tag (501) shown in figure 5 previously described.

If the event manager (5) determines in step (S114) that the total number of utilities (6) and applications (7) that require event notifications and that are active is equal to or greater than "1", or if the Event manager (5) does not receive the cancellation of the registration of the event notification request from any of the utilities (6) and from the applications (7) in step (S113), the process advances to step (S116) without issuing any status notification messages. In step S116, the event manager (5) determines whether it is necessary to unregister an event notification request. If the result is YES in step S116, the process advances to step S117. If the result is NO in step S116, the process advances to step S118 (FIG. 2A).

By this operation, upon receiving the status notification message issued in step S115, the network device 200 receives the status notification message in step S208 in the manner described above. In step S209, the network device 200 changes the <Status> field in the management table according to the content of the received message.

In this way, the event manager (5) of the client device (100) repeats the processing of the steps (S107) to (S116) previously described and monitors the operating states of the utilities (6) and of the applications (7 ) that run event processing.

It should be noted that in case the operating state of the client device (100) changes to a standby state or shuts down, the process advances from step (S116) to step (S117) in Figure 2B . In step S117, the event manager 5 issues a registration cancellation request ("UnSubscribe" request) for an event notification request, which is defined by the WS-Eventing specifications, to the device (200 ) network through the SOAP processor (3).

ES 2 335 238 T3

By this operation, the network device 200 receives this "UnSubscribe" request in step S210 (Figure 3). Subsequently, the event manager (12) of the network device (200) refers to the "SubscribeID" described in the request "UnSubscribe" in the table described above in step S211. Subsequently, the event manager (12) searches the management table for the corresponding client device, and deletes the information of the corresponding client device from the management table.

If the client device 100 cannot receive the response "ProbeMatch" in step S102 in FIG. 2A, the process advances to step S118. The plug and play controller (4) monitors in step (S118) whether the client device (100) has received the message "Hello" transmitted from the network device (200) participating in the network (300). If the result is YES in step S118, the process advances to step S103 to execute the next processing. If the client device 100 has not received the "Hello" message in step S118, the process advances to step S107.

It should be noted that the "Hello" message is a packet issued when the network device (200) wakes up to be ready to provide a service on the network (300). In this case, this packet is defined by the WS-Discovery specifications and issued in step S200 in figure 3.

Fig. 6 is a flow chart showing a control processing procedure in the event that an event occurs in the network device 200 according to the first embodiment.

This flowchart shows the processing of the network device (200, that is, a network printer. The processing is triggered at the time of the occurrence of an event associated with a change in the transition state regarding a job, a event associated with an error, an event associated with a change of an option of a device, an event associated with a change in the configuration or the like.Firstly, in step S301, it is determined whether or not some type of occurrence occurs. event. If some type of event occurs, then the printer controller (10) notifies the event manager (12) of the occurrence of the event. Subsequently, the process advances to step S302, where the event manager (12) that has received this notification searches the management table. In step S303, the event manager (12) determines if the information "Subscribe" is described and if <Status> is in the "Active" state. If the result is YES in step S303, the process advances to step S304 to report the occurrence of the event in relation to the address described in the management table.

In this case, the event handler (12) describes the event reported by the printer driver (13 in XML according to the notification format defined by the WS-Eventing specifications. The event handler (12) transmits, in addition, the resulting information to the client device (100) through the SOAP processor (10).

If the printer controller (13) determines in step (S303) that the "Subscribe" information is not described in the management table, or if <Status> is "InActive" even though the "Subscribe" information is described in the management table, the process skips step S304 and advances to step S305. Through this operation, the client device (100), which has all the utilities (6) and the application (7) that executes the event processing, will not be notified of the event.

In step S305, the event manager (12) determines whether the processing of the notification of an event in relation to all the parts of the "DescriptionID" information stored in the management table is complete or not. If the result is NO in step S305, the process returns to step S302 to search the management table and execute the above-described processing, otherwise the process is terminated.

On the other hand, after receiving the notification of the event from the network device (200), the event manager (5) of the client device (100) notifies the utility (6) or the application (7) whose notification request of events has been recorded, from the information received from the event.

As described above, according to the first embodiment, a series of control processing described in the flowcharts of Figures 2A and 2B, 3 and 6 is executed. This makes it possible to control the network device (200) to notify an event only when any utility (6) or application (7), which executes the event processing, is active in the client device (100), which is a characteristic of this first embodiment.

This makes it possible to notify the occurrence of an event to a single client device, of the client devices whose event notification requests have been registered, which is to perform event processing. Therefore, unnecessary notifications of the occurrence of events can be avoided.

Additionally, this can reduce the burden on an event communication process and deliver real-time notification of the occurrence of an event.

Illustrative example

In the first embodiment described above, the event manager (5) of the client device (100) issues a status notification request to the network device (200) according to the operating states of the utilities (6) and applications ( 7) that work on the top layer.

ES 2 335 238 T3

If the device (100) is a client device in which the number of utilities (6) and applications (7) that are inactive is small, it is possible to carry out a control using only the “Subscribe” information sent to the device (200) to determine if an event notification request is issued.

The illustrative example will be described below with reference to Figures 7A, 7B and 8. It should be noted that the configurations of an arrangement of the apparatus and the system according to the illustrative example are the same as those mentioned in the first embodiment, and will be omitted a repeating description.

Figures 7A and 7B are flow charts for explaining control processing in a client device (100) in accordance with the illustrative example. FIG. 8 is a flow chart for explaining control processing in a network device 200 in accordance with the illustrative example. The same step numerals in Figures 7A, 7B, and 8 indicate common processes as in Figures 2A, 2B, and 3, and repetitive description will be omitted.

After the acquisition of information from the device in step (S401), the event manager (5) of the client device (100) monitors the operating states of the utilities (6) and of the applications (7) that operate in the layer higher.

If at least one element of the software, the utilities (6) or the applications (7), which process an event from a network device, for example, a dialog from a driver, a view of the print queue, and software for managing network devices, is active, the software element registers a request for notification of events with respect to the event manager (5).

When the event manager (5) receives a registration request for an event notification request from a utility (6) or application (7) in this way in step (S107), the process advances to step (S109) . In step S109, the event manager (5) determines if the total number of utilities (6) and applications (7) that have issued event notification requests and that are active is equal to or greater than " 1". If the result is YES in step S109, the process advances to step S402 to determine whether a registration request for an event notification request ("Subscribe" request) has been issued. If the result is NO in step S402, the process advances to step S403 to issue a registration request for an event notification request ("Subscribe" request) defined by the WS-Eventing specifications to the device. (200) network through processor (3) SOAP. It should be noted that if the event handler 5 determines in step S402 that a "Subscribe" request has been issued, the process advances to step S113 (FIG. 7B).

When the event manager (12) of the network device (200) receives this "Subscribe" request in step (S205) in figure 8, the process advances to step (S501) (figure 8) to generate a "SubscribeID ”For unique identification of the client device. Subsequently, the event manager (12) registers the "SubscribeID" and the address information of the notification destination of the event of the client device (100) described in the "Subscribe" request in the management table. Next, in step S502, the event handler (12) describes the generated "SubscribeID" in a response packet "Subscribe" defined by the WS-Event specifications. Subsequently, the event manager (12) transmits the response "Subscribe" to the client device (100) through the SOAP processor (10).

By this operation, the client device 100 determines in step S404 whether this "Subscribe" response has been received. If the result is NO in step S404, the process advances to step S405 to deliver an error notification. Subsequently, the process advances to step S113 (Figure 7B). If the result is YES in step S404, the process advances to step S406, where the event manager (5) stores the "SubscribeID" described in the packet. Subsequently, the process advances to step S113 (Figure 7B).

In step (S113) of figure 7B, the event manager (5) verifies the states of the software elements, of the utilities (6) and of the applications (7), which process an event from the device (200 ) network, for example, a driver dialog, a print queue view, and network device management software. If all the software elements processing the event are finished, then the software notifies the event manager (5) of the deregistration of the event notification request.

If the event manager (5) receives the cancellation of the registration of the event notification request from one of the utilities (6) and from the applications (7), the process advances from step (S113) to step (S114 ) (Figure 7B). In step S114, the event manager (5) determines whether the total number of utilities (6) and applications (7) that have issued the event notification requests and that are active is "0". If the answer is YES in step S114, the process advances to step S407 (Figure 7B) to issue a registration cancellation request ("UnSubscribe" request) for an event notification request that is defined by the WS-Eventing specifications to the network device (200) through the SOAP processor (3).

By this operation, the event manager (12) of the network device (200) receives this "UnSubscribe" request in step S210 of FIG. 8, and the process advances to step S503. In step S503, the event handler 12 refers to the "SubscribeID" described in the request "UnSubscribe" in the management table described above. Subsequently, the event manager (12) searches the management table for the information of the corresponding client device, and deletes the information corresponding to the client device from the management table.

ES 2 335 238 T3

In this way, in the event that an event occurs in the network device (200), the event manager (12) searches the management table. If the information "Subscribe" is described in the table, the event manager (12) notifies the occurrence of the event with respect to the address described in the management table.

The above processing allows issuing an event notification request to the network device (200) only when at least one of the utilities (6) or applications (7) that can execute the event processing is active on the device ( 100) customer.

This makes it possible to deliver a notification of the occurrence of an event only to a client device, of the client devices whose event notification requests have been registered, which is ready to perform event processing. Therefore, unnecessary notifications of the occurrence of events can be avoided.

Additionally, this can reduce the burden on an event communication process and deliver real-time notification of the occurrence of an event.

In the first embodiment and in the illustrative example described above, in steps (S111) and (S115) in Figure 2B, the event manager (5) issues a status notification message to the network device (200) regarding to the operating states of the utilities (6) and applications (7) that can process the event.

It is assumed that the client device (100) can simultaneously run a number of utilities (6) and applications (7), and each software program has a function to display a user interface in the form of a window. In this case, it is possible to request the event manager (5) to register an event notification request and, even if the corresponding software is active, have the event manager (5) monitor whether a window for the corresponding software is found open (for example, active). If the total number of software items, utilities (6) and applications (7) that have issued event notification requests and whose windows are open is equal to or greater than "1", the event manager (5) issues a status notification message to the network device (200). This makes it possible to deliver a notification of the occurrence of a requested event only when at least one of the utilities (6) and of the applications (7) that execute the event processing is active on the client device (100) and a window like user interface is open.

According to the first embodiment and the illustrative example, when all the utilities (6) and applications (7) that execute an event processing are idle in the client device (100), the network device (200) does not notify any event to the device (100) client. However, it is possible to notify the client device (100) of the occurrence of predetermined events such as a major error state and a state change associated with a change in the disposition of a device regardless of whether the utilities (6) or applications (7) are active.

Furthermore, the first embodiment and the illustrative example described above use the protocols defined by the WS-Discovery and WS-Eventing specifications as means for searching for a network device, notifying the participation of a network device in a network. and the registration and notification of an event. However, the present invention is not limited to this. For example, it is sufficient to use SSDP (Simple Service Discovery Protocol) and GENA (General Event Notification Architecture) defined by UPnP (tm) v1.

As a search protocol for a network device, the present invention can use any protocol that can obtain an address for the acquisition of the information of the attributes of a network device and control the destination of transmission of the information to control the device. net.

As event recording / notification means, the present invention can use any protocol that can issue an event notification request and notify an event transmission destination through a network, and furthermore can transmit an occurred event to a source of request that has issued an event notification request.

The first embodiment and the illustrative example have exemplified the printer as a network device. However, a network device can be office equipment such as a copy machine, scanner, storage device, or household appliance such as a television, refrigerator, or air conditioner as long as it is a device that can be used and controlled through a communication channel.

The respective processing functions in the client device (100) and in the network device (200) according to the above-described embodiments are implemented by reading programs for the implementation of the respective processing functions and causing the CPU (Central Unit Processing) executes them. However, the present invention is not limited to this, and some or all of the processing functions may be implemented by dedicated hardware. Furthermore, the above memory can be a non-volatile memory such as a magneto-optical disk, a readable storage medium such as a CD-ROM, a volatile memory other than RAM, or storage media that allow read / write by computer comprising a combination of these.

It is possible to store, on a computer-readable storage medium, programs to implement the respective functions in the client device (100) and the network device (200), and to perform the respective processes.

ES 2 335 238 T3 making the computer system read and run the programs. It should be noted that the "computer system" in this case includes an OS (Operating System) and hardware, such as peripheral devices. More specifically, the programs read from the storage medium are written in the memory of a function expansion card inserted in the computer or a function expansion unit connected to the computer. Subsequently, the CPU of the function expansion card or function expansion unit performs some or all of the current processing based on the instructions of the programs, thus implementing the functions of the previous embodiments.

Furthermore, the "computer-readable storage medium" is a portable medium such as a floppy disk, a magneto-optical disk, a ROM, or a CD-ROM or a storage device such as a hard disk integrated into the computer system. Furthermore, "computer-readable storage medium" is a medium that maintains programs for a predetermined period of time, for example, a server to which programs are transmitted over a network such as the Internet, or such a communication line. such as a telephone, or a volatile memory (RAM) in a computer system that works as a client.

It is possible to transmit the above programs from the computer system that stores the programs in a storage device or the like to another computer system through a transmission medium or carrier waves in the transmission medium. In this case, the "transmission medium" is a medium that has a function to transmit information, for example, a network such as the Internet or a communication line such as a telephone line.

Each of the above programs can be one that implements a part corresponding to one of the functions described above or it can be one that implements the function in combination with a program that has already been recorded on the computer, that is, a differential file ( differential program).

Furthermore, a program product such as a computer-readable storage medium, which stores the above programs can be applied as an embodiment of the present invention. The scope of the present invention incorporates the above programs, storage media, transmission media, and a program product.

Although the embodiments of the present invention have been described in detail above, the specific arrangements of the present invention are not limited to the embodiments.

While the present invention has been described with reference to exemplary embodiments, it should be understood that the invention is not limited to the exemplary embodiments described. The scope of the following claims should be construed more broadly to encompass all modifications and equivalent structures and functions.