JP2002014791A - Print system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a print system which integrates a series of pieces of information regarding a print job and provides the whole image of the integrated job for a user, with respect to a print system which is connected to a network. SOLUTION: A job history information device 40 collects job history information stored in respective modules. Arbitrary history information in the collected history information is regarded as reference history information and one of jobs constituting the reference history information is decided as a reference job. Job information on a job included in history information different from the reference history information judged to be done by the same print job as the reference job is added to job information on the reference job. After the job information is added, similar operation is carried out as to the job of other history information and this operation is carried on for jobs of all history information. After the operation is completed for the jobs of all the history information, different history information is regarded as reference history information and the same operation is carried out.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a print system in which print data transmitted from a client is received, processed, and printed by a print server or a printing apparatus via a network, and more particularly, to printing of each module. The present invention relates to a printing system that acquires and manages a job history.

[0002]

2. Description of the Related Art A printing system for transmitting data from a plurality of client devices via a network, receiving and processing data transmitted from a printing device or a print server connected to the network, and performing printing is put into practical use. Have been.

In the above-described printing system, as a method of acquiring a “print job history”, for example, a technique in which information of a job generated by a print driver on a client is stored as data by the print driver itself, a print job serviced by a print server There is known a technology in which the print server itself stores the information of the print server, and a technology in which the print device itself stores the information of the job printed by the print device.

As such a prior art, Japanese Patent Laid-Open No.
Japanese Patent Publication No. 283131 proposes a technique in which print history information is stored in a storage medium in a printer, and the stored print history information is displayed to a user by printing or transmitting the print history information to a host computer.

[0005]

Originally, a print job is
The job starts from a job generation location “client”, passes through a print server or the like, finally reaches a printing device, print data is printed, and the process is completed.

However, in the above-described prior art, each print driver, print server, and printing apparatus need only store print job information that can be collected at that point (location) at only one point in the passing path. Had been.

For example, since the print driver exists on the client which is the starting point of the job, information on the "starting point of the job" such as the name of the user who has requested the job and the name of the application which has performed printing can be collected in detail. However, it is not possible to store information relating to the “end point of the job”, such as the number of final output sheets, or information relating to the print value-added job scheduling scheduled to be performed by the print server.

The print server can collect in detail the information serviced by the print server, such as job scheduling on the print server, distributed printing, output to another printing device by avoiding a malfunctioning printing device, and the like. . However, the print server cannot store information on the job start point and end point.

Further, the printing apparatus can collect information about the end point of the job, such as the number of sheets actually output, but cannot store information on the start point of the requester or the like and the value-added print information by the server.

A print job passes through a service point from a start point and reaches an end point. However, print job information that can be obtained at each point between the print points is different, and job history information generated by the prior art is: There is a problem that the information is biased to any one point of job information on this path.

The job history is used for various purposes such as charging and load analysis. The required job information differs depending on the application, and in some cases, all information on the job path may be required. The above-described problems sometimes make it inconvenient to use job information.

SUMMARY OF THE INVENTION The present invention has been made in view of the above-mentioned problems, and integrates a series of information relating to a print job.
It is an object of the present invention to provide a printing system that provides a user with an integrated image of a job.

It is still another object of the present invention to provide a system in which each subsystem in a printing system acquires identification information given from the generation to the disappearance of one print job. It is another object of the present invention to provide a method for recognizing a timing of closing information when the number of job information fragments does not increase.

[0014]

In order to achieve the above object, according to the first aspect of the present invention, a printing apparatus driving unit transmits print data generated by a print data generating unit of a client on a network via a network. A printing system that performs a print job in which the transmitted print data is printed by a printing device, and a printing system to which a printing management device is connected. A first storage unit that stores and saves driver history information indicating that the printing apparatus has performed the printing operation, and the printing apparatus stores and saves printing apparatus history information indicating what processing the printing apparatus performed in the print job. 2
Reading means for reading out the driver history information stored in the first storage means and the printing apparatus history information stored in the second storage means, and data stored in the print management apparatus. And a display means for displaying

According to a second aspect of the present invention, in the first aspect of the present invention, the printing management apparatus stores and saves the driver history information and the printing apparatus history information read by the reading unit. It is characterized by further comprising storage means.

According to a third aspect of the present invention, in the first or second aspect of the invention, the print management device is included in any one of the driver history information and the printing device history information read by the reading unit. The reference job determining means for selecting the processing indicated by any one of the data to be determined and determining the reference processing, and the processing indicated by the data different from the reference processing determined by the reference job determining means are identical. Determining means for determining whether or not the job is performed in a job; data adding means for adding data indicating a process different from the data indicating the reference process to data indicating the reference process; When the determination unit determines that the process indicated by another data is performed in the same print job, the process is added by the data addition unit.

According to a fourth aspect of the present invention, in the third aspect of the present invention, the data indicating another process added by the adding means is stored in the driver history information stored before the data is added by the adding means. And first deletion means for deleting from any one of the printing apparatus history information.

According to a fifth aspect of the present invention, in the third or fourth aspect of the invention, the print data generating unit is common on a network and in a terminal connected to the network, and is distinguished by each print job. And an identification information embedding unit for embedding the identification information into the print data, and a criterion of the judgment by the judging unit is based on the identification information embedded by the identification information embedding unit.

The invention according to claim 6 is the invention according to claims 1 to 5
In the invention described in any one of the above, the print management device deletes an information item that is one element constituting one piece of information included in any one of the driver history information and the printing device history information. If the information item of the driver history information and the information item of the printing device history information match when determined by the determining device, the information item of the driver history information and the information item of the printing device history information Is deleted by the second deletion unit.

According to a seventh aspect of the present invention, in the first aspect, a server is further connected to the network, and the server stores server history information indicating what processing the server performed in the print job. And a fourth storage unit for storing the server history information stored in the fourth storage unit.

According to an eighth aspect of the present invention, in the second aspect, a server is further connected to the network, and the third storage unit further stores server history information.

According to a ninth aspect of the present invention, in the third or fifth aspect, a server is further connected to the network, and an object selected by the reference job determining means is an arbitrary one included in the server history information. It is characterized in that the processing indicated by the two data is also included.

According to a tenth aspect of the present invention, in the fourth aspect of the present invention, a server is further connected to the network, and the deletion target of the first deletion means includes server history information. I do.

According to an eleventh aspect of the present invention, in the sixth aspect of the present invention, a server is further connected to the network, and an object to be deleted by the second deletion means is one data included in the server history information. It is characterized in that an information item which is one of the constituent elements is also included.

According to a twelfth aspect of the invention, there is provided a printing system comprising:
A printing system having a plurality of subsystems, the printing system comprising: a job identifier identifying each print job performed by the printing system; and a key used to search for the job identifier within a predetermined range of the printing system. The plurality of subsystems search for an identifier by a key, and a fragment job that is a job performed in each of the plurality of subsystems in a print job is identified by the identifier. It is characterized by being put together.

According to a thirteenth aspect of the present invention, in the printing system of the twelfth aspect, the job ID list holding unit further includes an identifier discarding unit for discarding the job identifier, and a discarding time determining unit for determining a discarding time. However, the timing of discarding is determined by notifications from a plurality of subsystems.

According to a fourteenth aspect of the present invention, in the printing system according to the twelfth or thirteenth aspect, the plurality of subsystems notify the job ID list holding unit of the start and end of the fragment job in the subsystem. The subsystem is further characterized in that the subsystem combines the fragmented jobs after the job start / end notifying unit notifies the end of the fragmented job.

[0028]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of a printing system according to the present invention will be described below in detail with reference to the accompanying drawings. Figure 1
10 to 10 show an embodiment of the printing system according to the present invention.

[First Embodiment] FIG. 1 shows a first embodiment of a printing system according to the present invention. As shown in FIG.
In this embodiment, a client 10, a server PC 20, a printing device 30, and a job information history device 40 are connected via a network.

The flow of a general print job will be described below. First, the application 11 instructs generation of print data, and the driver 12 generates print data. The generated print data is transmitted to the server PC by the server communication 13.
It is transmitted to 20 additional services 21. Additional service 2
1 provides additional services such as distributed printing and abnormal printer avoidance, and print data is printed by the printing device 30.

In the above-described print job, a history of executed jobs is accumulated in each of the driver 12, the server communication 13, the additional service 21, and the printing device 30. However, only the history information stored in each of the modules (the driver 12, the server communication 13, etc.) described above is used as follows so that the operation performed by each module can be grasped in the overall flow of a series of print jobs. To do. Here, in the present embodiment, as shown in FIG. 1, a job information history device 40 that integrates and manages history information stored by each module is connected to a network.

In the following, based on FIG. 4, the job information history device 40 collects history information of each module, and creates information indicating a flow of a series of print jobs.

The job information history device 40 collects job history information generated by each module as shown in FIG. 2 (step S1). One of the plurality of collected job history information is selected, and the selected history information is set as reference history information (step S2). Scan all the job information included in the reference history information (step S
3). An arbitrary one of the scanned jobs is set as a reference job (step S4), and histories stored in other modules of the print job in which the job has been performed are collected.

One piece of arbitrary history information to be merged is extracted (step S5). A job determined to have been performed when printing the same print data as the reference job is extracted from the remaining history information (step S6), and added to the job information of the reference job (step S7). In the present embodiment, the criterion for determination is based on the date and time when printing was performed and the size of the print data.

The extracted job information is deleted from the history information (step S8). If all the information of the print job is not merged with the added job information (step S8).
9 / No), and fetch another piece of history information (Step S)
5). If all pieces of history information are merged (step S9 / Yes), all the acquired job information is integrated as job information of one print job and added to the integrated history information that has been integrated earlier. (Step S1
0).

If all the jobs in the reference history information are not reference jobs (step S11 / No), another arbitrary job is set as a reference job (step S4).
If all the jobs in the reference history information are the reference jobs (step S11 / Yes) and the collected history information is the reference history information (step S12 /
Yes), the process ends. If the collected history information is not all reference history information (step S12 / N
o), another piece of history information becomes reference history information (step S)
2).

As described above, by integrating the job information stored in each module for one print job, if the user obtains the result by, for example, printing the result, the user can use the conventional method. In comparison, it is easier to obtain overall information for each print job.

In this embodiment, when integrating the history information generated by each module, the job information history device 40 determines that a job determined to have been performed in the same print job as a reference job in certain reference history information A criterion is used when acquiring information from among the remaining pieces of history information. This criterion is determined based on a match between the date and time when the print job was performed and the size.

[Second Embodiment] A second embodiment will be described below. In this embodiment, in the first embodiment, when a print job of the same size is performed at the same date and time when the print job is determined based on the above-described determination criterion, it is a job of another print process. An example of avoidance in a case where there is a possibility that the print job is determined to be the same even if the print job is determined. Hereinafter, a method of embedding “JOBID = identification information” in print control information such as PJL will be described as a second embodiment. FIG. 5 is an overall configuration diagram showing the contents of the history information stored in each module.

In this embodiment, a module such as the driver 12, which is a starting point of a print job, embeds job identification information in print data. It is assumed that this identification information can be identified as the print job in the entire system or network. As a method of embedding identification information, as described above, “J” is included in print control information such as PJL.
The method of adding “OBID = identification information” is selected.

The process of embedding the identification information in the job data at the start point of the job of the driver 12 or the like in the present embodiment will be described below with reference to the flowchart shown in FIG. From applications and systems,
The start of a print request and the generation of print data are requested (step S11).

Print data and job identification information are generated (step S12), and the generated print data and job identification information are set as a set and stored in history information (step S12).
13), embedding job identification information in job data,
Then, it sends to a printing process (an additional service etc.) (step S14).

Hereinafter, processing at points other than the job start point in this embodiment will be described with reference to the flowchart shown in FIG. The job data transmitted from the process before the module is received (step S21), and general processing of each module is performed according to the job data (the server service for the additional service 21 and the paper output for the printing apparatus 30) (step S22).

The job identification information in the job data is extracted, and the job identification information and other information (processing result information, job information, etc.) are set and stored in the history information (step S23). FIG. 6 shows the job history information stored by each module.

When integrating the job history information groups stored by each module, the flow of the basic integration process is the same as that of the first embodiment. In the first embodiment, when a job performed in the same print job as the reference job is searched from other pieces of history information, a match between date and time and size is used as a criterion. In the present embodiment, the search is executed based on the matching of the identification information of each job.

Regarding the generation of job identification information capable of specifying a print job in the entire system, a method using the network address of the client 10 is conceivable.
Since the network node on the system is specified by using the network address, the network address of the client or a value based on the network address is used in the first half of the identification information.

In the latter half of the identification information, a unique value is added in the network node (specifically, the client 10). For example, the unique value may be time information on the millisecond or microsecond level, or an increment counter. Furthermore, some “unique value generation schemes” (UU
ID, etc.).

If the module that generates print data such as the driver 12 has a system configuration in which job identification information cannot be embedded, a subsequent process module identifies the print data sent from the previous process module later. A method of adding information is employed.

In some cases, the identification information cannot be embedded depending on the format of the print data. In such a case, the identification information may be transmitted through a communication unit that transfers the print data from the previous process to the subsequent process. That is, instead of embedding the identification information in the print data, the job identification information may be transmitted via a data transfer unit such as a packet header or a command argument.

Also, depending on the communication means, when the receiving side adds identification information instead of transmitting the job,
The preceding process (the side transmitting the job) may receive the identification information from the subsequent process (the side receiving the job) and may add the identification information to the history information.

As shown in the above-described embodiment, when the print job information is integrated by newly embedding the identification information into the print job, the same print job There is no possibility that the job is determined to have been performed. As a result, the user can grasp more accurate job information.

[Third Embodiment] Hereinafter, in the first embodiment, information such as a document name (job name), requester information, and billing information that is expected to remain unchanged from the start of the job until the job is completed. A third embodiment describes a method of merging overlapping information into one and integrating the information in a case where appears in a plurality of pieces of history information of the same print job. FIG. 8 shows an overall configuration diagram in the third embodiment. FIG. 8 also shows the contents of the history information stored by each module.

The operation of this embodiment will be described below with reference to the flowchart shown in FIG. The following operation is performed between S6 and S7 in the flowchart shown in FIG. First, all the item identifiers of the information items are obtained from the reference job (step S31). In the job to be integrated extracted in step S6, the job that overlaps with the item identifier acquired in S31 is deleted (step S3).
2).

In the third embodiment, as an example, it is assumed that job information is composed of four items: job identification information, date, user name, and number of bytes. These four pieces of information are considered to be individual components expressing job information, and these components are composed of a set of “type and value” as described below.

For example, when the job information is composed of the above four elements, one job information is "".
jobid = 1234 """date = 06/01""" us
er = asaya "" and "size = 180"".

Each piece of history information is a list of job histories in each module. Each job information includes not only its value but also item identification information. The item identification information means the type of the information element. Specifically, the item identification information is the date and time information in the case of the information indicating the date and time, and is the type of the byte number information in the case of the information indicating the byte number.

If the history information is CSV (comma separated valu)
e) In the case of data in the format, jobid, date, user 1234, 06/01, Asaya 1235, 06/01, Inoue, etc. The first line shows what type of data is arranged in which order. There is a method in which a line is provided for identification.

Alternatively, the history information is stored in XML (extensible m
There is also a method in which each information element is described with a different tag name in a tagging format such as arkup language). When the history information is binary data, there is a method in which each information element is stored not only in its value but also in a column of “type, value”.

Each module that generates history information identifies information elements having the same meaning with the same information identifier. For example, the information element “job identification information” has the same meaning even if collected at any point from the start to the end of the job path, since the information element is performed in the same print job.

In some systems, the job name and the requester of the job have the same meaning from the start to the end of the job. For the information elements as described above, all the log information storage modules use the same information element identifier such as jobid, jobname or user.

In the case of integrating the history information typed as described above, it is possible to combine the same information elements into one. FIG. 10 shows the flow of the processing. Hereinafter, the grouping process will be described with reference to FIG.

In the first embodiment, when adding information of a job determined to have been performed by the same print job in different history information to the reference job, the information is not simply added but included in the reference job information. One information element that already exists is listed. Then, for each existing information element, an information element having an information element identifier is searched, and if there is a matching information element, it is deleted. Only the remaining information elements are added to the reference job information.

In this embodiment, when there is an overlapping information element in two pieces of job information, the value of the reference job information is prioritized. However, the value of the reference job information may be overwritten with the value of the job information to be integrated.
Also, by comparing both values, if they do not match, the user can select one value, and if they do not match, the user can specify in advance which value to select. Adopt the method.

As described above, when information of a job performed in the same print job existing in a plurality of pieces of history information is integrated, overlapping information elements are detected and merged, so that the integrated information is obtained. The job history information is simplified without losing the information, and is easy to see when the user browses the data.

[Fourth Embodiment] In the above description of the job identification information, it has been described that the identification information is always embedded in the information fragment of the print job. However, depending on the data format of the job, it may not be possible to embed it. . Some subsystems that supply job information fragments include:
Sometimes the contents of the job data cannot be seen.

The job transport means between the subsystems may not embed the job data, and some subsystems for supplying the job information fragments may not be involved in transporting the job.

Hereinafter, a process for obtaining an identifier using a key will be described with reference to a configuration diagram of a printing system applied as an embodiment of the present invention in FIG. The subsystem that has assigned a job identifier registers a pair of the identifier and a key that can search for the job in the job ID list holding unit. On the other hand, the subsystem that supplies the job information fragment passes a key capable of searching for the job to the job ID list holding unit and receives a corresponding identifier.

The difference between the "key for retrieving a job" and the "identifier for identifying a job" will be described below. First, the "identifier for identifying a job" is a type that uniquely identifies a job in the entire system during the time from generation to disappearance of the job.

In general, in a printing system, a job is generated on, for example, a client PC, passes through various modules on the PC, and eventually the job leaves the PC and
It is passed to the print server, passes through various modules in the server PC, and then leaves the server PC and is passed to the printing device.

On the other hand, a key is a value that can identify a job within a context whose range is limited. For example, Clie
If the OS assigns a number to the nt PC, that is, assigns a job ID to the PC, the job can be identified. However, this value cannot be used for job identification outside the Client PC, such as a print server or a printing device. Also, depending on the OS, job identification may not be possible just by restarting. In this case, Client
The ID on which the OS gives a number on the PC is the key.

The job ID list holding unit uses this Client PC
When operating on the above, the job ID list holding unit holds a pair of a key, which is an ID numbered by the OS, and a job identifier. Various modules that supply job information on the Client PC (for example, print applications, printer drivers, port drivers, print processors, etc.)
Can obtain a valid job identifier for the entire system from the job ID of the OS.

Hereinafter, an example in which a job is transported between subsystems will be described. For example, in some network printing protocols, a job receiving side (such as a print server) passes an ID received when receiving a job to a job sending side (such as a print client).

In this case, the job receiving side has the authority to determine what value to use as the ID. Originally, if an identifier is generated when a job is generated and the job cannot be identified from the same point in time as the generation of the job, subsystems involved in the initial stage of generation of the job cannot generate job information (can be generated). Cannot be embedded.)

Some job receivers return a value that allows a job to be identified only by the job receiver, that is, a value that cannot be identified by other subsystems. Also,
The data format of the job ID returned by the job receiving side may be determined depending on the print protocol. In this case, it is not possible to embed common information for identifying a job in the entire system.

Therefore, an identifier that can identify a job in the entire system is separately numbered. For example, a number may be assigned when a job is generated. In this example, the key is an ID generated by the print server or the like.

In this case, “Subsystem A such as Client
And the job transfer between the subsystem B such as a server, and the like.
D is useful. Therefore, the job ID list holding unit is raised in response to the transmission and reception during this time, and the job identifier inherited from the upstream of the job flow can be searched using the effective ID as a key between the two sides of the job sending side and the receiving side. .

As described above, the job ID value introduced by the existing technology is a value that is useful in a limited context, such as within the OS range in the Client PC or in job transfer communication between two parties. Since there are many such IDs in the existing technology, they are used as "keys" in the context.
From the key, an identifier that can identify the job in the entire system is searched.

In the present example, “the job ID list holding unit is placed in the Clean PC, and the job identifier can be searched for in each module in the Clean PC”. An ID list holding unit is provided to enable a job identifier search between the two parties. " This example is a model in which a job ID list holding unit is placed in each context.

However, as another method, the job ID list holding unit may be placed outside each context so that it can be used in the entire system. For this purpose, for example, instead of an array of [key-identifier] pairs, [key of context-A, key of context-B, cont
ext-C key-identifier], a key for each context may be associated with one job identifier.

The processing performed by the job generating subsystem and the job receiving / monitoring subsystem will be described below with reference to FIGS. 12 (a) and 12 (b). First, a process in which the job generating subsystem stores a key / identifier pair in the job ID list storage unit will be described.

A job identifier is generated (step S4)
1) and a key that can specify the job by another method if it is within a limited context (step S42). The job ID and the key are notified to the job ID list holding unit (step S43). The job ID list holding unit stores the pair of the key and the identifier (step S44), and the process ends.

Next, a process in which the job receiving / monitoring subsystem returns an identifier matching the key will be described. When the job information is acquired (step S51), a key that can specify the job by another method within a limited context is determined (step S52).

The key is sent to the job ID list holding unit, and a corresponding identifier is requested (step S53). Job ID
The list holding unit searches the ID list and returns an identifier that matches the key (step S54). Hereinafter, the process of recognizing the erasing time will be described.

The list of job identifiers is held by each subsystem. Each subsystem stores only a necessary job identifier in the process of processing the job, and an unnecessary identifier is generated when the transmission of the job information is completed. This identifier may be discarded at an appropriate timing of the subsystem itself.

As means for the ID notifying unit to notify the information of [key]-[identifier] to each subsystem, there is a method in which a subsystem requiring such information registers itself as a notification destination in advance. Or on a network
There is also a method such as broadcast / multicast, in which information is passed to an unspecified number of people by predetermined means, and each subsystem picks up as much as necessary.

The process of assigning an identifier number (numbering process) will be described below with reference to FIGS. 15 (a) and 15 (b). First, this processing will be described based on (a).

A module for assigning a job identifier number, such as an application or a driver, assigns an identifier and a key to an ID.
The information is passed to the notification unit (step S61). The ID notifying unit notifies each subsystem of the key and the identifier (Step S).
62). Each subsystem that receives the key and the identifier
This is held by itself (step S63), and the process ends.

Next, the processing at the time of generating job information by the subsystem will be described based on (b). Based on the key of the target job, the corresponding identifier is extracted from its own table (step S71). The information of the job is transmitted, and [key]-[identifier] of the job is deleted from its own table (step S72).

Hereinafter, a description will be given of a method in which the job history holding unit determines the reception standby time of information fragments in arbitrary job information. Here, the subsystems on the path through which the job passes supply job information fragments to the job history holding unit at various timings.

FIG. 16 shows a configuration diagram of a printing system applied as an embodiment of the present invention. Each subsystem sends a notification indicating the start to the job history holding unit α when the job is transported to itself. At this time, not only this notification but also a job information fragment relating to the start may be sent together.

After performing the job processing, the subsystem conveys the job to the subsystem of the next process. After starting the job processing, the subsystem sends a Start notification to the job history information holding unit. After the transfer of the job is completed, the subsystem in the preceding process sends a notification indicating that the job information fragment is not sent. Note that, similarly to the above, the job information fragment relating to the end of the job processing of the own device may be sent together.

Similarly, the subsystem in the next process performs the job processing and then sends the job to the next process, and sends an end notification (and a job information fragment if necessary) to the job history holding unit. Some subsystems perform monitoring from outside the job path without intervening in the job flow. In this example, it is assumed that there is a subsystem that monitors the printing apparatus.

When the subsystem detects that a job has been generated (or received) at a point monitored by itself, it sends a Start notification and a supplementary job information fragment to the job history holding unit in the same manner as described above. When the job disappears at that point, an end notification and a supplementary job information fragment are sent to the job history holding unit.

On the other hand, the job history holding unit has a Start-End
And job information fragments attached thereto. If an End notification is received from one subsystem for a given job, but only a Start notification is received from another subsystem, this job survives on the system and information fragments will continue to be sent in the future. Could be In that case, the job is still open.

When the End notification for the job is received from all the subsystems that have sent Start, it is determined that the information fragment for the job cannot be further collected on the system, the information of the job is closed, and the information of the job is closed. Merge fragments. In this way, even when various subsystems on the system supply job information fragments at various timings, it is possible to obtain accurate timing for putting together information fragments.

FIG. 17 shows the flow of the above processing. First, when the job is transported to Subsystem A, a notification indicating the start is sent to the job history holding unit, and the job processing is started. When the job processing is completed, the job is transported to Subsystem B which is a subsystem of the next process.

When the transfer is completed, a notification indicating the end is sent to the job history holding unit. On the other hand, the Su
bsystem B sends a notification indicating the start to the job history holding unit, and starts processing the conveyed job.

Similarly, when the processing is completed, the job is conveyed to the printing apparatus which is a subsystem of the next process. When the conveyance is completed, a notification indicating the end is sent to the job history holding unit. On the other hand, in the printing device to which the job has been transported, when the transport is completed, the printing process is performed and the process is terminated.

Also, a Subsys that does not participate in the job flow
In tem X, when the transfer of the job from Subsystem B to the printing apparatus starts, a notification indicating the start is sent to the job history holding unit. When all the processes in the above system are completed, a notification indicating the end is held in the job history. To the department.

[0100]

As is apparent from the above description, according to the present invention, the job information stored in each module is integrated for each print job, and the result is printed. If the user can easily obtain the information, it becomes easier for the user to obtain the overall information on each print job as compared with the related art.

Further, by embedding the identification information in the print job, the print job information can be integrated.
Since there is no possibility that a job performed in a different print job is determined as a job performed in the same print job, the user can grasp more accurate job information.

Further, when information of jobs performed in the same print job that exist in a plurality of pieces of history information is integrated,
By detecting and merging overlapping information elements, the integrated job history information is simplified without losing the information, and becomes easier to view when the user browses the data.

According to the twelfth aspect of the present invention, even if the job identifier cannot be read directly, the job identifier can be retrieved and read, so that the identifier can be read reliably, and the print job can be read more accurately. It becomes possible to put together.

According to the thirteenth aspect, according to the first aspect,
According to the second aspect of the invention, the identifier that is no longer needed in the job history holding unit can be discarded, so that the job history holding unit can more efficiently use the storage area of the identifier.

According to the invention set forth in claim 14, claim 1 is
In the invention described in 2 or 13, since the subsystem can grasp the timing of combining the jobs, each subsystem can combine the jobs at an appropriate timing for combining the jobs.

[Brief description of the drawings]

FIG. 1 is an overall configuration diagram of a first embodiment according to a printing system of the present invention.

FIG. 2 shows an example of the contents of history information 12a stored in a driver 12, history information 21a stored in an additional service 21, and history information 30a stored in a printing apparatus 30.

FIG. 3 shows contents of a program for executing a processing operation in the first embodiment.

FIG. 4 is a flowchart showing an operation in the first embodiment.

FIG. 5 is an overall configuration diagram of a second embodiment according to the printing system of the present invention.

FIG. 6 shows an example of history information stored by each module in the second embodiment.

FIG. 7 is a flowchart showing the operation of each module in the second embodiment.

FIG. 8 is an overall configuration diagram of a printing system according to a third embodiment of the present invention.

FIG. 9 shows a program for executing a processing operation in the third embodiment.

FIG. 10 is a flowchart showing an operation in the third embodiment.

FIG. 11 is a configuration diagram of a printing system applied as an embodiment of the present invention.

FIG. 12 is a flowchart illustrating a process in which a subsystem on the job generating side stores a key and an identifier, and a process in which the subsystem on the job receiving / monitoring side searches for an identifier from a key.

FIG. 13 is a diagram illustrating a basic model of a print job, embedding in job data, and ID notification by a job transport unit.

FIG. 14 is a configuration diagram of a printing system applied as an embodiment of the present invention.

FIG. 15 is a flowchart illustrating a process of assigning an identifier number and a process performed by a subsystem when generating job information.

FIG. 16 is a configuration diagram of a printing system applied as an embodiment of the present invention.

FIG. 17 is a flowchart illustrating the start and end of a job by each subsystem in a job history holding unit.

[Description of Signs] 10 Client 11 Application 12 Driver 12a History information saved in driver 12b History information saved in driver 12c History information saved in driver 13 Server communication 13a History information saved in server communication 13b Server communication 13c History information stored in server communication 20 Server PC 21 Additional service 21a History information stored in additional service 21b History information stored in additional service 21c History information stored in additional service 30 Printing Apparatus 30a History information stored in printing apparatus 30b History information stored in printing apparatus 30c History information stored in printing apparatus 40 Job information history apparatus 40a History information stored in job information history apparatus 40b Job information history apparatus History information A subsystem B Subsystem C Subsystem X subsystem that is stored in the history information 40c job information history unit that is exist

Claims (14)

[Claims] 1. A printing system in which a print data generation unit of a client on a network transmits and prints print data via the network, wherein the printing device driving unit stores first driver history information. The printing apparatus has second storage means for storing printing apparatus history information performed by the printing apparatus, and the printing management apparatus includes driver history information stored in the first storage means, A printing system comprising: means for reading printing device history information stored in a second storage means; and transfer means for transferring owned data to the client. 2. The print management apparatus according to claim 1, further comprising a third storage unit configured to store the driver history information and the printing device history information read by the reading unit. The printing system as described. 3. A reference job determination unit that selects a process indicated by data included in one of the read driver history information and the print device history information and determines a process, wherein the print management device includes: Determining means for determining whether or not processing indicated by data different from the reference processing determined by the reference job determining means is performed in the same print job; and data different from the data indicating the reference processing. Data adding means for adding data indicating the processing of the reference to data indicating the processing of the reference, wherein processing indicated by data different from the processing of the reference is performed in the print job by the determining means The printing system according to claim 1, wherein when the determination is made, the data is added by the data adding unit. 4. Deleting any one of the driver history information and the printing device history information stored before adding the data indicating another processing added by the adding unit by the adding unit. The printing system according to claim 3, further comprising a first deletion unit that performs the deletion. 5. The print data generation unit includes an identification information incorporation unit that incorporates identification information that is common on the network and in a terminal connected to the network and that is identified by each of the print jobs into the print data. The printing system according to claim 3, wherein a criterion of the determination by the determination unit is based on identification information incorporated by the identification information incorporating unit. 6. The print management device according to claim 2, wherein the print management device deletes an information item that is one element constituting one piece of information included in one of the driver history information and the printing device history information. When the information item of the driver history information and the information item of the printing device history information match at the time of the determination by the determining unit, the information item of the driver history information and the information item of the printing device history information 6. The printing system according to claim 1, wherein one of the information items is deleted by the second deletion unit. 7. A server is further connected to the network, and the server has fourth storage means for storing and storing server history information indicating what kind of processing the server performed in the print job. 2. The printing system according to claim 1, wherein the reading unit further reads server history information stored in the fourth storage unit. 8. The printing system according to claim 2, wherein a server is further connected to the network, and the third storage unit further stores the server history information. 9. The server according to claim 1, wherein a server is further connected to the network, and a selection target of the reference job determination unit includes a process indicated by arbitrary one data included in the server history information. Item 6. The printing system according to item 3 or 5. 10. The printing system according to claim 4, wherein a server is further connected to the network, and the server history information is included in a deletion target of the first deletion unit. 11. A server is further connected to the network, and one of data to be deleted by the second deletion unit is included in the server history information.
The printing system according to claim 6, further comprising an information item that is one of the elements. 12. A printing system having a plurality of subsystems, wherein the printing system uses a job identifier for identifying each print job and a search for the job identifier within a predetermined range of the printing system. The plurality of subsystems retrieves the identifier using the key, and uses the identifier to execute a row in each of the plurality of subsystems in the print job. A printing system characterized by combining fragmented jobs, which are jobs to be executed. 13. The job ID list holding unit further includes: identifier discarding means for discarding the job identifier; and discarding time determining means for determining the discarding time. 13. The printing system according to claim 12, wherein the printing system is determined by a system notification. 14. The plurality of subsystems further include a job start / end notification unit for notifying the job ID list holding unit of the start and end of the fragment job in the subsystem, and the subsystem includes: 14. The printing system according to claim 12, wherein the job start / end notification unit notifies the end of the fragment job, and then combines the fragment jobs.