Network enabled printing device, method, and recording medium

The present invention relates generally to web services, and in particular to supporting multiple service discovery protocols on a device.

The approaches described in this section are traceable approaches, but they are not necessarily approaches that have been considered or tracked in the past. Therefore, unless otherwise noted, none of the approaches described in this section should be assumed to be considered prior art solely because they are included in this section.

The term "web service" refers to a standard that integrates web-based applications that use the XML, SOAP, and WSDL standards over network protocols such as IP. XML is used to tag the data, SOAP specifies how to encode web service requests and responses into XML messages, and WSDL is used to describe the services available. Web services are used by programmed and networked entities to communicate with each other regardless of the platform on which they are implemented. Since many such entities are business-related, web services allow multiple businesses to communicate data without being familiar with each other's IT systems behind the firewall.

Web services share business logic, data and processes over the network through program interfaces. Web services allow different applications from different sources to communicate with each other without time-consuming custom coding. Moreover, since all communication is done in XML, web services are not tied to any operating system or programming language. For example, Java (Java®) can communicate with Python (Python), and Windows (Windows®) applications can communicate with Unix (UNIX®) applications.

The Web Services Standard-Multiple-consists of interoperable protocols for security, reliable messaging, and processing in loosely coupled systems. The web service standard may be a standard as well as an approved standard (eg, approved by the World Wide Web Consortium (W3C) or approved by the Structured Information Standards Promotion Association (OASIS)). Includes no proposed documents, drafts, etc.

<p> A client application that wants to take advantage of the web services provided by one device may implement one standard protocol, but may not implement another. Therefore, in order for a device to provide web services to as many client applications as possible, the device may have to implement as many web service standards and other standard protocols as possible. However, it is imperative to update existing protocols, and new protocols are becoming standardized on a regular basis. Usually such changes affect a large number of modules in a device, which means that the logic of many modules operating in the device needs to be modified. Also, modifying a particular module of a device that is not related to the web service (provided by the device) may require modification of the device module that runs the web service.</p>

<p> Techniques are provided to support multiple service discovery protocols on multifunction devices (MFPs). In one form, the MFP includes multiple Service Discovery Protocol (SDP) services, multiple SDP adapters and a device service management system (DSMS). Each SDP service interfaces with one of the multiple SDP adapters. Each SDP adapter interfaces with the DSNS. Each SDP adapter translates messages from the corresponding SDP service into a format understandable by the DSNS. Each SDP adapter also translates the message from the DSNS into a format that the corresponding SDP service can understand. DSMS manages service metadata information for multiple services provided by the MFP.</p><p> Upon receiving a request from a client for metadata for one or more services provided by the MFP, the SDP service requests metadata from the corresponding SDP adapter. The SDP adapter requests metadata from the DSNS, and the DSNS responds to the SDP adapter with the requested metadata. The SDP adapter sends the requested metadata to the SDP service, which sends the metadata to the client.</p><p> In a related method, the DSNS detects changes in the status of one or more services provided by the MFP. The DSMS sends notifications to all SDP adapters (for example, those registered with the DSNS). Each SDP adapter translates its notifications into a format (a format understood by the corresponding SDP service). Each SDP service then sends an advertisement message to one or more clients in the network (eg, by multicast or broadcast).</p>

Hereinafter, non-limiting examples of the present invention will be described with reference to the accompanying drawings. In the figure, similar numbers refer to similar elements.

In the following description, for convenience of explanation, many specific details will be described to enhance the understanding of the present invention. However, it will be clear that the present invention may be realized regardless of such specific details. Also, in order to avoid unnecessarily obscuring the present invention, well-known structures and devices are shown in block diagram format.

&lt;Service Discovery Protocol Architecture Example&gt; FIG. 1 is a block diagram showing an example of a service discovery protocol (SDP) architecture according to an embodiment of the present invention that interacts between a client 102 and a multifunction device (MFP) 104.

Client 102 sends a discovery request to MFP 104. This discovery request follows a standard discovery protocol such as WS Discovery. In one embodiment, a discovery request may request the service type provided by the MFP without the service metadata for each service. If a user of client 102 attempts to use one of the services of the MFP, client 102 may send a service discovery request for service metadata for that selected service. Alternatively, the discovery request may initially request service metadata for all services provided by the MFP.

The client 102 is communicably coupled with the MFP 104 via the communication network 114. Communication link 114 may be implemented by any medium or means that allows data exchange between the client 102 and the MFP 104. Specific examples of the communication link 114 are, but are not limited to, a local area network (LAN), a wide area network (WAN), a network such as Ethernet or the Internet, or one or more terrestrial, satellite or wireless links. including.

&lt;Multifunction device&gt; A MFP is a device that has two or more service applications, each of which provides at least one service. The various services provided by the MFP may include, but are not limited to, printing services, scanning services, facsimile services, archiving services, and the like. If one of the services provided by the MFP was a print service, the print service application would be prepared to process the print data and cause a print version of the electronic document to be reflected in the print data to be generated. Includes a printing process to prepare for. In Figure 1, the two or more service applications are the MFP services 112A-112C.

The MFP 104 also has a device service management system (DSMS) 110. DSMS110 manages the MFP service 112A-112C (collectively referred to as "MFP service 112"). The DSMS110 is a hardware circuit, may be realized by computer software, or may be realized by a combination of hardware circuit and computer software, and is not limited to a specific hardware or software implementation means.

The DSMS 110 acquires service status information and service metadata information for each service 112. The DSMS110 provides a common interface for multiple SDP service modules 106A-C (collectively referred to in the figure, hereinafter referred to as "SDP service 106") supported by the MFP104.

Figure 1 shows three SDP services 106, but the MFP 104 may support only two SDP services 106 and may support more than three SDP services 106.

&lt;Service Discovery Protocol Service&gt; SDP service 106 implements the SDP protocol. Each SDP service 106 may be realized by hardware circuits, computer software, or a combination of hardware circuits and computer software, and is not limited to specific hardware or software implementation means. Non-limiting examples of SDP Service 106 include WS Discovery and Simple Service Discovery Protocol (SSDP), both of which are standards (at least once). More SDP services may be deployed in the future. If the client 102 is restricted to one or more SDPs in a group and each of the SDPs is not supported by the MFP 104, then the client 102 is an MFP service provided by the MFP 104 such as print, scan or facsimile. 112 will not be found (and used).

Most SDP services have the following basic characteristics: First, in response to being notified that a device service (eg, the MFP service 112C) has become available or unavailable, the SDP service is brought to "the world" (ie, the network). Send some notifications (to all clients in), or at least send notifications to clients who are registered to be notified of such events. Second, the SDP service receives a discovery request from the client, requests service metadata, and forwards that service metadata to the client.

&lt;Service Discovery Protocol Adapter&gt; The SDP Adapter Module 108A-C (collectively referred to in the figure, hereinafter referred to as the "SDP Adapter 108") is the bridge between the SDP Service 106 and the DSMS 110. For example, the SDP adapter 108A is a bridge between the SDP service 106A and the DSMS 110, and the SDP adapter 108B is a bridge between the SDP service 106B and the DSMS 110, and so on. Similar to the SDP service 106, the SDP adapter 108 may be implemented in hardware circuits, computer software, or a combination of hardware circuits and computer software, and may be implemented as a means of implementing specific hardware or software. Is not limited.

The SDP adapter 108 converts the data (in native format) from the corresponding SDP service 106 into data in a format understandable by the DSNS110. Similarly, the SDP adapter 108 converts the data (in native format) from the DSNS110 into data that fits the format understood by the corresponding SDP service. As a result, the SDP adapter 108 essentially "decouples" the SDP service 106 from the DSNS110. This separation allows the DSNS110 to process multiple SDP services 106 without requiring to know anything about any of the services in the SDP service 106. This separation also allows the SDP service 106 to be transferred to different devices that accompany different DSMSs. The only change needed in this case would be to modify the corresponding SDP adapter so that it communicates with a different DSMS.

Therefore, one adapter in the SDP adapter 108 becomes an adapter for a particular service in the SDP service 106. So, for example, the SDP adapter 108B "knows" the interface of the SDP service 106B and what the SDP service 106B expects. Also, the SDP adapter "knows" the interface to the DSMS 110 and can properly request and receive data from the DSMS 110.

Therefore, each SDP adapter 108 supports at least two interfaces-one interface for the corresponding SDP service 106 and one interface for the DSNS110. The interface to SDP service 106 is protocol specific. The interface to the DSMS110 is defined by the DSMS110's common interface to the SDP service 106. Therefore, all SDP adapters 108 support their common interface.

&lt;Device service management system&gt; To support the above characteristics, the DSNS110 provides at least an interface to the SDP Adapter 108 (with respect to the registration, notification and device service metadata below).

For registration, most SDP protocols support notifications that device services are up or down. To support this notification feature, the DSNS110 provides a registration API that the SDP Adapter 108 uses with the DSNS110 for registration. In one embodiment, the SDP adapter 108 receives the unique identity (identification information) of the corresponding SDP service 106 in response to registration with the DSNS110. Since there are multiple SDP services 106, the DSNS110 uses a unique ID to know which SDP service 106 sent, for example, a request for service metadata. The DSMS110 uses a unique ID to return a response (eg, metadata) to the appropriate SDP adapter 108.

With respect to notifications, the DSNS110 notifies each SDP adapter 108 (the SDP adapter registered with the DSNS110), for example, in response to detecting that a service (eg, the MFP service 112C) has become available or unavailable. Send notifications via API.

With respect to providing service metadata, the SDP adapter 108 can send a request for metadata information about one or more MFP services 112 to the DSNS110, for example via the query metadata (query metadata) API. Non-limiting examples of service-specific metadata include URLs, service types, service endpoints, and the like. The URL is used by the client requesting the service metadata to communicate directly with the appropriate MFP service 112. Depending on the specific MFP service 112, the service type may be printer, scanner, camera, etc. The service endpoint specifies the method of contact with the MFP service 112, for example, the port number or IP address associated with the MFP service 112.

&lt;Sequence diagram&gt; FIG. 2 is an embodiment of the present invention showing how the SDP adapter and SDP service register with the DSMS, how device service notifications are received, and how the SDP service sends notifications. It is a sequence diagram by.

In step 1, the SDP adapter 108A registers with the DSNS110 by sending a registration message to the DSNS110 in order to receive service metadata and notifications from the DSNS110. Similarly, in step 2, the SDP adapter 108B registers with the DSNS110 by sending a registration message to the DSNS110.

In step 3, shortly after the SDP adapter 108A registers with the DSNS110, the DSNS sends a notification to the SD adapter 108A indicating that, for example, the new MFP service 112 is available to one or more clients on the MFP104. To do.

In step 4, the SDP adapter 108A requests service metadata for its new MFP service 112. In response, in step 5, the DSNS110 sends the requested service metadata to the SDP adapter 108A. Alternatively, the notification sent by the DSNS110 in step 3 may include the service metadata for the new MFP service 112. Thus, it is not mandatory for the SDP adapter 108A to request service metadata separately.

In step 6, in response to the notification and service metadata from the DSNS110, the SDP adapter 108A sends a notification to the SDP service 106A in a format that the SDP service 106A can "understand."

In step 7, the SDP service 106A sends a notification of the new MFP service 112 to one or more clients, for example client 102. Multiple clients may register with SDP Service 106A to be notified when a new MFP Service 112 is added and / or when an existing MFP Service 112 becomes unavailable. In that case, at least those clients who have registered for a particular event will be notified when that particular event occurs. Alternatively, the SDP service 106A may broadcast or multicast a notification message to clients in the network to notify the clients that the new MFP service 112 is available on the MFP 104.

Steps 8-12 are similar to steps 3-7, except that the SDP adapter is the SDP adapter 108B and the SDP service is the SDP service 106B. Step 8-12 is drawn to be done after step 3-7, but step 8-12 may be done prior to step 3-7 or alternated with step 3-7. May be good. For example, the processes may be performed in the order of steps 1,2,8,3,4,9,10,5,11,12,6,7.

As shown in Figure 2, the client receives two notifications. In general, current MFPs usually have only one SDP protocol, so only one such notification is sent to one or more clients. However, according to one embodiment of the invention, the MFP 104 does not know which SDP the client supports, so that all SDP services in the MFP will send notifications and all clients in the network will be notified. May be guaranteed. Client management notification case could not be the solution, the Kuraainto may discard the notification.

&lt;Flowchart&gt; FIG. 3 shows another blow chart according to one embodiment of the present invention showing how the SDP adapter and the SDP service interact.

In step 302, the SDP adapter 108A registers with the DSNS110. In step 304, the SDP adapter 108A continuously (or periodically) checks to see if notifications have been received from the DSNS110. If so, the process proceeds to step 306 and the SDP adapter 108A receives the service metadata from the DSNS110. In step 308, the SDP adapter 108A calls the SDP service 106A and sends a notification. After step 308, the process for SDP adapter 108A returns to step 304.

As shown in Figure 3, the thick line indicates that the message is sent from the SDP adapter 108A to the SDP service 106A and vice versa. Therefore, step 308 also shows that the message is sent from the SDP adapter 108A to the SDP service 106A. Figure 3 shows that SDP service 106A processes the notification (in step 308) at step 330.

In step 328, the SDP service 106A creates a thread to process the notification from the SDP adapter 108A. At step 330, the thread listens (monitors) (eg, on a particular port) and whether notifications are coming from (or intended to be sent from) the SDP adapter 108A. To confirm. If so, the process proceeds to step 322. In step 322, the thread sends a notification to one or more clients (eg, client 102), for example that the MFP service 112 is no longer available.

In step 320, SDP service 106A checks to see if a discovery request has been received. If a discovery request (eg, from client 102) has been received, the process proceeds to step 322.

In step 322, the SDP service 106A processes the discovery request by calling the SDP adapter 108A and retrieving the service metadata requested for one or more MFP services 112.

In step 310, the SDP adapter 108A creates a thread to process the request from the SDP service 106A. At step 312, the thread monitors (eg, on a particular port) to see if the SDP service 106A has sent a service metadata request. If so, the process proceeds to step 314.

In step 314, the SDP adapter 108A receives the service metadata from the DSNS110 (eg, via the getmetadata API call) and responds to the SDP service 106A with the requested service metadata.

In step 324, the SDP service 106A receives the requested service metadata from the SDP adapter 108A. In step 326, the SDP service 106A builds a response message based on the requested service metadata and sends the response message to, for example, the first client to send the discovery request processed in step 320. After the client receives the service metadata of one or more MFP services 112, the client may communicate directly with one or more MFP services 112.

In short, the SDP adapter 108 creates two threads, one for processing notifications from DSNS110 and the other for processing discovery requests from the corresponding SDP service 106. Is. Similarly, the SDP service 106 creates two threads, one for processing notifications from the corresponding SDP adapter 108A and another for processing discovery requests from clients.

&lt;Effect&gt; One advantage of one embodiment of the present invention is that if the DSNS110 is modified, no modification is required for any SDP service 106 and only the SDP adapter 108 needs modification.

Another advantage of one embodiment of the present invention is that if a new MFP service is added to or removed from the MFP 104, the SDP service 106, SDP adapter 108, and DSNS110 all need to be modified. Do not do it.

Another advantage of one embodiment of the invention is that if the SDP service 106 is modified, the DSNS110 does not need to be modified and only the corresponding SDP adapter 108A needs modification. Similarly, a new SDP service may be added to the MFP 104 without modifying the DSNS110.

Another advantage of one embodiment of the invention is that if the SDP service 106 is requested by another device (eg, another MFP) (the DSMS of that other device is not the same), the SDP service 106 will be rewritten. I don't need it. Instead, the only fix needed is to fix each corresponding SDP adapter so that each corresponding SDP can interface with the new DSNS.

&lt;Realization means&gt; The techniques described herein may be implemented on any type of computer platform or architecture. FIG. 4 shows a block diagram of a computer system 400 in which the embodiments of the present invention may be used. The computer system 400 has a bus 402 or other means of communication for communicating information and a processor 404 for processing information coupled to the bus 402. The computer system 400 has a main memory 406 coupled to a bus 402 such as random access memory (RAM) or other dynamic storage device, which stores instructions and information executed by the processor 404. Main memory 406 may be used to store temporary variables or other intermediate information during the execution of instructions executed by processor 404. Computer system 400 further includes read-only memory (ROM) 408 or other static storage device coupled to bus 402 that stores instructions and static information for processor 404. A storage device 410, such as a magnetic disk or other optical disk, is prepared to store information and instructions and is coupled to bus 402.

The computer system 400 may be coupled to a display 412, such as a cathode ray tube (CRT), via a bus 402 to display information to the user. An input device 414 containing alphanumeric characters and other keys is coupled to bus 402 to notify processor 404 of information and instruction selections. Another type of user input device is a cursor controller 416 (eg, mouse, trackball, stylus or cursor arrow keys) that notifies processor 404 of instructional information and instruction selection and the movement of the cursor on display 412. Control. This input device typically has two degrees of freedom with two axes, the first axis (eg x) and the second axis (eg y), allowing the device to specify a position on a plane.

The present invention relates to utilizing a computer system 400 with a wireless communication architecture. According to an embodiment of the present invention, wireless communication is provided by the computer system 400 in response to a processor 404 that executes one or more sequences of one or more instructions contained in main memory 406. Such instructions may be read into main memory 406 from other machine readable media such as storage device 410. Execution of the instruction sequence contained in main memory 406 causes processor 404 to perform the process steps described herein. One or more processors in a multiprocessing configuration may be used to execute the instruction sequence contained in main memory 406. In alternative embodiments, hard-wired circuits may be used alternatives or in combination with software instructions to carry out the present invention. That is, the embodiments of the present invention are not limited to any particular combination of hardware circuits and software.

As used herein, the term "machine readable medium" relates to any medium involved in providing data that causes a machine to operate in a particular format. In one embodiment using computer system 400, various machine readable media are incorporated, for example, when providing instructions to processor 404 in preparation for execution. Such media may take many forms and include, but are not limited to, non-volatile media, volatile media and transmission media. Non-volatile media include, for example, optical or magnetic disks such as storage device 410. Volatile media include dynamic memory such as main memory 406. Transmission media include coaxial cables, copper wires and optical fibers, and include the wires that make up bus 402. The transmission medium may take the form of sound waves or light waves, such as those produced during radio and infrared data communications.

Common forms of machine-readable media are floppy disks, flexible disks, hard disks, magnetic tape or any other magnetic medium, CD-ROM or any other optical medium, punched cards, paper tape or any other with a hole pattern. Includes physical media, RAM, PROM, EPROM, flash EPROM and other memory chips, cartridges, carriers as described above, or any other computer-readable medium.

Various forms of machine-readable media are also applicable when delivering one or more sequences of one or more instructions to processor 404 in preparation for execution. For example, instructions may initially be delivered on a remote computer's magnetic disk, which is far away. The remote computer may load the instruction from its dynamic memory and use a modem to send the instruction over the telephone line. A modem near computer system 400 receives the data over a telephone line and uses an infrared transmitter to convert the data into an infrared signal. The infrared detector coupled to the bus 402 receives the data carried by the infrared signal and puts the data on the bus 402. Bus 402 carries the data to main memory 406, and processor 404 extracts and executes instructions from main memory. Instructions received in main memory 406 may be selectively stored in storage device 410 before or after they are executed by processor 404.

The computer system 400 also includes a communication interface 418 coupled to bus 402. Communication interface 418 provides bidirectional data communication coupled to network link 420 connected to local network 422. For example, the communication interface 418 may be an integrated services digital network (ISDN) card or modem that provides a data communication connection to the corresponding type of telephone line. In another example, the communication interface 418 may be a LAN card that provides a data communication connection to a compatible LAN. Wireless links may be used. In any implementation, the communication interface 418 transmits and receives electrical, electromagnetic or optical signals and carries a digital data stream that represents various types of information.

Network link 420 typically provides data communication with other data devices over one or more networks. For example, network link 420 provides a connection to a host computer via a local network 422 or a connection to a data device operated by an Internet Service Provider (ISP) 426. The ISP 426 then provides data communication services over a worldwide packet data communication network (today commonly referred to as the Internet 428). Both local networks 422 and Internet 428 use electrical, electromagnetic or optical signals that carry digital data streams. The signals via various networks and the signals via the communication interface 418 in the network link 420 may take the form of a carrier wave that carries digital data to and from the computer system, for example, transmitting information.

The computer system 400 sends a message and receives data including a program code via a network, a network link 420 and a communication interface 418. In the Internet example, server 430 may send the requested code for an application program over Internet 428, ISP426, local network 422 and communication interface 418.

The received code may be executed when it is received, or it may be stored in storage device 410 or other non-volatile storage for later execution. In this way, the computer system 400 may acquire the application code in the form of a carrier wave.

The specific specific embodiments of the present invention have been described above with many specific details that may vary from embodiment to embodiment. The indicator of the exclusive right indicating that the applicant intends to be an invention and what the invention is is the scope of the claims of the present application, and the specific expression of the scope of the claims may be amended in any manner thereafter. Including. Any explicit definition that refers to a term that appears in the claims governs the meaning of such terms used in the claims. Therefore, any limitation, element, characteristic, feature, advantage or attribute that does not explicitly appear in the claims should not limit the claims in any way. Therefore, the specification and drawings are construed as exemplary rather than limiting.

<figref num="1">It is a block diagram which shows the service discovery protocol (SDP) architecture example by one Example of this invention which interacts between a client and a MFP.</figref><figref num="2">One of the inventions showing how SDP adapters and SDP services register with the Device Service Management System (DSMS), how device service notifications are received, and how SDP services send notifications. It is a sequence diagram by an Example.</figref><figref num="3">Another blow chart according to an embodiment of the present invention showing how the SDP adapter and the SDP service interact is shown.</figref><figref num="4">It is a block diagram which shows the computer system in which this invention may be carried out.</figref>

Code description

400 computer system 402 Bus 404 processor 406 main memory 408 Read-only memory 410 storage device 412 display 414 Input device 416 Cursor control unit 418 Communication interface 420 network link 422 Local network 424 host 426 Internet Service Provider 428 internet 430 server