JP2006338582A - Printer management device, its control method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To relieve a load to a resource of a logical printer server which manages a plurality of physical printers. <P>SOLUTION: This printer management device (device A) as the logical printer server is constituted so that it manages attribute information, state information of the physical printers (devices B, C, D), when a job request is received from a PC 105, selects a physical printer which processes the job request based on the information to be managed, transfers the job request to the selected physical printer and transfers a print destination (URI showing a print port) returned from the physical printer as its response to the PC 105. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to control of a distributed printing system including a plurality of physical printers, a logical printer that manages each physical printer, and a client device that issues a print instruction to the logical printer.

  With the recent development of the LAN environment, not only personal computers but also devices such as multifunction peripherals and printers are supported and shared within the LAN.

  When a client PC executes printing for a printer connected in such a LAN environment, there are cases where printing is performed by specifying a physical printer, and printing is performed by specifying a logical print server. It is.

  Patent Document 1 describes an information processing apparatus as the logical print server.

This information processing apparatus manages a plurality of physical printers, and when there is a print request from a client PC, the job is held once in the print server, and an appropriate physical printer is selected according to the request, It was designed to deliver jobs.
JP-A-7-2197331

  However, in the information processing apparatus described in Patent Document 1, it is necessary for the information processing apparatus to hold print data transmitted from the client PC once. For this reason, a large load is often applied to the resources of the information processing apparatus equipped with the logical print server function. In addition, there is a problem in that printing cannot be performed unless there is sufficient free space on the hard disk in the information processing apparatus.

  The present invention has been made to solve the above-described problems, and an object of the present invention is to send a job request and send a real print data to a print destination that is returned in response to the job request. And a printer management apparatus capable of communicating with a plurality of physical printers that return print destinations in response to received job request requests and print processing print data transmitted to the print destinations. , Storing and managing status information in a memory and receiving a job request from a client device, selecting one of the physical printers that processes the job request based on the information stored and managed in the memory The job request request is transferred to the received physical printer, and the print destination returned from the physical printer as the response is sent to the class printer. By transferring to the ant device, the client device can directly send the print data to the physical printer, so there is no need to manage the print data in the printer management device, and the printer management can reduce the load on the resources An apparatus, a printing system, a printer management method, a program, and a storage medium are provided.

  The present invention transmits a job request request and transmits a real print data to a print destination specified by a job reception response returned in response to the job request request, and in response to the received job request request In a printer management apparatus communicable with a plurality of physical printers that send back print destinations, a management means for storing and managing attribute information and status information of each physical printer; and a management means upon receiving a job request from the client apparatus Selecting one of the physical printers that processes the job request request based on the information managed by the control unit, and transferring the job request request to the physical printer selected by the selection unit, A transfer method for transferring the print destination returned from the physical printer as a response to the client device. Characterized in that it has and.

  According to the present invention, a client device that transmits a job request and sends actual print data to a print destination that is returned in response to the job request, and a print destination that returns a print destination in response to the received job request. A printer management device capable of communicating with a plurality of physical printers that perform print processing of print data transmitted to a print destination stores and manages the attribute information and status information of each physical printer in a memory, and receives a job request from a client device Then, it selects one of the physical printers that processes the job request request based on information stored and managed in the memory, transfers the job request request to the selected physical printer, and responds to the response. From the client device by transferring the print destination returned from the physical printer to the client device as Printing data is sent directly sent to a physical printer, it is not necessary to manage the print data in the printer management apparatus, it is possible to reduce the load to the resource.

  Further, since the printer management apparatus does not need to hold a job (print data) from the client apparatus, the logical print server function can be realized even in an apparatus that does not include a large-capacity storage device such as an HDD. Become.

  Accordingly, in the print management apparatus, data can be delivered to each physical printer without spooling the data, and the load of resources of the print management apparatus having the logical print server function can be reduced. There is an effect.

[First Embodiment]
Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

  FIG. 1 is a system configuration diagram showing a configuration of a print system to which a logical print server (printer management apparatus) showing an embodiment of the present invention can be applied. Here, a multi-function peripheral (MFP) having a network connection function is shown as an example of a network device apparatus to which the logical print server can be applied, but the logical print server is another information processing apparatus such as a computer. It may be.

  In FIG. 1, 101, 102, 103, and 104 are multifunction device devices (MFPs) that can be connected to the LAN 100.

  The MFPs 102, 103, and 104 correspond to physical printers in the present invention. Further, the MFP 101 corresponds to a printer (logical print server (printer management apparatus)) having a logical printer pre-installed that manages a physical printer and can handle a plurality of physical printers as a single printer in the present invention. . The MFP 101 is also a physical printer.

  Reference numeral 105 denotes a personal computer (PC). The PC 105 is connected to the LAN 100 together with the printer (MFP 101) and the physical printers (MFPs 102, 103, 104) having the logical printer function of the present invention described above.

  In this embodiment, the PC 103 makes a print request to a printer (MFP 101) having a logical printer function, and the logical printer (MFP 101) selects an appropriate physical printer according to the request and performs printing. It has become.

  In other words, the print system according to the present embodiment is a distributed print system including a plurality of physical printers, a logical printer that manages each physical printer, and a client device that issues a print instruction to the logical printer.

  FIG. 2 is a block diagram showing a schematic configuration of the printer (MFP 101) having the logical printer function shown in FIG.

  In FIG. 2, reference numeral 201 denotes a scanner engine control unit that controls the scanner engine 213. Reference numeral 202 denotes a CPU. The CPU 202 loads a program stored in the ROM 203 or the HDD 207 into a boot ROM (RAM) 204 and executes it, and performs overall control of the entire MFP.

  Reference numeral 205 denotes a non-volatile RAM (NVRAM) for holding a value set from the panel. An engine control unit 206 controls the printer engine 212.

  Reference numeral 208 denotes a timer. Reference numeral 209 denotes an I / O control unit that controls a user interface portion 214 such as a panel or a button lamp. Reference numeral 210 denotes a network control unit for connecting to the LAN 100. As described above, the devices 201 to 210 are connected to the bus 211, respectively.

  As described above, the same functional blocks as those of the MFP 101 shown in FIG. 2 are also provided in the MFPs 102, 103, and 104 shown in FIG. 1, and in the present embodiment, they are referred to as physical printers using their print functions.

  FIG. 3 is a plan view showing an example of the user interface portion 214 shown in FIG.

  In FIG. 3, reference numeral 301 denotes a large touch panel, and the user can perform various settings under the control of the CPU 202 by operating the touch panel. FIG. 3 shows a case where a standby screen for copying is displayed on the touch panel 301.

  A numeric keypad 302 is used to input numbers “1” to “0”. The “S” button is a service button. When the “S” button is pressed, various service screens appear on the touch panel 301 under the control of the CPU 202, and services other than copying can be performed. The “R” button is a setting button. When the “R” button is pressed, various setting screens appear on the touch panel 301 under the control of the CPU 202 and parameters can be set.

  Reference numeral 303 denotes a speaker from which sound, a buzzer, and the like are output under the control of the CPU 202. Reference numeral 304 denotes a lamp. When printing or copying is jammed, the lamp 304 is blinked under the control of the CPU 202.

  FIG. 4 is a block diagram of a module configuration for controlling the devices of the MFPs 101, 102, 103, and 104 shown in FIG. 1 around the network.

  In FIG. 4, 401 is an EtherDriver, which is a driver module for connecting to the LAN 100 and transmitting and receiving Ethernet (registered trademark) packets.

  Reference numeral 402 denotes a TCP / IP protocol stack. The device of the present invention supports multi-protocols and can communicate with protocols such as NetWare and AppleTalk, but the description is omitted here.

  Reference numeral 403 denotes a socket layer, which defines an API for using the TCP / IP protocol. All programs that communicate using TCP / IP communicate using the API provided by the socket layer 403.

  Reference numeral 404 denotes an HTTP PD module, which has an HTTP processing function, determines a URL, and performs each process. Reference numeral 405 denotes a module called RemoteUI, which can refer to devices using the HTTP protocol.

  Reference numeral 406 denotes a SOAP module, and reference numeral 407 denotes a print service module (PrintService), which is a module for realizing a print service (SOAP print service) using SOAP / XML. Note that this print service module 407 also realizes functions using the HTTP protocol.

  Reference numeral 408 denotes an IPP module that realizes a function of performing printing using the IPP protocol. The IPP protocol is a printing protocol on HTTP, and is a protocol for transmitting and controlling a print job via HTTP.

  Reference numeral 409 denotes an LPD module that realizes a printing function using the LPD protocol. Reference numeral 410 denotes a Printer API, and each print module (LPD, IPP, SOAP print service) transfers received print data via the Printer API 410. The data received from the Printer API 410 is handled in the device under the control of the CPU 20, developed into a bitmap, and then sent to the printer engine 212 via the engine control 206 to be printed.

  Hereinafter, a case where printing is executed from a client PC using a SOAP print service in the print system according to the present embodiment will be described.

  In the printing system according to the present embodiment, when printing is performed from a client PC using the SOAP print service, a method of performing printing by designating a physical printer (first printing method) and a plurality of physical printers A method (second printing method) of performing printing by designating a logical print server that manages the above is possible.

[First printing method]
Hereinafter, with reference to FIG. 5 to FIG. 10, first, a case where printing is executed by the first printing method will be described.

  FIG. 5 shows an example of packet data called “CreateJob” transmitted from the client (PC 105) to the printing apparatuses (MFPs 102 to 104) in the protocol of the SOAP print service over HTTP in the print system of the present embodiment. FIG.

  In FIG. 5, reference numeral 500 denotes data indicating a CreateJob packet, which is described in the XML format. The CreateJob packet 500 is a command (job request request data) that instructs the printing apparatus to start a job (printing).

  In the CreateJob packet 500, information such as a request source user name (<requesting-user-name> tag 501) and an instruction related to job processing (<job-instruction> tag 502) is described.

  The <job-instruction> tag 502 includes a <copies> tag 503 for setting the number of copies to be printed, a <sides> tag 504 for setting double-sided printing, a “<finishing>” tag 505 for setting printing finishing, and the like. It is. Then, the printing apparatus performs job processing based on the values set in these tags.

  Furthermore, the <job-instruction> tag 502 may optionally include a <notification-instruction> tag 506. The <notification-instruction> tag 506 describes notification information related to the job. In the example shown in FIG. 5, a <notification-recipient> tag 507 for setting a notification destination and an <event> tag 508 for setting a notification condition are described as notification information. The printing apparatus performs an event transmission process based on the values set in these tags.

  In this embodiment, since “job-completed” and “job-canceled” are designated by the <event> tag 508, an event is notified at “when job printing is finished” and “when job is canceled”. .

  FIG. 6 is a diagram illustrating an example of response packet data (CreateJob response packet) that is returned from the printing apparatus to the client in response to the CreateJob packet illustrated in FIG. 5.

  In FIG. 6, reference numeral 600 denotes data indicating a CreateJob response packet (job reception response data), which is described in the XML format in the same manner as the CreateJob packet shown in FIG. In this embodiment, the CreateJob response packet 600 is transmitted / received using SOAP over HTTP.

  The CreateJob response packet 600 includes a result code (<result-code> tag 602) for the CreateJob command, an identifier of the generated job (<job-id> tag 603), and a URI (<data-sink) for the print port. -uri> tag 604) and the like are included. Note that the portion indicated by 601 in FIG. 6 is a portion indicating the URI (data for specifying the print destination) of the print port. In the example of FIG. 6, the URI “http://192.168.1.4/job001” is shown as the URI of this printing port.

  Hereinafter, referring to the flowchart of FIG. 7, in the printing system of the present embodiment, when printing is performed by designating a physical printer from the client PC using the SOAP print service (when printing is performed by the first printing method). ) Will be described in detail.

  FIG. 7 is a flowchart showing an example of a first control processing procedure in the printing system of the present invention. This flowchart corresponds to the operation of the printing apparatus (physical printer) when printing is executed by specifying a physical printer from the host computer (client) (when printing is executed by the first printing method). To do. Further, S701 to S708 in FIG. 7 correspond to the steps executed by the printing apparatus (MFPs 102, 103, and 104 shown in FIG. 1). Further, S701 to S708 are executed when the CPU 202 of the printing apparatus loads a program stored in the ROM 203 or the HDD 207 into the RAM 204 and executes it.

  First, when the CreateJob packet 500 as shown in FIG. 5 is transmitted from the host computer (PC 105) to the printing apparatus, the CPU 202 of the printing apparatus analyzes the XML data described in the CreateJob packet 500 in step S701, In step S702, it is determined whether there is an error in the analysis result.

  If the CPU 202 of the printing apparatus determines in step S702 that there is no error in the analysis result, it generates a print port for receiving print data in step S703.

  When the process of step S703 ends, the CPU 202 of the printing apparatus advances the process to step S705, and generates XML data (CreateJob response packet 600 as shown in FIG. 6) of the response to the CreateJob packet 500. At this time, the CPU 202 of the printing apparatus sets the URI of the port generated for print data reception in step S703 as the value of the <data-sink-uri> tag 604. For example, a URI as indicated by 601 in FIG. 6 is embedded in the XML data.

  Next, when the CPU 202 of the printing apparatus finishes generating the CreateJob response data (CreateJob response packet 600) shown in step S705, the process proceeds to step S706.

  In step S706, the CPU 202 of the printing apparatus transmits the data (CreateJob response packet 600) generated in step S705 to the host computer using SOAP.

  Thereafter, the host computer transmits print data 800 as shown in FIG. 8 to the URI specified by the <data-sink-uri> tag 604 using the HTTP POST method.

  FIG. 8 is a diagram illustrating an example of a print data transfer packet by the HTTP POST method.

  In step S707, the CPU 202 of the printing apparatus receives the data that has arrived at the print port, and executes print processing on the printer while performing appropriate processing. When the reception of the print data in step S707 ends normally, the CPU 202 of the printing apparatus transmits an HTTP response packet 900 as shown in FIG. 9 to the host computer in step S708, and deletes (closes) the print port. The printing operation is terminated.

  FIG. 9 is a diagram illustrating an example of an HTTP response packet.

  On the other hand, if the CPU 202 of the printing apparatus determines in step S702 that there is an error in the XML data described in CreateJob 500, the process proceeds to step S704.

  In step S704, the CPU 202 of the printing apparatus generates error response data 1000 as shown in FIG.

  FIG. 10 is a diagram illustrating an example of packet data of an error response returned from the printing apparatus to the client in response to the CreateJob packet 500 illustrated in FIG.

  In FIG. 10, 1000 is data indicating an error response packet which is a response packet when the CreateJob packet 500 is error data.

  In step S706, the CPU 202 of the printing apparatus transmits the error response 1000 generated in step S704 to the host computer. The host computer that has received the error response 1000 does not transmit print data and ends the process.

  The above corresponds to the method (first printing method) in which printing is performed by designating a physical printer when printing is performed from the client PC using the SOAP print service in the printing system of the present embodiment.

[Second printing method]
Next, referring to FIGS. 11 to 26, in the printing system of the present invention, printing is executed by designating a logical print server that manages a plurality of physical printers from the host computer (client) (second). Will be described).

  FIG. 11 is a schematic diagram showing a physical printer management mode by the logical printer in this embodiment, and the same components as those in FIG. 1 are denoted by the same reference numerals.

  As shown in FIG. 11, the device A (MFP 101) searches for the devices B, C, and D (MFPs 102, 103, and 104), and monitors the status of the printer that each device is serving. In the following description, the MFP 101 is referred to as device A, and the MFPs 102, 103, and 104 are referred to as devices B, C, and D.

  FIG. 12 is a diagram illustrating an example of a format of a search packet transmitted from the device A illustrated in FIG. 11 to search for another device.

  As indicated by reference numeral 1201 in FIG. 12, the search packet 1200 is multicast on the network using a method called M-SEARCH of HTTP.

  In the present embodiment, when the device A transmits a packet 1200 as shown in FIG. 12, each device B, C, D returns a response packet 1300 as shown in FIG.

  FIG. 13 is a diagram showing an example of a format of a response packet 1300 for the search packet 1200 shown in FIG.

  As shown in FIG. 13, a device description file (DDF) is defined in the URI indicated by the <loc> tag 1301 in the response packet 1300.

  The device A extracts the tag 1301 beginning with <loc> from the response packet 1300, and extracts the URI of the DDF file. Then, the device A accesses the extracted URI, and stores the location information of the devices B, C, and D, and the attribute files of the devices B, C, and D (DDF file 1400 as shown in FIG. 14). Will be acquired.

  FIG. 14 is a diagram showing an example of the format of the DDF file acquired from the URI indicated by the <loc> tag 1301 shown in FIG.

  When the device A acquires the URI starting with the <loc> tag 1301 illustrated in FIG. 13 using the HTTP GET method, the devices B, C, and D return the DDF file 1400 illustrated in FIG. 14 as a response.

  In FIG. 14, reference numeral 1401 indicates a URI that stores the attribute file of the device by a <SCPDURL> tag. In this example, the URI is “/bmlinks/sdf-print.xml”. Reference numeral 1402 denotes position information of the device. In this example, it is indicated by a <FL> tag and its position is “2F-2”.

  Then, the device A responds to the URI indicated by the <SCPDURL> tag 1401 from the response packet (DDF file 1400) with the attribute files of the devices B, C, and D (SDF as shown in FIGS. 15 to 16). File 1500).

  15 to 16 are diagrams showing examples of the format of the SDF file that is the device attribute file acquired from the URI indicated by the <SCPDURL> tag 1401 shown in FIG.

  When the device A acquires the URI starting with the <SCPDURL> tag 1401 shown in FIG. 14 by using the HTTP GET method, the devices B, C, and D respond with the SDF files 1500 shown in FIGS. 15 to 16, respectively. Return to.

  1501 in the SDF file 1500 indicates the name of the device. Since the attribute starting with the <name> tag 1501a is “service-name”, the service name of the device is shown here. As the possible values, the value starting with the <allowedValue> tag 1501b is the service name itself (in this case, “B”). Thereby, it can be seen that the service name of this device is “B”.

  An attribute 1502 indicates whether color printing is possible. The attribute starting with the <name> tag 1502a is “colors”, and the possible value <allowedValue> 1502b is “0”. This indicates that this device does not support Color printing.

  1503 describes finishing. The attribute starting with the <name> tag 1503a is “finishings”, and the possible value <allowedValue> tag 1503b indicates the value “not-supported”. This indicates that this device does not support the finisher.

  Reference numeral 1601 describes supported paper types. The attribute starting with the <name> tag 1601a is “media”, and the possible value <allowedValue> is “iso-A3, jis-b4, iso-A4, jis-b5”. This indicates that the paper sizes supported by this device are A3, B4, A4, and B5.

  Reference numeral 1602 describes the engine speed of this device. The attribute starting with the <name> tag 1602a is “pages-per-minute”, and the possible value <allowedValue> tag 1602b is “32”. From this, it is understood that the engine speed supported by this device is “32 PPM (Page-Per-Minutes)”.

  FIG. 17 is a diagram illustrating an example of a device management table for managing attribute information of each device acquired from the DDF and SDF illustrated in FIGS. 14 and 15 to 16 by the device A illustrated in FIG.

  In FIG. 17, reference numeral 1700 denotes a device management table, which is stored in the RAM 203, NVRAM 205, or HDD 207 in the device A.

  As shown in FIG. 17, for example, in the device B, the engine speed (PPM) is “32”, the presence / absence of color printing (Color) is “false”, the presence / absence of stapling (Staple) is “OFF”, and the supported media size (Media Size) is “A4, A3, B4, B5”, the device position (Locale) is “2F-1”, and the status (Status) is “printing” (printing).

  Note that the device management table 1700 stores and manages the attribute information of each device, the job execution status, and the like for each device (in FIG. 17, the device is described for each column).

  18 and 19 are schematic diagrams schematically describing how the PC 105 sends data to the device C via the device A as the logical printer server.

  In FIG. 18, the PC 105 issues CreateJob 500 as shown in FIG. 5 to the device A as the logical printer server. Then, the device A refers to the device management table 170 (FIG. 17) and selects a physical printer that can be printed against the conditions of CreateJob. Here, if only the device C is a physical printer that meets the conditions of CreateJob and is currently printable, the device C is selected. Then, device A transfers CreateJob 500 to selected device C.

  Then, the device C returns a CreateJob response response 600 (FIG. 6) including a <data-sink-uri> tag to the device A. Then, the device A transfers the CreateJob response response 600 received from the device C to the PC 105.

  Then, as shown in FIG. 19, the PC 105 print data (data) with respect to the URI (601 in FIG. 6) indicated by the <data-sink-uri> tag 604 on the CreateJob response response 600 returned from the device A. ) Is transferred using the HTTP POST method.

  Note that the device C issues an event to the device A at the start and end of printing (details will be described later).

  20 is a diagram showing an internal module configuration of the print service 407 (FIG. 4) installed in the device A shown in FIG.

  In FIG. 20, reference numeral 2001 denotes a job / device management module, and reference numeral 2002 denotes an event reception module, which corresponds to an internal module of the print service 407.

  The job / device management module 2001 manages the attributes and jobs of each device and registers them on the device management table 1700 (FIG. 17). The event reception module 2002 receives an event raised from each device, and registers the state of the device in the device management table 1700.

  As described above, the print service 407 installed in the device A manages the attributes and jobs of each device by the internal module and registers them on the device management table 1700 (FIG. 17), and the events raised from each device. And the status of the device is registered in the device management table 1700.

  Hereinafter, with reference to the flowcharts of FIGS. 21 to 26, in the printing system of the present invention, printing is executed by designating a logical print server that manages a plurality of physical printers from the host computer (client) (second). The flow of processing in the case of performing printing with this printing method will be described in detail.

  FIG. 21 is a flowchart showing an example of a second control processing procedure in the printing system of the present invention. This flowchart is a process of creating the device management table 1700 shown in FIG. 17 by the job / device management module 2001 shown in FIG. 20 (processing for registering the name, attribute, etc. of each device in the device management table 1700). Corresponds to the flow. 21 correspond to the steps executed by the device A. Further, S2101 to S2106 are executed when the CPU 202 of the device A loads a program stored in the ROM 203 or the HDD 207 into the RAM 204 and executes it.

  The job / device management module 2001 (executed by the CPU 202) of the device A starts the process of this flowchart at a predetermined timing such as when the power is turned on. In step S2101, the search packet 1200 shown in FIG. Send on. The job / device management module 2001 transmits the search packet 1200 to the multicast address using the M-SEARCH method of HTTP.

  In step S2102, the job / device management module 2001 waits for a response from each device. Each device returns a response packet 1300 as shown in FIG.

  If the job / device management module 2001 determines in step S2102 that a response from each device has been received, the process proceeds to step S2103.

  In step S2103, the job / device management module 2001 selects any response packet from the response packets received from each device (hereinafter, a device corresponding to the selected response packet is referred to as a “current device”). ). The job / device management module 2001 accesses the URI indicated by the <loc> tag 1301 in the selected response packet 1300 and requests the DDF file 1400 (FIG. 14) using the HTTP GET method. And get.

  Then, the job / device management module 2001 extracts the URL of the SDF file (1401 shown in FIG. 14) and the location information (1402 shown in FIG. 14) from the acquired DDF file 1400. Further, the job / device management module 2001 registers the extracted location information as current device information in the Locale column in the device management table 1700.

  In step S2104, the job / device management module 2001 accesses the URI of the extracted SDF file and requests and acquires the SDF file using the HTTP GET method. The job / device management module 2001 extracts each attribute value from the acquired SDF file 1500 and registers it on the device management table 1700 as current device information.

  Specifically, the job / device management module 2001 extracts a device name from 1501 (FIG. 15) in the SDF file 1500 and registers it in the Device column in the device management table 1700 as current device information. Also, the job / device management module 2001 extracts information on the presence / absence of color printing support from 1502 (FIG. 15) in the SDF file 1500, and registers it as current device information in the Color column in the device management table 1700. To do.

  Further, the job / device management module 2001 extracts finisher support information from 1503 (FIG. 15) in the SDF file 1500 and registers it in the Staple column in the device management table 1700 as current device information. Also, the job / device management module 2001 extracts supported paper type information from 1601 (FIG. 16) in the SDF file 1500, and stores it in the mediaSize column in the device management table 1700 as current device information. sign up.

  Further, the job / device management module 2001 extracts information about the engine speed from 1602 (FIG. 16) in the SDF file 1500 and registers it in the PPM column in the device management table 1700 as current device information.

  In step S2105, the job / device management module 2001 transmits an event issuance request 2700 (FIG. 22 to be described later) to the current device (event issuance process).

  FIG. 22 is a diagram showing an example of the format of an event issuance request in this embodiment.

  In this embodiment, as indicated by reference numeral 2701 in FIG. 22, an event issuance request is registered so that an event is notified under a condition starting with an <event> tag.

  In the example shown in FIG. 22, “job-created” (when creating a job), “job-completed” (when the job is completed successfully), “job-canceled” (when canceling a job), “device-state-changed” (device The device is registered to notify the event when the status changes).

  Hereinafter, the description returns to the flowchart of FIG.

  When the transmission of the event issuance request is completed, the job / device management module 2001 then acquires device information for all devices in step S2106 (whether the processing in steps S2103 to S2105 has been completed). Determine whether.

  If the job / device management module 2001 determines in step S2106 that the device information has not yet been acquired for all devices, the process returns to step S2103 to acquire the next device information. To do.

  On the other hand, if it is determined in step S2106 that the job / device management module 2001 has acquired device information for all devices, the processing ends.

  As described above, the names and attributes for all devices that have responded to the search packet 1200 are registered in the device management table 1700.

  The flow of processing for receiving an event issued when an event occurs from each device and registering it in the device management table 1700 will be described below using the flowchart of FIG.

  FIG. 23 is a flowchart showing an example of a third control processing procedure in the printing system of the present invention. This flowchart corresponds to the flow of processing for creating the device management table 1700 shown in FIG. 17 by the job / device management module 2001 shown in FIG. 20 (processing for registering the status of each device in the device management table 1700). To do. Also, S2201 to S2202 in FIG. 23 correspond to each step executed by the device A. Further, S2201 to S2202 are executed when the CPU 202 of the device A loads a program stored in the ROM 203 or the HDD 207 into the RAM 204 and executes it.

  The event reception module 2002 (executed by the CPU 202) of the device A starts the process of this flowchart at a predetermined timing such as when the power is turned on or when the process shown in FIG. 21 is completed. Wait for event reception.

  If it is determined in step S2201 that the event reception module 2002 has received an event 2400 (FIG. 24) from a device, the process proceeds to step S2202.

  In step S2202, the event reception module 2002 determines device state information such as “job completed” and “job started” from the event received in step S2201 (for example, <job-state- in FIG. 24). reason >> "job-completed-successfully" shown in the tag 2401). Then, the event reception module 2002 updates and registers the information indicating the extracted device status in the Status column in the device management table 1700 illustrated in FIG. 17 as the information of the event transmission source device.

  Then, the event reception module 2002 returns the process to step S2201 to return to a state of waiting for event reception from each device.

  FIG. 24 is a diagram illustrating an example of an event format issued by each device and received by the event reception module 2002 of the device A in the present embodiment.

  Hereinafter, the flow of processing in which each device transmits an event to device A when an event occurs will be described with reference to the flowchart of FIG.

  FIG. 25 is a flowchart showing an example of a fourth control processing procedure in the print system of the present invention. This flowchart corresponds to the flow of processing in which each device that receives the event issuance request transmitted from device A in step S2105 shown in FIG. 21 transmits an event when an event occurs. Also, S2301 to S2302 in FIG. 25 correspond to the steps executed by the devices B, C, and D. Further, S2301 to S2302 are executed when the CPU 202 of the devices B, C, and D loads a program stored in the ROM 203 or the HDD 207 into the RAM 204 and executes it.

  First, the CPU 202 of each device such as devices B, C, and D starts the processing of this flowchart when it is registered to notify an event when there is a state change from the device A in step S2105 shown in FIG. To do.

  In step S2301, the CPU 202 of each of the devices B, C, and D monitors whether there has been a state change registered so as to be notified from the device A by its own device, and waits until the state change occurs.

  If the CPU 202 of the devices B, C, and D determines in step S2301 that there has been a change in the state (for example, if there has been a change in state such as “job reception has started” or “job has ended”) In step S2302, the CPUs 202 of the devices B, C, and D generate an event packet as shown in FIG. 24 and notify the device A using the HTTP POST method.

  Then, the CPUs 202 of the devices B, C, and D return the process to step S2301 and monitor again whether or not the above-described state change has occurred.

  In this way, the device A as the logical print server acquires the attribute information of each device (device B, C, D) as the physical printer, and monitors the change in the state of the device by the event.

  Hereinafter, referring to the flowchart of FIG. 26, in the printing system of the present invention, printing is executed by designating a logical print server (device A) that manages a plurality of physical printers from the host computer (client PC 105). (When printing is executed by the second printing method) will be described.

  FIG. 26 is a flowchart showing an example of a fifth control processing procedure in the print system of the present invention. This flowchart shows a case where printing is executed by designating a logical print server (corresponding to the device A) that manages a plurality of physical printers from the host computer (client) (when printing is executed by the second printing method). ) Of the logical print server (device A). Also, S2501 to S2506 in FIG. Further, S2501 to S2506 are executed when the CPU 202 of the device A loads a program stored in the ROM 203 or the HDD 207 into the RAM 204 and executes it.

  First, when the CreateJob packet 500 as shown in FIG. 5 is transmitted from the host computer (PC 105) to the device A as the logical print server, the CPU 202 of the device A receives this, and in step S2501, the CreateJob packet 500 The XML data described in 500 is analyzed to extract printing conditions. For example, when the printing conditions are extracted from the XML data (CreateJob packet 500) shown in FIG. 5, since “staple” is designated in the <finishing> tag 505, the host computer 105 desires staple printing. I understand that.

  Therefore, the CPU 202 of the device A searches the device management table 1700 shown in FIG. 7, and searches for devices whose Staple is “ON” and the current Status is “Active” (S2502). Devices whose Status is “printing” or “Error” are excluded because they cannot be printed immediately. Here, it is assumed that the device that matches the above condition (Staple is “ON” and the current Status is “Active”) is “C”, and the device C is selected.

  Next, in step S2503, the CPU 202 of the device A transfers the CreateJob command 500 requested from the host computer 105 to the selected device C.

  Then, the device C that has received the CreateJob command 500 generates a print port for receiving print data through the sequence shown in FIG. Further, the device C generates a CreateJob response response 600 in which the URI of the generated port is set as the value of the <data-sink-uri> tag 604 (FIG. 6), and returns it to the device A.

  When the CPU 202 of the device A receives the CreateJob response response 600 from the device C, it returns the CreateJob response response 600 of the device C returned from the device C to the host computer 105 in step S2504.

  Then, the host computer 105 performs printing as shown in FIG. 8 using the HTTP POST method for the URI indicated by the <data-sink-uri> tag 600, as in the sequence shown in FIG. Data 800 is transmitted (S2510). This procedure eliminates the need for device A to receive a job (print data) from the host computer and transfer it to device C, unlike a conventional print server. Therefore, the load on the device A is reduced as compared with the conventional print server.

  Note that when the device C receives print data from the host computer 105, the status of the device C changes. Therefore, the device C issues a “Job-created” event to the device A. This event is registered in the device C in step S2105 shown in FIG. 21 when the device A is powered on.

  In the device A, when receiving the event from the device C, the event receiving module 2002 of the device A registers the status of the device C as “printing” in the Status column of the device management table 1700 in step S2505.

  When the reception from the host computer 105 is completed, the device C returns a response to the host computer 105 as in the sequence shown in FIG. 7 (S2511). The device C expands the received data and performs print processing.

  When the printing process is completed in the device C, the device C notifies the device A of a “job-completed” event.

  In the device A, when receiving the event from the device C, the event receiving module 2002 of the device A registers the state of the device C as “Active” in the Status column of the device management table 1700 in step S2506.

  Further, since CreateJob 500 shown in FIG. 5 includes a description for notifying the host computer of event notification, the device C also sends “job-completed” to the host computer 105 in the same manner as the sequence shown in FIG. The event is notified (S2512). In addition, the device C deletes (closes) the printing port and ends the printing operation.

  As described above, according to the printing system of the present embodiment, the device A as the logical print server apparatus sends the print data transmitted from the host computer 105 to each physical printer without spooling the print data. It can be delivered. Therefore, it is possible to reduce the load (load of resources such as HDD, load due to data transfer processing, etc.) in the device A having the logical print server function.

[Second Embodiment]
In the first embodiment, the device management table 1700 (FIG. 17) is created when the device A is turned on. However, the device A creates the device management table 1700 at the timing after receiving CreateJob from the host computer. However, the CreateJob may be transferred to the corresponding device.

  Hereinafter, with reference to the flowchart of FIG. 27, the case where it prints with the 2nd printing method in 2nd Embodiment of this invention is demonstrated.

  FIG. 27 is a flowchart showing an example of a sixth control processing procedure in the printing system of the present invention. This flowchart shows a case where printing is executed by designating a logical print server (corresponding to the device A) that manages a plurality of physical printers from the host computer (client) (when printing is executed by the second printing method). ) Of the logical print server (device A). Also, S2501, S2602, S2503 to S2506 in FIG. 27 correspond to the steps executed by the device A, and the same steps as those in FIG. Further, S2501, S2602, and S2503 to S2506 are executed when the CPU 202 of the device A loads a program stored in the ROM 203 or the HDD 207 into the RAM 204 and executes it.

  First, when the CreateJob packet 500 as shown in FIG. 5 is transmitted from the host computer (PC 105) to the device A, the CPU 202 of the device A receives this and described in the CreateJob packet 500 in step S2501. XML data is analyzed to extract printing conditions. For example, when the printing conditions are extracted from the XML data (CreateJob packet 500) shown in FIG. 5, since “staple” is designated in the <finishing> tag 505, the host computer 105 desires staple printing. I understand that.

  Next, in step S2602, the CPU 202 of the device A performs processing as shown in S2101 to S2106 in FIG. 21 to create the device management table 1700. Then, after creating the device management table, the CPU 202 of the device A selects a device to print and issues CreateJob to the device. The processing after step S2503 is the same as that in FIG.

  In the present embodiment, the device A searches for a device after receiving CreateJob, whereby the latest device at that time can be searched from the network. In addition, the latest attribute information at that time can be acquired.

[Third Embodiment]
In the first embodiment, a configuration for creating the device management table 1700 (FIG. 17) when the power of the device A is turned on will be described. In the second embodiment, the timing when the device A receives CreateJob from the host computer. Although the configuration for creating the device management table 1700 has been described, when the device management table 1700 is created when the device A is powered on and a CreateJob specifying a highly urgent job is received from the host computer, the timing is Then, the device management table 1700 may be created again.

  With this configuration, when device A receives CreateJob specifying a highly urgent job, the latest device at that time can be searched from the network and the latest device management data can be generated. Therefore, the job can be processed by a device that can reliably process the job at that time. On the other hand, when a job other than a highly urgent job is received, device management data created in advance is used, so the load on the device A can be reduced.

  In each of the above embodiments, the device A monitors the status of the device using event reception. However, the device A uses a polling method for each device (devices B, C, and D). The status of each device may be monitored.

  In each of the above embodiments, the module having the logical print server function is operated on the device A. However, the same effect can be obtained by operating the module on a server computer such as a computer.

  Further, in each of the above-described embodiments, the print system in which the device A as a logical print server and the devices B, C, and D as physical printers are connected to the LAN 100 has been described. The present invention may be applied to a wide area print service system in which a device A as a logical print server and devices B, C, and D as physical printers are connected.

  In this case, the logical print server receives a large amount of CreateJob from user PCs in every place in the country, but the logical printer server of the present invention does not receive the print data itself. Therefore, even if a large amount of CreateJob is received, the load on the logical printer server can be reduced.

  Also, the CreateJob transmitted from the host computer may be a CreateJob specifying pull print. In this case, the print data transmitted to the physical printers such as devices B, C, and D are stored in the HDD 207 and the like in the physical printer, and printing is started when the user issues a print instruction using the operation unit 214 of the physical printer. Further, a password can be added to the print data for which pull printing is designated.

  In particular, when the present invention is applied to the above-described wide area print service system in the WAN environment, the pull print job to which the above-mentioned password is added becomes effective. Thereby, it is possible to realize a print system capable of safely acquiring highly confidential data without imposing a load on the server.

  In each of the above embodiments, whether the printer unit (printer engine) is a laser beam method or an electrophotographic method (for example, LED method) other than the laser beam method, a liquid crystal shutter method, an ink jet method, a thermal transfer method, a sublimation method. However, the present invention can be applied to other printing methods.

  Further, the configuration in which the logical print server manages a plurality of physical printers has been described, but the physical printer may be an information processing apparatus other than the printer. For example, a network scanner may be used. In this case, the CreateJob packet corresponds to an image reading job request request.

  Further, it may be a computer that performs data processing. In this case, the CreateJob packet corresponds to a data processing (for example, data analysis) request, and the server selects a computer that can execute the data processing indicated by the data processing request and relays the packet.

  Further, the configuration and contents of the various data described above are not limited to this, and it goes without saying that the various data and configurations are configured according to the application and purpose.

  Although one embodiment has been described above, the present invention can take an embodiment as, for example, a system, apparatus, method, program, or storage medium, and specifically includes a plurality of devices. The present invention may be applied to a system including a single device.

  In addition, all the structures which combined each embodiment mentioned above and its modification are also included in this invention.

  As described above, the device A as the logical print server manages the devices B, C, and D as physical printers, and selects an appropriate physical printer in response to a print request from the client PC 105. After the selection, the client print request is transferred to the physical printer, the print destination is received from the physical printer, and the response is returned to the client. Then, the client PC 105 transfers the job (print data) directly to the physical printer with respect to this print destination. With this configuration, it is not necessary to manage job data in the logical print server, and the load on the resources of the logical printer server that manages a plurality of physical printers can be reduced.

  Further, with the logical print server having such a configuration, it is not necessary to store the job from the client PC 105 in the hard disk (HDD 207), and thus an apparatus that does not include the hard disk (HDD 207) is provided as the logical print server apparatus. It becomes possible.

  Therefore, it is possible to provide a printer device having a logical print server function with reduced resource load.

  The configuration of a data processing program that can be read by each information processing apparatus (device A, device B, C, D) that constitutes the print system according to the present invention will be described below with reference to the memory map shown in FIG.

  FIG. 28 illustrates a memory map of a storage medium (recording medium) that stores various data processing programs that can be read by each information processing apparatus (device A, device B, C, D) constituting the print system according to the present invention. It is a figure to do.

  Although not particularly illustrated, information for managing a program group stored in the storage medium, for example, version information, creator, etc. is also stored, and information depending on the OS on the program reading side, for example, a program is identified and displayed. Icons may also be stored.

  Further, data depending on various programs is also managed in the directory. In addition, a program for installing various programs in the computer, and a program for decompressing when the program to be installed is compressed may be stored.

  The functions shown in FIGS. 7, 21, 23, 25, 26, and 27 in this embodiment may be performed by a host computer by a program installed from the outside. In this case, the present invention is applied even when an information group including a program is supplied to the output device from a storage medium such as a CD-ROM, a flash memory, or an FD, or from an external storage medium via a network. Is.

  As described above, a storage medium storing software program codes for realizing the functions of the above-described embodiments is supplied to the system or apparatus, and the computer (or CPU or MPU) of the system or apparatus stores the storage medium in the storage medium. It goes without saying that the object of the present invention can also be achieved by reading and executing the programmed program code.

  In this case, the program code itself read from the storage medium realizes the novel function of the present invention, and the storage medium storing the program code constitutes the present invention.

  Therefore, as long as it has the function of the program, the form of the program such as an object code, a program executed by an interpreter, or script data supplied to the OS is not limited.

  As a storage medium for supplying the program, for example, a flexible disk, hard disk, optical disk, magneto-optical disk, MO, CD-ROM, CD-R, CD-RW, magnetic tape, nonvolatile memory card, ROM, DVD, etc. Can be used.

  In this case, the program code itself read from the storage medium realizes the functions of the above-described embodiments, and the storage medium storing the program code constitutes the present invention.

  As another program supply method, a browser of a client computer is used to connect to a homepage on the Internet, and the computer program itself of the present invention or a compressed file including an automatic installation function is stored in a storage medium such as a hard disk from the homepage. It can also be supplied by downloading. It can also be realized by dividing the program code constituting the program of the present invention into a plurality of files and downloading each file from a different homepage. That is, a WWW server, an ftp server, and the like that allow a plurality of users to download a program file for realizing the functional processing of the present invention on a computer are also included in the claims of the present invention.

  In addition, the program of the present invention is encrypted, stored in a storage medium such as a CD-ROM, distributed to users, and key information for decryption is downloaded from a homepage via the Internet to users who have cleared predetermined conditions. It is also possible to execute the encrypted program by using the key information and install the program on a computer.

  Further, by executing the program code read by the computer, not only the functions of the above-described embodiments are realized, but also an OS (operating system) or the like running on the computer based on the instruction of the program code. It goes without saying that a case where the function of the above-described embodiment is realized by performing part or all of the actual processing and the processing is included.

  Further, after the program code read from the storage medium is written to a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer, the function expansion is performed based on the instruction of the program code. It goes without saying that the case where the CPU or the like provided in the board or the function expansion unit performs part or all of the actual processing and the functions of the above-described embodiments are realized by the processing.

  In addition, the present invention may be applied to a system composed of a plurality of devices or an apparatus composed of a single device. Needless to say, the present invention can be applied to a case where the present invention is achieved by supplying a program to a system or apparatus. In this case, by reading the storage medium storing the program represented by the software for achieving the present invention into the system or apparatus, the system or apparatus can enjoy the effects of the present invention. .

  The present invention is not limited to the above embodiments, and various modifications (including organic combinations of the embodiments) are possible based on the spirit of the present invention, and these are excluded from the scope of the present invention. is not.

1 is a system configuration diagram illustrating a configuration of a print system to which a logical print server (printer management apparatus) according to an embodiment of the present invention is applicable. FIG. 2 is a block diagram illustrating a schematic configuration of a printer (MFP) having a logical printer function illustrated in FIG. 1. It is a top view which shows an example of the user interface part shown in FIG. FIG. 2 is a block diagram of a module configuration that performs control around the network of the MFP device illustrated in FIG. 1. 4 is a diagram illustrating an example of packet data called “CreateJob” transmitted from a client (PC) to a printing apparatus (MFP) in the protocol of the SOAP print service over HTTP in the print system of the present embodiment. FIG. FIG. 6 is a diagram illustrating an example of response packet data (CreateJob response packet) that is returned from the printing apparatus to the client in response to the CreateJob packet illustrated in FIG. 5. 6 is a flowchart illustrating an example of a first control processing procedure in the print system of the present invention. 6 is a diagram illustrating an example of a print data transfer packet by an HTTP POST method. FIG. It is a figure which shows an example of an HTTP response packet. FIG. 6 is a diagram illustrating an example of packet data of an error response returned from the printing apparatus to the client in response to the CreateJob packet illustrated in FIG. 5. It is a schematic diagram showing a management form of a physical printer by a logical printer in the present embodiment. It is a figure which shows an example of the format of the search packet which device A shown in FIG. 11 sends out in order to search for another device. It is a figure which shows an example of the format of the response packet 1300 with respect to the search packet 1200 shown in FIG. It is a figure which shows an example of the format of the DDF file acquired from URI shown by the <loc> tag shown in FIG. It is a figure which shows an example of the format of the SDF file which is an attribute file of the device acquired from URI shown by the <SCPDURL> tag shown in FIG. It is a figure which shows an example of the format of the SDF file which is an attribute file of the device acquired from URI shown by the <SCPDURL> tag shown in FIG. FIG. 17 is a diagram illustrating an example of a device management table in which device A illustrated in FIG. 11 manages attribute information of each device acquired from the DDF and SDF illustrated in FIGS. 14 and 15 to 16. FIG. 3 is a schematic diagram schematically describing how a PC sends data to a device C via a device A as a logical printer server. FIG. 6 is a schematic diagram schematically describing how a PC sends data to a device C via a device A as a logical printer server. It is a figure which shows the internal module structure of the print service (FIG. 4) mounted in the device A shown in FIG. 6 is a flowchart illustrating an example of a second control processing procedure in the printing system of the present invention. It is a figure which shows an example of the format of the event issue request in this embodiment. 10 is a flowchart illustrating an example of a third control processing procedure in the print system of the present invention. It is a figure which shows an example of the format of the event issued by each device and received by the event receiving module of the device A in this embodiment. 10 is a flowchart illustrating an example of a fourth control processing procedure in the print system of the present invention. 10 is a flowchart illustrating an example of a fifth control processing procedure in the print system of the present invention. It is a flowchart which shows an example of the 6th control processing procedure in the printing system of this invention. It is a figure explaining the memory map of the storage medium (recording medium) which stores the various data processing program which can be read by each information processing apparatus (device A, device B, C, D) which comprises the printing system based on this invention. .

Explanation of symbols

100 LAN
101 MFP (device A)
102 MFP (device B)
103 MFP (device C)
104 MFP (device D)
105 PC (host computer)
202 CPU
203 ROM
204 RAM
205 NVRAM
207 HDD
210 Network controller

Claims (10)

A client device that transmits a job request and sends actual print data to a print destination that is returned in response to the job request, and a print destination that is sent in response to the received job request and sent to the print destination In a printer management apparatus capable of communicating with a plurality of physical printers that print processing print data,
Management means for storing and managing attribute information and status information of each physical printer;
When receiving a job request from the client device, a selection unit that selects any one of the physical printers that processes the job request based on information managed by the management unit;
Transfer means for transferring the job request to the physical printer selected by the selection means, and transferring the print destination returned from the physical printer as a response to the client device;
A printer management apparatus. The management means includes
Search means for searching for a physical printer capable of communication;
Acquisition means for acquiring device information and service information from the physical printer searched by the search means;
2. The printer management apparatus according to claim 1, further comprising event registration means for performing event registration for notifying an event when the state of the physical printer changes with respect to the physical printer by the search means.   The printer management apparatus according to claim 2, wherein the acquisition unit acquires information from the physical printer immediately after the printer management apparatus is powered on.   The printer management apparatus according to claim 2, wherein the acquisition unit acquires information from the physical printer after receiving a job request from the client apparatus.   The said management means acquires the status information of each said physical printer by regularly inquiring the status information of each said physical printer with respect to each said physical printer. The printer management apparatus according to claim 1.   The management means acquires status information of each physical printer by receiving a notification transmitted from each physical printer when the status of the physical printer changes from each physical printer. Item 5. The printer management apparatus according to any one of Items 1 to 4. A client device that transmits a job request and sends actual print data to a print destination that is returned in response to the job request, and a print that sends a print destination in response to the received job request and sends it to the print destination In a printing system in which a plurality of physical printers that print data and a printer management apparatus can communicate,
The printer management device includes:
Management means for storing and managing attribute information and status information of each physical printer;
When receiving a job request from the client device, a selection unit that selects any one of the physical printers that processes the job request based on information managed by the management unit;
Transfer means for transferring the job request to the physical printer selected by the selection means, and transferring the print destination returned from the physical printer as a response to the client device;
A printing system comprising: A client device that transmits a job request and sends actual print data to a print destination that is returned in response to the job request, and a print destination that is sent in response to the received job request and sent to the print destination In a printer management method in a printer management apparatus capable of communicating with a plurality of physical printers that print processing print data,
A management step of acquiring attribute information and status information of each physical printer and storing and managing them in a memory;
Upon receiving a job request from the client device, a selection step of selecting any one of the physical printers that processes the job request based on information stored and managed in the memory;
A transfer step of transferring the job request request to the selected physical printer and transferring a print destination returned from the physical printer to the client device as a response;
A printer management method.   A program for causing a computer to execute the steps of the printer management method according to claim 8.   A storage medium storing a computer-readable program for causing a computer to execute each step of the printer management method according to claim 8.

Images