WO2008034873A2 - Verfahren und system zum automatischen übertragen von druckdaten und insbesondere zum spiegeln von druckaufträgen - Google Patents

Verfahren und system zum automatischen übertragen von druckdaten und insbesondere zum spiegeln von druckaufträgen Download PDF

Info

Publication number
WO2008034873A2
WO2008034873A2 PCT/EP2007/059958 EP2007059958W WO2008034873A2 WO 2008034873 A2 WO2008034873 A2 WO 2008034873A2 EP 2007059958 W EP2007059958 W EP 2007059958W WO 2008034873 A2 WO2008034873 A2 WO 2008034873A2
Authority
WO
WIPO (PCT)
Prior art keywords
print
data
mirror
job
print data
Prior art date
Application number
PCT/EP2007/059958
Other languages
English (en)
French (fr)
Other versions
WO2008034873A3 (de
Inventor
Herman Lankreijer
Albin Stoderschnig
Olaf DÜNGER
Original Assignee
OCé PRINTING SYSTEMS GMBH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from DE200610044870 external-priority patent/DE102006044870B3/de
Priority claimed from DE200710010277 external-priority patent/DE102007010277B4/de
Application filed by OCé PRINTING SYSTEMS GMBH filed Critical OCé PRINTING SYSTEMS GMBH
Priority to EP07820398A priority Critical patent/EP2078241A2/de
Priority to JP2009528725A priority patent/JP4861480B2/ja
Priority to US12/441,551 priority patent/US8373872B2/en
Publication of WO2008034873A2 publication Critical patent/WO2008034873A2/de
Publication of WO2008034873A3 publication Critical patent/WO2008034873A3/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1278—Dedicated interfaces to print systems specifically adapted to adopt a particular infrastructure
    • G06F3/1285—Remote printer device, e.g. being remote from client or server
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G06F21/608—Secure printing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1202—Dedicated interfaces to print systems specifically adapted to achieve a particular effect
    • G06F3/121—Facilitating exception or error detection and recovery, e.g. fault, media or consumables depleted
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1202—Dedicated interfaces to print systems specifically adapted to achieve a particular effect
    • G06F3/1222—Increasing security of the print job
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1223—Dedicated interfaces to print systems specifically adapted to use a particular technique
    • G06F3/1229—Printer resources management or printer maintenance, e.g. device status, power levels
    • G06F3/1234—Errors handling and recovery, e.g. reprinting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1223—Dedicated interfaces to print systems specifically adapted to use a particular technique
    • G06F3/1237—Print job management
    • G06F3/1238—Secure printing, e.g. user identification, user rights for device usage, unallowed content, blanking portions or fields of a page, releasing held jobs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1443—Transmit or communication errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2058—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring using more than 2 mirrored copies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2071—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring using a plurality of controllers
    • G06F11/2076—Synchronous techniques

Definitions

  • the present invention relates to a method and apparatus for receiving print data by a receiver from a transmitter, and more particularly to mirroring print jobs.
  • the invention is intended for high-performance electrophotographic printer printing environments.
  • print servers are usually print servers. Such print servers are described in the book Digital Printing Technique and Printing Technologies of oce Drucksysteme, 9th Edition, February 2005 (ISBN 3-00-001019-X) in Chapter 15. These print servers are called oce PRISMAproduction Server. Among other things, they provide communication between mainframes
  • Such a print server can receive print data streams of various different mainframes in different formats and forward them to a large number of other printing devices.
  • the transmission of the data can take place via different networks according to different protocols.
  • IBM To transfer the data from a mainframe to a print server, IBM often uses the IBM Download Services protocol, which is a separately orderable feature of the IBM Print Services Facility (PSF) for the OS / 390 operating system used on mainframes over a TCP / IP network
  • PSF IBM Print Services Facility
  • Print center operators experience considerable problems if they lose print data due to a computer breakdown or if the print data are damaged to such an extent that they are no longer usable. If the correct reception has been acknowledged by the sender, then this clears the print data and they are no longer available for retransmission.
  • the download protocol is provided with a function with which the print data can be transmitted simultaneously to several recipients. This is used to send the print data to a print server and mirror -
  • Mainframe computer or on its mirror computer systems the print data are held until the complete printout is completed. For this, a feedback to the mainframe computer would have to be sent over the entire production chain after the printout has been completed, so that the print data can be deleted again. Such feedback means a considerable communication effort.
  • Mainframes send their print data to different print servers, which in turn control a large number of different printers. All the different print servers and printers would have to be set up for such feedback. Since known protocols for transmitting print data between mainframe computers and print servers do not provide for such feedback, this is virtually impossible.
  • Print server to be transmitted The individual print servers often have similar names, so that a wrong print server is entered as the destination in case of a typo or wrong selection from a menu list.
  • misaddressing does not occur frequently, once it does occur, it causes considerable damage in high-performance printing, since a printed product printed on the wrong printing device is mostly unusable.
  • this printing device often does not have the correct resources and form definitions, so the print data is printed incorrectly.
  • a misprinted print job can cause significant financial damage. So far, an attempt is made
  • firewall programs which decide on the basis of parameters contained in the header of the network protocol used, whether the print data is delivered correctly.
  • the headers of the network protocols such as TCP / IP, however, contain only basic parameters such as the address of the sender and the recipient. Is a specific one If the transmitter is activated at a certain receiver, the firewall programs allow the reception of all data from this transmitter.
  • transmitter and receiver e.g., a sender should transmit a particular type of print job to a particular recipient and submit another type of print job to another recipient.
  • Each print job is accompanied by a separate file containing not only the address data of the send computer and the receive computer, but also several parameters to the user. There is also a parameter for the pressure device listed herein.
  • the disadvantage of this system is that the parameters to be monitored are stored in a separate file. If a hacker intercepts and copies this file, he can trigger a print job at any time on a print server. It can also inject files into the print server that pose a security risk.
  • the Oce PRISMAproduction server system includes a PrintJob Manager PJM (see chapters 15.2.4 and 18.2) that creates print jobs on any client client and in this one ServerSystem be edited and managed.
  • the PrintJob Manager is also referred to as a print job manager.
  • Patent Application DE 10 2007 009 737 is incorporated by reference in its entirety and is incorporated in the present patent application.
  • Job-related data of a print job containing control parameters for controlling the print job. This method is used in a printing system with a print job manager, one or more clients on which print jobs are generated, and a print job
  • Print server for feeding the print jobs to a printing device and includes the following steps:
  • This method is characterized in that the checking of the order-related data according to the predetermined ticket rules is performed centrally on the print job manager.
  • the order-related data is checked and / or checked centrally and preferably exclusively by the print job manager, the ticket rules used for a specific print job are easy to understand, because the ticket rules are only in one place, namely the print order manager, not as it was previously the case was to be present on different clients and there to investigate.
  • centrally running the job-in-order data check on the print job manager ensures that all incoming jobs Order-related data are checked or checked according to the same ticket rules and, if necessary, amended and corrected accordingly.
  • Job-related data centrally at the print job manager lies in the fact that the check of the job-related data in the process chain is very close to the concrete printing device, so that this check can be carried out very specifically for the respective printing device. This can significantly increase the quality of the review.
  • the check of the job-related data at the clients there is the problem that the clients have different
  • Print job managers can communicate so that it must be adapted to a review of the job-related data to the printing devices, which can be achieved with the different print job managers, which in turn is very difficult.
  • the central administration of the ticket rules also makes it possible to provide the operator with tools that facilitate the creation and administration of the ticket rules.
  • GUI graphical user interface
  • the invention is based on the object to provide a method and apparatus for receiving print data by a receiver of a transmitter, the on simple way to allow a safer handling of the print data at the receiver.
  • the object is achieved by a method having the features of claim 1 and claim 21 and by a
  • Print data by a receiver from a transmitter transmits the print data from the transmitter to the receiver according to a predetermined protocol.
  • the correct receipt of a predetermined data unit of print data is acknowledged by the sender.
  • the method for automatically transferring print data is characterized in that the receiver copies the print data for a particular data unit before executing the respective acknowledgment.
  • the print data is often transmitted from the sender to the receiver in a compressed form.
  • the compressed print data is copied.
  • the memory required to hold the copied data is kept low.
  • the data is not copied within a computer system, but copied from a computer system to a mirror computer system.
  • data would have to be transmitted via a data line. The transmission of the data line delays the copying process. Copying the print data in compressed form minimizes this delay.
  • the copying of the print data is as close as possible to the input of the receiver, in particular to an interface module, a copying module directly following the interface module or to a buffer module immediately downstream of the interface module.
  • the solution according to claim 23 relates to a method for receiving print data by a receiver from a transmitter, wherein the print data is transmitted according to a predetermined protocol.
  • the receiver checks whether the print data originate from a correct sender by checking the correctness of the sender with a module for receiving and storing the print data based on a plurality of parameters contained in the header according to the predetermined protocol before the print data passes through the module will be saved. Since several parameters are checked, the transmitter can be checked very specifically, whereby a profile with a variety of parameters can be queried. Since the parameters are taken from the header of the transmission protocol, third parties can not recognize which parameters are relevant for access to the receiver.
  • a third party can not send any print jobs to the receiver, even if it should recognize all parameters as receipt items. Because if one or more parameters can determine the content of the print job, only such print jobs are transmitted to the receiver with this parameter set. Other types of print jobs are automatically rejected.
  • the parameters of several headers are used to check the sender. If print data are transmitted from the sender to the receiver via the Internet, for example by means of the download protocol, the print data not only has a header of the download protocol but also of the Internet protocol. From both headers parameters can be used to check the transmitter. The selection and compilation of the parameters is incumbent on the receiver alone, who can thus individually determine according to which criteria he allows print data from transmitters.
  • the invention is further based on the object of further developing a method, a printing system and a computer program for mirroring print jobs with job-related data from a print server receiving the print jobs to a print server of another printing system in such a way that, in the event of a failure of one of the print servers, the print data is reliably printed, can be done quickly and correctly.
  • the mirror server In the method for mirroring print jobs containing job-related data by a print server of a first printing system to a print server of a second printing system, the mirror server, the following steps are performed: the received print jobs are printed on the
  • Mirror server mirrored, at least one mirror job ticket is created from the job-in-order data, and the mirror job ticket is copied to the mirror server.
  • the print job can print reliably, quickly, and correctly based on the mirrored job and the mirrored mirror job ticket ,
  • two mirror job tickets are created that are specific to each one of the two printing systems and copied to the mirror server.
  • the mirrored print jobs and / or mirror job tickets are locked for a predetermined period of time and / or the lock is only released when a data connection between the mirrored printing systems is interrupted.
  • the blocking can also be canceled manually by an authorized operator.
  • two or more printing systems can mirror each other symmetrically the print jobs, so that all printing systems are arranged side by side with equal rights.
  • the generation of the mirror job ticket is expediently carried out by means of ticket rules stored centrally in a ticket rule module in a print job manager. This uses default job tickets that are specific to the printing systems and / or the incoming print jobs, i. that therein are contained for the respective printing systems specific control parameters.
  • An entire order contains at least one document processing order, in particular a print job.
  • a print job contains at least one print file to be printed.
  • a total order ticket contains information about an overall order, such as Delivery address, order date, desired delivery date, etc.
  • a job ticket contains all the data required to process a print job. These data include control parameters that are relevant in a workflow for the job-workflow.
  • the job ticket is coded in a corresponding ticket format.
  • a default job ticket contains standard data that is suitable to present a print job that does not contain any further processing information Print system or an existing printing environment.
  • Such data are control parameters and may be, for example, names or addresses of printing devices that are connected to the respective print server.
  • a data ticket is understood to mean information that is generated by a print job-generating system, for example, a MFS mainframe computer system, together with the print data.
  • the scope of such data is very limited due to the system and its format is not standardized, which is why they are not considered job tickets in the above sense.
  • the order-related data can be both a total order ticket, a job ticket and / or a
  • Control parameters are often inserted in the file name of the print job.
  • a print system-specific job ticket is generated on the print job manager by means of the default job ticket and possibly further control parameters and the ticket rules. However, if a job ticket is attached to the print job, the job ticket is checked using the ticket rules to determine whether it is suitable as a printing system-specific job ticket and, if necessary, changed - which is the rule - and supplemented in particular by pressure-system-specific parameters from the default ticket.
  • FIG. 1 schematically shows the construction of a printing system for transmitting print data with a mainframe computer, a print server and a plurality of printers
  • FIG. 2 shows the print server from FIG. 1 with the modules for receiving and processing print data
  • FIG. 3 is a diagram illustrating the timing of transmitting and correcting
  • FIG. 5 shows a table with a parameter list
  • Figures 6a, 6b each have a configuration of
  • FIG. 7 shows a further table with parameters
  • Figure 8 shows essential parts of two printing systems for carrying out a method for mirroring of print jobs in a simplified schematic
  • the method for automatically transferring print data serves to transfer print data from a transmitter 1 to a receiver 2.
  • the transmitter 1 is generally a mainframe computer on which a large amount of data is generated on print data. This print data is usually distributed to several recipients 2 distributed. In FIG. 1, to simplify the illustration, only a single transmitter 1 and a single receiver 2 are shown.
  • the data communication between the transmitter 1 and the receiver 2 can be regulated by means of different protocols.
  • IBM mainframe computers this is
  • Program module HotDir which provides a directory in which incoming print data is automatically collected and forwarded to the recipient.
  • the transmitter 1 is a mainframe or IBM mainframe which operates with the OS / 390 operating system and the download protocol for transmitting the print data.
  • two printer driver 3 "Printer 1" and “Printer 2" are installed, which prepare the print data for transmission to a printer and forward.
  • a print server can simulate such a printer for the mainframe so that it can receive the print data from the mainframe.
  • the print server or receiver 2 can freely distribute the received print data to one of a plurality of printers 4 connected to the receiver 2.
  • printer driver is not used here in the sense of the printer drivers known from personal computers which process the print data in such a way and even rasterize it so that it can process the respective printing device directly. Instead, the printer drivers 3 of the transmitter 1 check the incoming print data as to whether they are suitable for the printing device on which they are to be printed and prepare the print data for transmission via a network 5 to the receiver 2 ,
  • the printer driver 3 can prepare print data for transmission to the transmitter 1 by certain Files to a print job, these files are compressed and possibly encrypted.
  • the thus prepared print data is received by the receiver 2.
  • the present receiver 2 is a print server, especially a PRISMA production print server.
  • This print server 2 has three different interface modules 6 for receiving print data using different protocols.
  • One of the interface modules 6 is for receiving data by means of the download protocol, the other for receiving data is a HotDir directory, and the third interface module 6 is for receiving data by means of the LP protocol.
  • the interface module 6 for receiving data by means of the download protocol is referred to below as the download interface 6.
  • two port numbers according to the TCP protocol are installed, with which the data streams between the transmitter 1 and the receiver 2 are identified. These port numbers are permanently assigned (assigned numbers).
  • the incoming at the interfaces print data are forwarded in the print server 2 to a spool module 7, which caches the print data and then transmits to the individual printer 4.
  • the download interface is designed as a program that runs in the background, usually with no direct user intervention taking place.
  • Such programs are called Unix and its derivatives as a daemon (Disc and Execution Monitor).
  • daemon Disc and Execution Monitor
  • the corresponding programs are called "Services" or “Services”.
  • a daemon can also run when no user is logged in to the computer.
  • FIG. 2 shows the program modules of the print server 2 that are relevant for receiving and forwarding by means of the download interface in a block diagram in more detail.
  • a buffer module 8 is subsequently arranged to the download interface 6, in which the incoming print data are buffered.
  • the buffer module 8 is followed by a decryption and decompression module 9, which writes the decrypted and decompressed data into another buffer module 10.
  • a print data processing unit 11 reads out the print data stored therein and performs the necessary processing steps.
  • the print data processing unit 11 writes the processed print data into another buffer 12 from which they are written into the spool module 7.
  • the buffer modules 8, 10, 12 are all inherited from the same class and correspond to the buffer class described in German patent application DE 199 57 594 A1 and in the corresponding US patent application US 2003/0041086 A1. These documents are incorporated herein by reference.
  • the buffer module 8 is designed such that it copies the incoming print data and forwards it via a data line 13 to a mirror computer system 14.
  • this mirror computer system 14 merely consists of an additional hard disk in the print server 2.
  • the mirror computer system 14 is preferably a computer system which is formed independently of the print server 2. In particular, the mirror computer system 14 should be removed, especially in another
  • the buffer module 8 with the copy function of the incoming print data is arranged in front of the decryption and decompression module 9, so that the print data in the compressed and encrypted state are forwarded to the mirror computer system 14.
  • the data volume to be transmitted via the data line 13 is kept low and enables a fast copying of the print data to the mirror computer system 14.
  • the buffer module 8 is designed in such a way that after completing the copying of the received print data, this is confirmed by the download interface 6.
  • the download interface 6 carries out the acknowledgment that the print data has been received correctly against the transmitter 1 only when the corresponding confirmation of the buffer module 8 is present. This ensures that an error on the print server 2, e.g. a crash does not cause incoming print data to be properly acknowledged to sender 1, but not to the
  • Print Server 2 in the mirror computer system 14 can be copied. This slight delay in the acknowledgment of the correct receipt of the incoming print data ensures that at least on the print server 2 or on the mirror computer system 4, even if a problem occurs on one of the two computers, the print data is available if it is correct with respect to the sender 1 have been acknowledged.
  • the delay of the acknowledgment of the correct input of the print data is mainly caused by the transmission of the copied print data via the data line 13. Therefore, it is particularly advantageous if the print data is transmitted in the compressed state to the mirror computer system 14. This is also advantageous if a fast data connection is used.
  • the incoming print data can also be copied in the download interface 6 and forwarded from there to the mirror computer system 14.
  • Such an embodiment has the advantage that the mirroring and acknowledgment is controlled by a single module, the download interface 6. As a result, an acknowledgment synchronized with the mirroring of the print data can easily be realized.
  • FIG. 2 shows by way of example a data connection 15 with a dashed line from the buffer module 12 to the mirror computer system 14.
  • the buffer module is designed such that all the print data stored with the buffer module 12 before being forwarded to the spool module 7 are copied via the data connection 15 to the mirror computer system 14.
  • the data link 15 is logically an independent data link from the data link 13.
  • the system for automatically transferring print data in which the print data is copied to a mirror computer system differs from conventional ones
  • mirror process is that not every arbitrary write to a storage medium, especially the hard disk of the receiver 2, is copied to the mirror computer system 14, but on the one hand only predetermined data, namely the print data to be copied and on the other hand, this data only to certain Process stations are copied. As a result, the necessary data transfer between the receiver 2 and the mirror computer system 14 is kept low compared to conventional mirror method.
  • the selection / specification of the data to be copied or stored and / or the mirror computer systems 14 can be carried out in a menu-guided manner, in particular by a user.
  • the targeted copying of predetermined data at certain process locations in the process flow of the receiver 2 brings about a further advantage over conventional mirror methods.
  • different rights for the user to edit the print data can be assigned to the receiver 2 and to the mirror computer system 14.
  • a user may have the right to delete 2 print data at the receiver. However, this right need not automatically extend to the mirror computer system 14. If a user inadvertently erases print data at the receiver 2, they continue to persist at the mirror computer system 14.
  • it is possible to form a deletion function on the receiver 2 such that they automatically staggered on the mirror computer system 14 is executed.
  • the time lag can be between a few hours and a few days. This ensures that after accidental deletion the data on the mirror computer system 14 at least for some time are available.
  • a print job comprising two print files (Datafile 1, Datafile 2) is transmitted from the transmitter 1 to the receiver 2.
  • Datafile 1 datafile 1
  • Datafile 2 datafile 2
  • Figure 3 the interface from the transmitter 1 to the network 5 with MF (mainframe), the
  • the first print file (Datafile 1) is transmitted from the transmitter to the receiver at step S1 (see arrow in FIG. 3). In the receiver, the first print file is copied and transferred to the mirror system with step S2.
  • Mirror computer system acknowledges the correct receipt of the print file 1 in step S3.
  • the correct receipt of the print file is then acknowledged by the receiver to the sender (step S4).
  • steps S1 to S4 are executed to transmit the second print file (data file 2). If the print job includes more than two print files, steps S1 through S4 are repeated to transfer one print file at a time. If all print files have been transferred correctly, the execution of the print job is started in the receiver with the step S5, wherein the print files are transmitted to the appropriate printing device. The recipient then receives after execution of the print job from
  • Download protocol are received, whereby the receipt of each print file is acknowledged.
  • the acknowledgment is given after the correct reception and the correct copying or mirroring of a data unit of the print data, which is limited by a checkpoint or the end of the print file.
  • the data unit to be transferred and copied is thus not always a complete print file but can also consist of sections of a print file.
  • the system consisting of the print server and the mirror computer system can be configured such that the mirror computer system is automatically used as the print server.
  • the mirror computer system with all functions or program modules of the print server, which are necessary for the forwarding and processing of the print data to provide.
  • the correct receipt of the print data is acknowledged only after copying the print data to the mirror computer system. If the copying of the print data can not be performed correctly, the entire transmission of the print data is canceled. In an alternative embodiment, however, it is also possible that the receiver to the transmitter the correct reception of the Print data acknowledges, even if the print data could not be correctly copied to the mirror computer system, provided that the print data was received correctly and stored correctly on the receiver. After correcting the error that was the cause of the improper copying, it is possible to subsequently copy the unprinted print data to the mirror computer system.
  • the system for automatically transferring print data may also be provided with multiple mirror computer systems.
  • the print data can be copied simultaneously to the multiple mirror computer systems.
  • Error error reaction
  • These rules for an error case are configured at the receiver 2. This configuration of a particular rule occurs for a particular mirror computer system 14. The rules are:
  • an error on a mirror computer system there are two ways in which an error on a mirror computer system can be remedied (error recovery).
  • error recovery an attempt can be made to copy all the print data or data units which have been received at the receiver since the occurrence of the error to the mirror computer system.
  • the mirror computer system can also be configured in such a way that the print data received since the occurrence of the error is no longer copied to this mirror computer system.
  • FIG. 4a shows a configuration example with three mirror computer systems which are referred to as primary mirror, secondary 1 -mirror and secondary 2 -mirror. If an error occurs while copying to the primary mirror, data transfer from the sender to the receiver is aborted. The print data or the corresponding data unit must be retransmitted. If an error occurs on the Secondary 1 mirror, the data transfer continues unchanged. After correcting the error, all print data received and stored in the meantime at the receiver will be copied to the Secondary 1-Mirror.
  • FIG. 4b shows a second configuration.
  • This configuration includes 4 mirror computer systems labeled Mirror 1, Mirror 2, Mirror 3, and Mirror 4.
  • the mirror 4 forms a replacement mirror computer system to the mirror 3.
  • the mirror 1 is configured so that the data transmission from the sender to the receiver is continued even if an error occurs in this mirror computer system.
  • the Mirror 2 is configured to abort data transfer from the sender to the receiver if a failure occurs on that mirrored computer system and at least two copies could not be successfully created. This means that data transfer will be interrupted if an error occurs on the Mirror 2 and the Mirror 1 fails or the Mirror 3 and its replacement mirror computer system (Mirror 4) fails. Furthermore, the data transfer is aborted when the mirror 4 fails.
  • the receiver whose interface module is designed such that it the incoming print data first checks whether they originate from a correct sender, in that the interface module contains the print data in a header according to the several parameters that are transmitted according to the protocol with which the print data is transmitted from the sender to the receiver. The correctness of the print data is checked before it is stored by the interface module on the receiver.
  • the print data are transmitted by means of the download protocol in conjunction with the TCP / IP protocol.
  • FIG. 4 is a table of typical parameters for monitoring the correct ones
  • the parameter "remote hosts” is in the header of the TCP / IP protocol All other parameters from the table in Figure 4 are specified in the header of the download protocol.
  • the parameters "local ports” and “remote hosts” provide general address data are used in firewall programs to monitor the correctness of the corresponding data.
  • the other parameters "remote users”, “remote printers”, “remote class” and “remote forms” are specific parameters for the print job or the printer or printer to be used These specific parameters are not used in firewall programs to validate the incoming data.
  • the remote class and remote forms parameters are very specific because these two parameters are the contents of the print data or data
  • the "remote forms" parameter specifies which forms are to be used.
  • the remote class parameter describes a specific printer queue in a given recipient
  • Printer queue is for transferring print data to one specific printer or to a specific group of printers.
  • FIG. 6a shows a configuration example in which a "star” is used as the placeholder for which arbitrary values can be inserted into the parameters
  • the configuration according to FIG. 5a thus means that all users can transmit their print data with arbitrary ports to any printing devices, provided that her IP address with "10.54.” starts.
  • the user "Natia” can transmit data from the printer “P910" on the transmitter “Testserver.nowhere.com” to the port 5055.
  • the user whose name begins with “Prod” can transmit from the transmitter "test server. anywhere.org “sends its print data over port 5056 to the" P950 "print device.
  • the user "Admin” can use any printer that starts with a “P” and transmits its print data from the transmitter "Domain Server” to any port.
  • the receiver can freely define the rules according to which the print data is allowed to be received based on the parameters from the headers.
  • the parameters listed in the above example are preferably used. In principle, however, other parameters listed in the headers can also be used.
  • FIG. 7 shows a list of further such JCL parameters (JCL: Job Control Language). This table is taken from the IBM Print Services Facility for OS / 390 & z / OS Guide, Download for OS / 390, Version 3, Release 3.0 (S544-5624e-02), 2002.
  • an apparatus for receiving used by print data which is designed as a print server.
  • a print server is a computer having a processor unit, a memory unit and a computer program for receiving, processing and forwarding print data.
  • the computer program is designed to carry out the method for automatically transferring print data.
  • the invention itself can also be realized as a computer program product which is stored on a data medium.
  • print jobs arriving at a print server 101 of a first printing system I are automatically mirrored onto a print server 101 of a second printing system II.
  • the print servers 101 each have a print job manager 102 (DAM), several clients 103, a buffer module 104 (PM), a decompression module 105 (DE), a memory unit 106 (SP) and a spool module 107 (SM) (FIG. 1).
  • DAM print job manager
  • PM buffer module
  • DE decompression module
  • SP memory unit
  • SP spool module 107
  • CL three different types of clients (CL) are provided, namely input modules 103/1, a print job client 103/2 and a ticket rule client 103/3.
  • a plurality of input modules 103/1 are provided, which are each connected to one or more computers 108 (RE) for generating a print job via data lines 109.
  • the input modules 103/1 serve to receive print data by means of protocols.
  • Such an input module 103/1 may, for example, be designed to receive print data by means of the download protocol or the LP protocol.
  • Such an input module can also be a HotDir directory.
  • the download interface is a program that runs in the background, usually without direct user intervention, educated. Such programs are called Unix and its derivatives as a daemon (Disc and Execution Monitor). In Microsoft Windows, the corresponding programs are called "Services" or “Services”. A daemon can also run when no user is logged in to the computer.
  • print job manager 102 and input modules 103/1 are located at a print center operator and print job processors 108 are at the customer's premises of the printing system operator and transmit their print jobs to the input modules via a network, such as the Internet ,
  • the clients 103 and the print job manager 102 are each computer program units. They can be installed and run on a common computer. However, it is equally possible to install and execute at least print job manager 102 and clients 103 on at least two separate computers.
  • the print job manager is also referred to as the PJM server (print job manager server).
  • the print job client 103/2 corresponding to the print job manager 102 is connected thereto via an interface 110 and serves to enable the operator of the print system to execute existing print jobs.
  • Such print jobs are, for example, print jobs that could not or could not be printed correctly.
  • the operator can change the print job and in particular the job ticket of such a print job with the aid of the print job client 103/2 and transmit the respective print job to the print job manager 102 in order to have it printed on a printing device 111 (DR).
  • DR printing device 111
  • incoming print jobs are routed via an interface 116 to the buffer module 104 and cached there.
  • the cached print jobs read out the decompression module 105 and decompress the data.
  • the decompression module 105 is also formed with a decryption function so that it also decrypts the data.
  • the decompressed and decrypted print data is stored in the storage unit 106.
  • the print jobs stored in the storage unit 106 are read by the print job manager 102 to be forwarded to the spool module 107.
  • the print job manager is used to check job-related data contained in the print jobs and to generate job tickets specific to the respective printing system.
  • the print job manager 102 supplements the job-related data of the incoming print jobs with data, in particular control parameters, from a default job ticket. In particular, missing, but necessary in the existing printing environment control parameters are added to the job-related data. If there is a complete order ticket, the data, in particular control parameters of the total order ticket, are also added to the printing system-specific job ticket.
  • the print job manager 102 has a ticket rule module 112 (TRM) in which ticket rules are stored.
  • TRM ticket rule module 112
  • the ticket rules are managed by the ticket rule module and executed on the print job manager.
  • the ticket rule module 112 has an interface 113 to the ticket rule client 103/3, via which bidirectional communication is possible.
  • the ticket rule client 103/3 comprises a rule editor module with which the ticket rules stored in the ticket rule module can be edited.
  • the rule editor module is provided with a graphical user interface (GUI).
  • the ticket rule module 112 may also be connected to a plurality of ticket rule clients 103/3. But they will all be Ticket rules stored exclusively in ticket rule module 112 at print job manager 102. With the ticket rule clients 103/3, only the ticket rules stored in the ticket rule module 112 can be accessed and these can be changed there.
  • the job ticket contains a list of control parameters for controlling the respective print job.
  • the ticket rules comprise a sequence of actions that are applied to incoming order-related data of the received print job.
  • the incoming print jobs at a first printing system I are copied by the buffer module 104 and the copy is transmitted via a data line 114 to an input module 103/1 of a second printing system II.
  • This copy contains the print jobs in compressed and encrypted state. This is advantageous for the transmission from the printing system I to the printing system II, since these two printing systems are normally arranged far away from each other and the compressed data can be transmitted much faster than uncompressed data.
  • the mirrored print data are written into the memory unit 106 in the second printing system II via the input module 103/1, the buffer module 104, the decompression module 105.
  • the incoming print data is also decompressed by the decompression module 105 and decrypted and then stored in the memory unit 106.
  • the respective print jobs are from the print job manager 102 of the first printing system I pressure system specific Jobtickets based on Job-related data created. In principle, this is done in the same way as described in the German Patent Application "Method, Printing System and Computer Program for Automatically Processing Order-Related Data of a Print Job" filed on February 28, 2007, which is why reference is made to this patent application.
  • the job ticket specific to the first printing system I is mirrored onto the print server of the second printing system II.
  • This job ticket is then called a mirror job ticket. This is especially useful when the second printing system II has the same resources and printing devices as the first printing system I. Then the print job can be performed directly on the second printing system.
  • the print job managers 102 of the two printing systems I and II are coupled together with a data link 115.
  • the data connection has interfaces to the two print job managers 102. Physically, however, this data connection 115 is based on the same lines as the data line 114 for mirroring the incoming print data. Since on the second printing system II the printing data are held together with the mirror job ticket specific to the first printing system I, in the case of a temporary failure of the first printing system I, in which the printing data stored on the first printing system I are damaged, this together with the mirror image Job ticket from the print server 101 of the second printing system II back to the print server 101 of the first printing system I are copied and brought to the first printing system I without further delay to execute.
  • a second job ticket specific to the second printing system II is created on the print server 101 of the first printing system I in addition to the job ticket specific to the first printing system I.
  • This second job ticket is mirrored on the print server 101 of the second printing system II and thus provides a mirror image.
  • Job ticket For this purpose, on the print server 101 of the first printing system I, a default job ticket specific to the second printing system II is kept, whose control parameters are used to supplement the job-related data for creating the job ticket specific to the second printing system II.
  • the checking of the order-related data and generation of the job ticket specific to the second printing system II is carried out by means of the ticket rules stored in the ticket rule module 112. The ticket rules can be used for each
  • Printing system contain specific control parameters that they enter in a specific job ticket.
  • the print job can be printed on the second printing system II with the mirror job ticket that is specific to the second printing system II without delay.
  • both a mirror job ticket specific to the first printing system I and a mirror job ticket specific to the second printing system II are generated on the first printing system I and both are mirrored onto the print server 101 of the second printing system II .
  • both mirror job tickets are also stored on the print server of the first printing system I, since then all the data for carrying out an expression on any of the two printing systems I and II are present on both printing systems.
  • the print job data is extracted from the print data on the print server 101 of the first print system I and either directly to the print server 101 of the second print system II or after pre-processing to the print server 101 of the print server 101 second printing system II transmitted.
  • a job ticket specific to the second printing system II is then generated from these job-related data.
  • the extraction of order-related data can be done simply by copying the order-related data available as a file in the form of a data ticket.
  • the extraction may, however, also include the collection of job-related data from different sources, in particular the file name of the print job and files containing one or more job-accompanying data.
  • the preprocessing of this order-related data may include, for example, a combination of the data from different sources in a common file.
  • this preprocessing can also be the generation of the job ticket specific to the first printing system I, which is forwarded to the print server 101 of the second printing system II and converted there into a job ticket specific to the second printing system II.
  • the job ticket generated at the second printing system II and specific for the second printing system II can, in turn, be mirrored onto the print server 101 of the first printing system I.
  • the print server 101 of the second printing system II should not be specially configured for use as a mirror server. It processes the mirrored print data received from the print server 101 of the first printing system I as well as all other incoming print data.
  • the print job manager 102 has an interface to the mirroring process to perform the mirroring process
  • Data connection 115 is formed. However, this interface is equally located on the print job manager 102 of the first print server 101. It is also possible for the print servers 101 of the two printing systems to mirror each other's respective print jobs, and this can also be done simultaneously. However, locked print jobs are not mirrored, otherwise the two print servers would block each other with a single print job due to the permanent back and forth mirroring of a print job.
  • the print data contained in the print jobs are processed. This processing may involve various processing operations such as e.g. grating the print data contained in the print jobs, adjusting the print page arrangement according to the post-processing devices connected to the print system.
  • information may be stored as to which parts of a print job that require a raster process (RIP) in the print server, such as a print job.
  • RIP raster process
  • Processing progress reflecting job ticket is suitably mirrored as a mirror job ticket on the print server 101 of the second printing system II.
  • the already processed print data on the print server 101 of the second printing system II is suitably mirrored as a mirror job ticket on the print server 101 of the second printing system II.
  • Printing system II copied. This makes it possible, in the case of a problem at the first printing system I to continue the processing of the respective print job with the processing progress already achieved on the second printing system II.
  • the print jobs at the print server 101 of the first printing system I are in the execution state, whereas the print jobs mirrored on the print server 101 of the mirror printing system II are in the blocked idle state.
  • These two print servers 101 are synchronized with one another such that when a print job in the execution state is deleted by the operator, the corresponding mirrored print job is also automatically deleted, this synchronization is canceled if the data line 114 or the data connection 115 between the two printing systems I , II is interrupted. Such an interruption will cancel the blocking of the mirrored print job in the mirror printing system II.
  • Print server to the receiving print server if an error occurs while copying on the print server of the mirror printing system.
  • Print server to the receiving print server, even if there is an error on the receiving print server.
  • error recovery there are two ways in which an error on a mirror printing system can be remedied (error recovery).
  • an attempt can be made to copy all the print data or data units that have been received at the receiver since the error occurred to the mirror printing system.
  • the reflective printing system can also be configured such that the print data received since the occurrence of the error is no longer copied to this mirror printing system.
  • the incoming print data is first directly mirrored. This is done in the buffer module 104. However, this can also be done in one of the input modules 103/1. All print data, ie the print data to be printed as well as the job-related data are mirrored. It is essential for the invention that specific job tickets are additionally generated from the job-accompanying data for the printing systems, which are then also mirrored immediately. Job tickets are created by applying ticket rules the incoming order-related data. These ticket rules link the order-related data with standard job tickets. The default job tickets are specific to each printing system. The default job tickets are also specific to the different input modules 103/1, so that, for example, a total of six different default job tickets are to be provided for three different input modules and two different printing systems.
  • the ticket rules can be called in different ways:
  • Input module with the call passes a parameter indicating which ticket rule to the respective
  • Print job or its job-related data is applied.
  • Print job is received, a certain ticket rule is automatically executed. (3) Depending on the mirror method in the buffer module
  • a particular ticket rule is called to create one or more mirror job tickets.
  • first printing system II second printing system (mirror printing system)

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Accessory Devices And Overall Control Thereof (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Empfangen von Druckdaten. Gemäß einem ersten Aspekt der vorliegenden Erfindung werden die Druckdaten vom Empfänger kopiert und auf einem Spiegel-Computersystem gespeichert, bevor der Empfang der Druckdaten dem entsprechenden Sender quittiert wird. Hierdurch wird die Gefahr eines Verlustes der Druckdaten auf Seiten des Empfängers erheblich verringert. Nach einem zweiten Aspekt der vorliegenden Erfindung werden die eingehenden Druckdaten anhand von in einem oder mehreren Headern enthaltener Parameter dahingehend überprüft, ob die Druckdaten von einem korrekten Sender stammen. Die entsprechende Parameterliste ist vom Empfänger frei einstellbar, wodurch er sehr spezifisch die Quellen, aus welchen er Druckdaten erhält, kontrollieren kann. Insbesondere können auch inhaltsbezogene Parameter der Druckdaten verwendet werden.

Description

Verfahren und System zum automatischen Übertragen von
Druckdaten und insbesondere zum Spiegeln von
Druckaufträgen
Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zum Empfangen von Druckdaten durch einen Empfänger von einem Sender, und insbesondere zum Spiegeln von Druckaufträgen.
Die Erfindung ist für Druckumgebungen mit elektrofotografischem Hochleistungsdrucker vorgesehen.
Die Empfänger sind hierbei in der Regel Druckserver. Derartige Druckserver sind im Buch Digitaldruck-Technik und Drucktechnologien der oce Drucksysteme, 9. Ausgabe, Februar 2005 (ISBN 3-00-001019-X) in Kapitel 15 beschrieben. Diese Druckserver werden als oce PRISMAproduction Server bezeichnet. Sie stellen unter anderem die Kommunikation zwischen Großrechnern
(Mainframes) und den Druckgeräten her. Ein solcher Druckserver kann von mehreren unterschiedlichen Großrechnern Druckdatenströme in unterschiedlichen Formaten empfangen und sie an eine Vielzahl weiterer Druckgeräte weiterleiten. Die Übertragung der Daten kann über unterschiedliche Netzwerke nach unterschiedlichen Protokollen erfolgen.
Viele Anwender derartiger elektrofotografischer Hochleistungsdrucksysteme haben ihre Großrechner auf einen bzw. wenige Standorte konzentriert. Oftmals führen die Betreiber derartiger Großrechner die Druckvorgänge nicht selbst durch, sondern senden ihre zu druckenden Daten an sogenannte Druckzentren. Diese Druckzentren haben ein oder mehrere elektrofotografische Hochleistungsdrucker, die über ein lokales Netzwerk miteinander verbunden sind. In diesem lokalen Netzwerk ist ein Druckserver angeordnet, der über ein weiteres Netzwerk, wie z.B. dem Internet, die Druckdaten vom Großrechner empfängt .
Zum Übertragen der Daten von einem Großrechner zu einem Printserver wird oftmals das Protokoll „Download" von IBM verwendet. Dieses Protokoll ist ein separat bestellbares Merkmal der IBM Print Services Facility (PSF) für das auf Großrechnern verwendete Betriebssystem OS/390. Download überträgt automatisch Druckdaten über ein TCP/IP-Netzwerk. Mit dem Download-Protokoll wird eine automatische
Fehlerbehebung ausgeführt. Falls die Übertragung der Druckdaten nicht korrekt ausgeführt werden konnte, werden die Druckdaten erneut übertragen. Hierzu ist es nicht notwendig, dass ein Operator am Großrechner eingreift und die Datenübertragung neu ausführt. Die Druckdaten werden solange im Großrechner vorgehalten, bis sie vollständig und korrekt übertragen worden sind. In dem vom Großrechner erzeugten Druckdatenstrom können Marken eingefügt werden, die als Checkpoints bezeichnet werden. Falls ein Fehler bei der Übertragung der Druckdaten aufgetreten sein sollte, werden die Daten ab dem letzten Checkpoint nochmals neu übertragen. Hierdurch ist es nicht notwendig, immer die gesamten Druckdaten von neuem zu übertragen.
Für Betreiber von Druckzentren entstehen erhebliche Probleme, wenn sie aufgrund einer Computerpanne die Druckdaten verlieren oder die Druckdaten soweit beschädigt werden, dass sie nicht mehr verwendbar sind. Wenn der korrekte Empfang dem Sender quittiert worden ist, dann löscht dieser die Druckdaten und sie stehen nicht mehr für eine erneute Übertragung zur Verfügung. Zur Vermeidung dieser Probleme ist das Protokoll Download mit einer Funktion versehen, mit welcher die Druckdaten gleichzeitig an mehrere Empfänger übertragen werden können. Dies dient dazu, die Druckdaten an einen Druckserver und an Spiegel -
Computersysteme zu übertragen, auf welchen die Druckdaten eine gewisse Zeit vorgehalten werden, um nachträglich auftretende Fehler bei der Verarbeitung der Druckdaten durch Abarbeiten vom Spiegel -Computersystem der Druckdaten beheben zu können. Jedoch liegt das Spiegeln der Druckdaten auf Spiegel -Computersysteme im Verantwortungsbereich des Betreibers des Großrechners und nicht der Druckzentren. Selbst wenn der Betreiber des Großrechners eine derartige Spiegelung vorsieht, werden die Druckdaten nach der Quittierung des erfolgreichen Empfanges gelöscht und es besteht keine Möglichkeit, die Druckdaten erneut abzurufen. Andererseits ist es für den Betreiber des Druckzentrums geschäftlich sehr nachteilig, wenn er von seinem Auftraggeber die bereits korrekt übermittelten Druckdaten erneut abfragen muss.
Um diese Probleme zu vermeiden, müssten auf dem
Großrechner bzw. auf dessen Spiegel -Computersysteme die Druckdaten solange vorgehalten werden, bis der vollständige Ausdruck abgeschlossen ist. Hierzu müsste über die gesamte Produktionskette nach dem erfolgten Ausdruck eine Rückmeldung an den Großrechner erfolgen, damit die Druckdaten wieder gelöscht werden können. Eine derartige Rückmeldung bedeutet einen erheblichen Kommunikationsaufwand. Großrechner versenden ihre Druckdaten an unterschiedliche Druckserver, die wiederum eine Vielzahl unterschiedlicher Drucker ansteuern. All die unterschiedlichen Druckserver und Drucker müssten für eine derartige Rückmeldung eingerichtet sein. Da bekannte Protokolle zum Übertragen von Druckdaten zwischen Großrechnern und Druckservern eine derartige Rückmeldung nicht vorsehen, ist dies praktisch kaum möglich.
Software zum Spiegeln von gesamten Computersystemen ist bekannt und könnte grundsätzlich auch für einen solchen Druckserver eingesetzt werden, der die Druckdaten empfängt. Hiermit würde jedoch der Druckserver an sich gespiegelt werden, was zur Folge hätte, dass im Druckserver fehlerhaft gespeicherte Daten auf dem Spiegel- Computersystem wiederum fehlerhaft gespeichert werden würden. Durch am Druckserver verursachte Fehler erzeugte Probleme können somit nicht vermieden werden. Löscht beispielsweise ein Benutzer am Druckserver versehentlich Druckdaten, so werden sie automatisch auch am Spiegel -
Computersystem gelöscht, da dieses Spiegel -Computersystem eine exakte Kopie des Druckservers darstellen soll.
Bei dieser bekannten Software zum Spiegeln eines gesamten Computer-Systems wird jeder einzelne Speichervorgang auf einer Festplatte des Computer-Systems sofort auf das Spiegel -Computersystem übertragen und dorthin kopiert.
Bei der Übertragung der Druckdaten besteht ein weiteres Problem, dass die Druckdaten manchmal an einen falschen
Druckserver übermittelt werden. Die einzelnen Druckserver haben oftmals ähnliche Namen, so dass bei einem Tippfehler oder bei einer falschen Auswahl aus einer Menüliste ein falscher Druckserver als Ziel eingegeben wird. Eine solche Fehladressierung tritt zwar nicht häufig auf, jedoch wenn sie einmal auftritt, verursacht sie im Hochleistungsdruck einen erheblichen Schaden, da ein am falschen Druckgerät ausgedrucktes Druckprodukt meistens nicht gebrauchbar ist. Wenn Druckdaten an ein falsches Druckgerät übermittelt werden, dann sind an diesem Druckgerät oftmals nicht die korrekten Ressourcen und Formulardefinitionen vorhanden, so dass die Druckdaten falsch ausgedruckt werden. Im Hochleistungsdruck kann ein fehlerhaft ausgedruckter Druckauftrag einen erheblichen finanziellen Schaden bedeuten. Bisher wird versucht, eine derartige
Fehlübertragung von Druckdaten mittels Firewall-Programmen festzustellen, die anhand von Parametern, die im Header des verwendeten Netzwerk-Protokolls enthalten sind, entscheiden, ob die Druckdaten korrekt zugestellt werden. Die Header der Netzwerkprotokolle, wie z.B TCP/IP enthalten jedoch nur grundsätzliche Parameter wie die Adresse des Senders und des Empfängers. Ist ein bestimmter Sender an einem bestimmten Empfänger freigeschaltet, so erlauben die Firewall-Programme den Empfang aller Daten von diesem Sender.
Oftmals will man jedoch eine wesentlich spezifischere Zuordnung zwischen Sender und Empfänger, z.B. soll ein Sender eine bestimmte Art von Druckaufträgen an einen bestimmten Empfänger übermitteln und eine andere Art von Druckaufträgen an einen anderen Empfänger übermitteln.
Bei auf Linux-Systemen oder anderen Unix-Derivaten basierenden Druckservern ist es bekannt, eingehende Druckaufträge mittels des Protokolls LP mit dem Deamon lpd.perms auf mehrere für den Sender und Empfänger spezifische Parameter zu überprüfen. Hierzu ist dem
Druckauftrag jeweils eine separate Datei beigefügt, die nicht nur die Adressdaten des Sende-Computers und des Empfangs-Computers, sondern auch mehrere Parameter zum Benutzer enthalten. Es ist auch ein Parameter zum Druckgerät hierin aufgeführt.
Nachteilig bei diesem System ist, dass die zu überwachenden Parameter in einer separaten Datei abgespeichert sind. Wenn ein Hacker diese Datei abfängt und kopiert kann er jederzeit an einem Druckserver einen Druckauftrag auslösen. Er kann auch Dateien in den Druckserver einschleusen, die ein Sicherheitsrisiko darstellen.
Aus Digital Printing - Technology und Printing Techniques of Oce Digital Printing Presses (a. a.a.O.) geht ein mit dem Handelsnamen Oce PRISMAproduction bezeichnetes Serversystem hervor, das eine breite Palette von Datenströmen verarbeitet bzw. konvertiert, die dann auf IPDS-Druckern gedruckt werden. Das Oce PRISMAproduction Serversystem umfasst einen PrintJobmanager PJM (siehe Kapitel 15.2.4 und 18.2), mit dem Druckaufträge auf einen beliebigen Kunden-Client erzeugt und in diesem ServerSystem bearbeitet und verwaltet werden. Der PrintJobmanager wird auch als Druckauftragsmanager bezeichnet .
Auf die am 28. Februar 2007 eingereichte deutsche
Patentanmeldung DE 10 2007 009 737 wird vollinhaltlich Bezug genommen und sie wird in die vorliegende Patentanmeldung aufgenommen.
Das darin beschriebene Verfahren bearbeitet
Auftragsbegleitdaten eines Druckauftrages, die Steuerparameter zum Steuern des Druckauftrages beinhalten. Dieses Verfahren wird in einem Drucksystem mit einem Druckauftragsmanager, einem oder mehreren Clients, an welchen Druckaufträge erzeugt werden, und einem
Druckserver zum Zuführen der Druckaufträge an ein Druckgerät ausgeführt und umfasst die folgenden Schritte:
- Empfangen eines Druckauftrages mit Auftragsbegleitdaten von einem der Clients durch den Druckauftragsmanager,
- Überprüfen der Auftragsbegleitdaten nach vorbestimmten Ticket-Regeln und Ausgeben eines drucksystemspezifischen Jobtickets, und
- Weiterleiten des Druckauftrages mit dem Jobticket zum Druckserver.
Dieses Verfahren zeichnet sich dadurch aus, dass das Überprüfen der Auftragsbegleitdaten nach den vorbestimmten Ticket-Regeln zentral am Druckauftragsmanager ausgeführt wird.
Da die Auftragsbegleitdaten zentral und vorzugsweise ausschließlich am Druckauftragsmanager überprüft bzw. kontrolliert werden, sind die für einen bestimmten Druckauftrag angewandten Ticket-Regeln einfach nachvollziehbar, denn die Ticket-Regeln sind lediglich an einer einzigen Stelle, nämlich dem Druckauftragsmanager, und nicht, wie es bisher der Fall war, an unterschiedlichsten Clients vorhanden und dort jeweils zu untersuchen. Weiterhin ist durch das zentrale Ausführen der Überprüfung der Auftragsbegleitdaten am Druckauftragsmanager sichergestellt, dass alle eingehenden Auftragsbegleitdaten nach den gleichen Ticket-Regeln überprüft bzw. kontrolliert werden und gegebenenfalls entsprechend abgeändert und korrigiert werden.
Weiterhin sind durch das zentrale Ausführen des
Überprüfens der Auftragsbegleitdaten die Ticket-Regeln zentral zu verwalten, wodurch sie auch zentral kontrollierbar sind und vermieden wird, dass ähnliche Auftragsbegleitdaten bzw. ähnliche Fehler in Auftragsbegleitdaten unterschiedlich korrigiert werden.
Ein weiterer Vorteil des Überprüfens der
Auftragsbegleitdaten zentral am Druckauftragsmanager liegt darin, dass die Überprüfung der Auftragsbegleitdaten in der Prozesskette sehr nahe am konkreten Druckgerät erfolgt, so dass diese Überprüfung sehr spezifisch für das jeweilige Druckgerät durchgeführt werden kann. Hierdurch kann die Qualität der Überprüfung erheblich gesteigert werden. Bei der Ausführung der Überprüfung der Auftragsbegleitdaten an den Clients besteht das Problem, dass die Clients mit unterschiedlichen
Druckauftragsmanagern kommunizieren können, so dass eine darauf ausgeführte Überprüfung der Auftragsbegleitdaten an die Druckgeräte, die mit den unterschiedlichen Druckauftragsmanagern erreicht werden können, angepasst sein muss, was wiederum sehr schwierig ist.
Durch die zentrale Verwaltung der Ticket-Regeln ist es auch möglich, dem Operator Werkzeuge zur Verfügung zu stellen, die das Erstellen und Verwalten der Ticket-Regeln erleichtern. Insbesondere ist es zweckmäßig, eine graphische Benutzeroberfläche (GUI) vorzusehen, in welcher die Ticket-Regeln erstellt und verwaltet werden können und ein Softwaremodul vorzusehen, mit dem die Syntax der editierten Ticket-Regeln automatisch auf eine korrekte Syntax überprüft wird.
Der Erfindung liegt die Aufgabe zu Grunde, ein Verfahren und eine Vorrichtung zum Empfangen von Druckdaten durch einen Empfänger von einem Sender zu schaffen, die auf einfache Art und Weise eine sicherere Handhabung der Druckdaten am Empfänger erlauben.
Die Aufgabe wird durch ein Verfahren mit dem Merkmal des Anspruchs 1 und des Anspruchs 21 und durch eine
Vorrichtung mit den Merkmalen des Anspruchs 27 gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind in den jeweiligen Unteransprüchen angegeben.
Mit dem Verfahren nach Anspruch 1 zum Empfangen von
Druckdaten durch einen Empfänger von einem Sender werden die Druckdaten vom Sender an den Empfänger nach einem vorbestimmten Protokoll übertragen. Der korrekte Empfang einer vorbestimmten Dateneinheit an Druckdaten wird vom Sender jeweils quittiert. Das Verfahren zum automatischen Übertragen von Druckdaten zeichnet sich dadurch aus, dass der Empfänger vor dem Ausführen der jeweiligen Quittierung für eine bestimmte Dateneinheit die Druckdaten kopiert.
Durch das unmittelbare Kopieren der Druckdaten, bevor sie gegenüber dem Sender quittiert werden, wird sicher gestellt, dass ein nach dem Quittieren am Empfänger auftretender Fehler keinen Einfluss auf die kopierten Druckdaten haben kann. Tritt hingegen vor dem Quittieren der Druckdaten ein Fehler am Empfänger auf, so erfolgt auch keine korrekte Quittierung, wodurch der Sender davon ausgehen muss, dass die Druckdaten nicht korrekt empfangen worden sind. Der Sender wird deshalb die Druckdaten nicht löschen und sie stehen für eine weitere Übertragung zur Verfügung. Tritt hingegen nach der Quittierung ein Fehler am Empfänger auf, kann es sein, dass die an sich korrekt empfangenen Druckdaten beschädigt werden. Da eine Kopie dieser Druckdaten erstellt worden ist, kann auf diese Kopie zurückgegriffen werden und die Bearbeitung der Druckdaten ohne Beeinträchtigung fortgesetzt werden. Das Verfahren zum automatischen Übertragen von Druckdaten erlaubt eine Vielzahl von Optionen, wie die kopierten bzw. gespiegelten Druckdaten in einem Fehlerfall verwendet werden. Es ist auch möglich, die Druckdaten mehrfach zu kopieren.
Die Druckdaten werden oftmals vom Sender zum Empfänger in einer komprimierten Form übertragen. In einer bevorzugten Ausführungsform der Erfindung werden die komprimierten Druckdaten kopiert. Hierdurch wird der Speicherbedarf zum Vorhalten der kopierten Daten gering gehalten. Meistens werden die Daten nicht innerhalb eines Computersystems kopiert, sondern von einem Computersystem auf ein Spiegel - Computersystem kopiert. Hierzu müssten Daten über eine Datenleitung übertragen werden. Das Übertragen der Datenleitung verzögert den Kopiervorgang. Durch das Kopieren der Druckdaten in komprimierter Fassung wird diese Verzögerung gering gehalten.
Nach einer weiteren bevorzugten Ausführungsform in der vorliegenden Erfindung erfolgt das Kopieren der Druckdaten möglichst nahe am Eingang des Empfängers, insbesondere an einem Schnittstellen-Modul, einem unmittelbar dem Schnittstellen-Modul nachgeordneten Kopiermodul oder an einem dem Schnittstellen-Modul unmittelbar nachgeordneten Puffermodul .
Die Lösung gemäß Anspruch 23 betrifft ein Verfahren zum Empfangen von Druckdaten durch einen Empfänger von einem Sender, bei dem die Druckdaten gemäß einem vorbestimmten Protokoll übertragen werden. Der Empfänger überprüft, ob die Druckdaten von einem korrekten Sender stammen, indem der Empfänger mit einem Modul zum Empfangen und Speichern der Druckdaten anhand von mehreren Parametern, die gemäß dem vorbestimmten Protokoll im Header enthalten sind, die Korrektheit des Senders überprüft, bevor die Druckdaten durch das Modul gespeichert werden. Da mehrere Parameter überprüft werden, kann der Sender sehr spezifisch überprüft werden, wobei ein Profil mit einer Vielzahl von Parametern abgefragt werden kann. Da die Parameter dem Header des Übertragungsprotokolls entnommen werden, können Dritte nicht erkennen, welche Parameter für den Zugang zum Empfänger relevant sind. Selbst wenn ein Dritter im Internet eine solche Nachricht abfangen sollte, kann er zum einen nicht erkennen, dass die im Header enthaltenen Parameter die zugangsrelevanten Daten sind und selbst wenn er Kenntnis davon haben sollte, kann er nicht erkennen, welche Parameter für den Zugang zum Empfänger relevant sind.
Wenn die Parameter, die zur Überprüfung des Senders herangezogen werden, den Inhalt des Druckauftrages mitbestimmen, kann ein Dritter keine beliebigen Druckaufträge an den Empfänger senden, selbst wenn er alle Parameter als Zugangselemente erkennen sollte. Denn wenn ein oder mehrere Parameter den Inhalt des Druckauftrages mitbestimmen können, nur derartige Druckaufträge mit diesem Parametersatz an den Empfänger übermittelt werden. Andere Typen von Druckaufträgen werden automatisch abgewiesen.
Vorzugsweise werden die Parameter mehrerer Header zur Überprüfung des Senders herangezogen. Werden Druckdaten beispielsweise mittels des Download-Protokolls über das Internet vom Sender zum Empfänger übertragen, so weisen die Druckdaten nicht nur einen Header des Download- Protokolls sondern auch des Internet-Protokolls auf. Aus beiden Headern können Parameter zur Überprüfung des Senders verwendet werden. Die Auswahl und Zusammenstellung der Parameter obliegt alleine dem Empfänger, der so individuell bestimmen kann, nach welchen Kriterien er Druckdaten von Sendern zulässt. Der Erfindung liegt weiterhin die Aufgabe zugrunde, ein Verfahren, ein Drucksystem und ein Computerprogramm zum Spiegeln von Druckaufträgen mit Auftragsbegleitdaten von einem die Druckaufträge empfangenden Druckserver auf einen Druckserver eines weiteren Drucksystems derart weiterzubilden, dass bei einem Ausfall eines der Druckserver der Ausdruck der Druckdaten zuverlässig, schnell und korrekt erfolgen kann.
Die Aufgabe wird durch ein Verfahren mit den Merkmalen des Anspruchs 29, ein Computerprogramm mit den Merkmalen des Anspruchs 43 und ein Drucksystem mit den Merkmalen des Anspruchs 45 gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind in den jeweiligen Unteransprüchen angegeben.
Beim Verfahren zum Spiegeln von Druckaufträgen, die Auftragsbegleitdaten enthalten, durch einen Druckserver eines ersten Drucksystems auf einen Druckserver eines zweiten Drucksystems, dem Spiegelserver, werden folgende Schritte ausgeführt: die empfangenen Druckaufträge werden auf den
Spiegelserver gespiegelt, anhand der Auftragsbegleitdaten wird zumindest ein Spiegel-Jobticket erstellt, und das Spiegel-Jobticket wird auf den Spiegelserver kopiert .
Da mit dem Verfahren zum Spiegeln von Druckaufträgen aus den Auftragsbegleitdaten ein Spiegel-Jobticket erstellt wird, das auf den Spiegelserver kopiert wird, kann bei einem Problem der Ausdruck des Druckauftrags zuverlässig, schnell und korrekt anhand des gespiegelten Druckauftrags und des gespiegelten Spiegel-Jobtickets fortgesetzt werden.
Vorzugsweise werden zwei Spiegel-Jobtickets erstellt, die für jeweils eines der beiden Drucksysteme spezifisch sind und auf den Spiegelserver kopiert. Die gespiegelten Druckaufträge und/oder Spiegel-Jobtickets werden für eine vorbestimmte Zeitdauer gesperrt und/oder die Sperrung wird nur aufgehoben, wenn eine Datenverbindung zwischen den gespiegelten Drucksystemen unterbrochen ist. Die Sperrung kann auch manuell von einem berechtigten Operator aufgehoben werden.
In einer Weiterbildung der Erfindung können zwei oder mehrere Drucksysteme sich gegenseitig symmetrisch die Druckaufträge spiegeln, so dass alle Drucksysteme gleichberechtigt nebeneinander angeordnet sind.
Die Erzeugung des Spiegel-Jobtickets erfolgt zweckmäßigerweise mittels zentral in einem Ticket-Regel- Modul vorgehaltener Ticket-Regeln in einem Druckauftragsmanager. Hierbei werden Vorgabe-Jobtickets verwendet, die für die Drucksysteme und/oder den eingehenden Druckaufträgen spezifisch sind, d.h. dass darin für die jeweiligen Drucksysteme spezifische Steuerparameter enthalten sind.
Zur Erläuterung der vorliegenden Erfindung werden nachfolgend einige Begriffe definiert:
Ein Gesamtauftrag enthält mindestens einen Dokumentenbearbeitungsauftrag, insbesondere einen Druckauftrag .
Ein Druckauftrag (Job) enthält mindestens eine zu druckende Druckdatei .
Ein Gesamtauftragsticket (order- ticket) enthält Informationen über einen Gesamtauftrag, wie z.B. Auslieferungsadresse, Auftragsdatum, gewünschtes Lieferdatum, etc.
Ein Jobticket enthält alle zur Abarbeitung eines Druckauftrages erforderlichen Daten. Diese Daten umfassen Steuerparameter, die in einem Arbeitsablauf für den Druckauftrag (job-workflow) relevant sind. Das Jobticket ist in einem entsprechenden Ticketformat kodiert.
Ein Vorgabe-Jobticket enthält Standard-Daten, die geeignet sind, einen Druckauftrag, der keine weiteren Bearbeitungsinformationen enthält, in einem vorliegenden Drucksystem bzw. einer vorliegenden Druckumgebung auszugeben. Solche Daten sind Steuerparameter und können z.B. Namen oder Adressen von Druckgeräten sein, die an den jeweiligen Druckserver angeschlossen sind.
Unter einem Datenticket werden Informationen verstanden, die von einem einen Druckauftrag erzeugenden System, beispielsweise einem MFS Mainframe-Computer-System erzeugten Druckauftrag zusammen mit den Druckdaten erzeugt werden. Der Umfang derartiger Daten ist systembedingt sehr begrenzt und ihr Format nicht standardisiert, weshalb sie nicht als Jobtickets im obigen Sinne angesehen werden.
Die Auftragsbegleitdaten können sowohl ein Gesamtauftragsticket, ein Jobticket und/oder ein
Datenticket oder Steuerparameter, die in anderer Form einem Druckauftrag beigefügt sind, umfassen. Steuerparameter werden öfters in den Dateinamen des Druckauftrages eingefügt.
Ist dem Druckauftrag kein Jobticket beigefügt, so wird am Druckauftragsmanager mittels des Vorgabe-Jobtickets und evtl. weiterer Steuerparameter und der Ticket-Regeln ein drucksystemspezifisches Jobticket erzeugt. Ist dem Druckauftrag hingegen ein Jobticket beigefügt, wird anhand der Ticket-Regeln das Jobticket überprüft, ob es als drucksystemspezifisches Jobticket geeignet ist und ggfs., - was die Regel ist - verändert und insbesondere durch drucksystemspezifische Parameter aus dem Vorgabe-Ticket ergänzt.
Die Erfindung wird nachfolgend beispielhaft näher anhand der Zeichnung erläutert. Die Zeichnung zeigt in:
Figur 1 schematisch den Aufbau eines Drucksystems zum Übertragen von Druckdaten mit einem Großrechner, einem Druckserver und mehreren Druckern, Figur 2 den Druckserver aus Figur 1 mit den Modulen zur Entgegennahme und Bearbeitung von Druckdaten,
Figur 3 ein Diagramm zum Darstellen des zeitlichen Ablaufes des Übertragens und Korrigierens von
Druckdaten eines Druckauftrages,
Figur 4a, 4b jeweils eine Konfiguration mehrerer
Spiegel -Computersysteme ,
Figur 5 eine Tabelle mit einer Parameterliste,
Figur 6a, 6b jeweils eine Konfiguration des
Zugangsprofils für Druckdaten,
Figur 7 eine weitere Tabelle mit Parametern, und
Figur 8 wesentliche Teile zweier Drucksysteme zum Ausführen eines Verfahrens zum Spiegeln von Druckaufträgen schematisch vereinfacht in einem
Blockschaltbild.
Das Verfahren zum automatischen Übertragen von Druckdaten (Fig. 1 bis 7) dient zum Übertragen von Druckdaten von einem Sender 1 zu einem Empfänger 2. Der Sender 1 ist in der Regel ein Mainframe Computer auf dem eine große Datenmenge an Druckdaten erzeugt wird. Diese Druckdaten werden meistens auf mehrere Empfänger 2 verteilt versandt. In Figur 1 ist zur Vereinfachung der Darstellung lediglich ein einziger Sender 1 und ein einziger Empfänger 2 dargestellt .
Die Datenkommunikation zwischen dem Sender 1 und dem Empfänger 2 kann mittels unterschiedlicher Protokolle geregelt sein. Bei Mainframe-Computern von IBM ist das
Download-Protokoll sehr gebräuchlich, das auf das TCP/IP- Protokoll aufsetzt. Bei Unix-Systemen werden Druckdaten mit dem LP-Protokoll (Lineprinter) übertragen. Weitere geeignete Protokolle sind FTP (File Transfer Protocol) und NFS (Network File System) die von Programmmodulen auf den Sender 1 zum automatischen Übertragen der Druckdaten angewandt werden. Die Anmelderin bietet ein solches
Programmmodul HotDir an, das ein Verzeichnis bereitstellt, in dem eingehende Druckdaten am Empfänger automatisch erfasst und weitergeleitet werden.
Im vorliegenden Ausführungsbeispiel ist der Sender 1 ein Großrechner bzw. Mainframe von IBM, der mit dem Betriebssystem OS/390 und dem Downloadprotokoll zum Übertragen der Druckdaten arbeitet. Auf dem Sender 1 sind zwei Druckertreiber 3 „Printer 1" und „Printer 2" installiert, die die Druckdaten zur Übermittlung an einen Drucker aufbereiten und weiterleiten. Ein Druckserver kann für den Großrechner einen solchen Drucker simulieren, so dass er die Druckdaten vom Großrechner empfangen kann. Der Druckserver bzw. Empfänger 2 kann die empfangenen Druckdaten frei an einen von mehreren an den Empfänger 2 angeschlossenen Drucker 4 verteilen.
Der Begriff „Druckertreiber" wird hier nicht im Sinne von den von Personalcomputern bekannten Druckertreibern verwendet, die die Druckdaten derart aufbereiten und gegebenenfalls sogar rastern, damit sie das jeweilige Druckgerät unmittelbar bearbeiten kann. Eine derartige Aufbereitung der Druckdaten findet bei elektrofotografischen Hochleistungsdrucksystemen im Druckserver und/oder in der Steuereinrichtung des jeweiligen Druckgeräts statt. Die Druckertreiber 3 des Senders 1 überprüfen vielmehr die eingehenden Druckdaten, ob sie für das Druckgerät, an dem sie gedruckt werden sollen, geeignet sind und bereiten die Druckdaten zur Übermittlung über ein Netzwerk 5 zum Empfänger 2 vor.
Hierbei können die Druckertreiber 3 Druckdaten für die Übertragung zum Sender 1 vorbereiten, indem bestimmte Dateien zu einem Druckauftrag zusammengestellt werden, diese Dateien komprimiert und eventuell verschlüsselt werden.
Die derart aufbereiteten Druckdaten werden vom Empfänger 2 empfangen. Der vorliegende Empfänger 2 ist ein Druckserver, insbesondere ein PRISMAproduction Druckserver. Dieser Druckserver 2 weist drei unterschiedliche Schnittstellen-Module 6 zum Empfangen von Druckdaten mittels unterschiedlicher Protokolle auf. Eines der Schnittstellen-Module 6 ist zum Empfangen von Daten mittels des Download-Protokolls, das andere zum Empfangen von Daten ist ein HotDir-Verzeichnis und das dritte Schnittstellen-Modul 6 ist zum Empfangen von Daten mittels des LP-Protokolls ausgebildet. Das Schnittstellen-Modul 6 zum Empfangen von Daten mittels des Download-Protokolls wird im Folgenden als Download-Schnittstelle 6 bezeichnet. An diesem Schnittstellen-Modul 6 sind zwei Port-Nummern gemäß dem TCP-Protokoll installiert, mit welchen die Datenströme zwischen dem Sender 1 und dem Empfänger 2 identifiziert werden. Diese Port-Nummern sind fest vergeben (assigned numbers) . Die an den Schnittstellen eingehenden Druckdaten werden im Druckserver 2 an ein Spool -Modul 7 weitergeleitet, das die Druckdaten zwischenspeichert und dann an die einzelnen Drucker 4 überträgt. Die Download-Schnittstelle ist als Programm, das im Hintergrund abläuft, wobei üblicherweise keine direkten Benutzerinterventionen stattfinden, ausgebildet. Derartige Programme bezeichnet man unter Unix und seinen Derivaten als Daemon (Disc and Execution Monitor) . Bei Microsoft Windows heißen die entsprechenden Programme „Services" bzw. „Dienste". Ein Daemon kann auch laufen wenn kein Benutzer am Computer eingeloggt ist.
Figur 2 zeigt die zum Empfangen und Weiterleiten mittels der Download-Schnittstelle relevanten Programmmodule des Druckservers 2 in einem Blockschaltbild etwas ausführlicher. In dem Druckserver 2 ist anschließend an die Download-Schnittstelle 6 ein Puffermodul 8 angeordnet, in dem die eingehenden Druckdaten zwischengespeichert werden. Dem Puffermodul 8 folgt ein Entschlüsselungs- und Dekomprimierungsmodul 9, das die entschlüsselten und dekomprimierten Daten in ein weiteres Puffermodul 10 schreibt. Aus dem Puffermodul 10 liest eine Druckdatenverarbeitungseinheit 11 die hierin gespeicherten Druckdaten aus und führt die notwendigen Verarbeitungsschritte durch.
Die Druckdatenverarbeitungseinheit 11 schreibt die verarbeiteten Druckdaten in einen weiteren Puffer 12, von dem sie in das Spool -Modul 7 geschrieben werden. Die Puffermodule 8, 10, 12 werden alle aus derselben Klasse geerbt und entsprechen der in der Deutschen Patentanmeldung DE 199 57 594 Al bzw. in der korrespondierenden US-amerikanischen Patentanmeldung US 2003/0041086 Al beschriebenen Pufferklasse. Diese Dokumente werden unter Bezugnahme hierin aufgenommen.
Bei dem in Figur 2 gezeigten Ausführungsbeispiel ist das Puffermodul 8 derart ausgebildet, dass es die eingehenden Druckdaten kopiert und über eine Datenleitung 13 an ein Spiegel -Computersystem 14 weiterleitet. Diese Spiegel- Computersystem 14 besteht im einfachsten Fall lediglich aus einer zusätzlichen Festplatte im Druckserver 2. Bevorzugt ist das Spiegel -Computersystem 14 ein Computersystem, das unabhängig vom Druckserver 2 ausgebildet ist. Insbesondere sollte das Spiegel- Computersystem 14 entfernt, vor allem in einem anderen
Gebäude als der Druckserver 2 angeordnet sein. Hierdurch ist sichergestellt, dass bei einer Beeinträchtigung des Druckservers 2 durch Feuer oder dergleichen das Spiegel - Computersystem 14 nicht beeinträchtigt wird und die darauf gespeicherten Druckdaten weiterhin zur Verfügung stehen. Das Puffermodul 8 mit der Kopierfunktion der eingehenden Druckdaten ist vor dem Entschlüsselungs- und Dekomprimierungsmodul 9 angeordnet, so dass die Druckdaten im komprimierten und verschlüsselten Zustand an das Spiegel -Computersystem 14 weitergeleitet werden. Hierdurch wird das über die Datenleitung 13 zu übertragende Datenvolumen gering gehalten und ein schnelles Kopieren der Druckdaten auf das Spiegel -Computersystem 14 ermöglicht .
Das Puffermodul 8 ist derart ausgebildet, dass nach Abschluss des Kopierens der eingegangen Druckdaten dies der Download-Schnittstelle 6 bestätigt wird. Die Download- Schnittstelle 6 führt die Quittierung, dass die Druckdaten korrekt empfangen worden sind, gegenüber dem Sender 1 erst aus, wenn die entsprechende Bestätigung des Puffermoduls 8 vorliegt. Hierdurch ist sichergestellt, dass ein Fehler auf dem Druckserver 2, wie z.B. ein Absturz, nicht dazu führt, dass eingehende Druckdaten gegenüber dem Sender 1 ordnungsgemäß quittiert werden, jedoch nicht auf den
Druckserver 2 in das Spiegel -Computersystem 14 kopiert werden können. Durch diese geringfügige Verzögerung der Quittierung des korrekten Empfangs der eingehenden Druckdaten wird sicher gestellt, dass zumindest am Druckserver 2 oder am Spiegel -Computersysteml4 , selbst beim Auftreten eines Problems an einem der beiden Computer die Druckdaten zur Verfügung stehen, wenn sie gegenüber dem Sender 1 ordnungsgemäß quittiert worden sind.
Die Verzögerung der Quittierung des korrekten Einganges der Druckdaten wird vor allem durch die Übertragung der kopierten Druckdaten über die Datenleitung 13 verursacht. Deshalb ist es besonders vorteilhaft, wenn die Druckdaten im komprimierten Zustand zum Spiegel -Computersystem 14 übertragen werden. Dies ist auch dann vorteilhaft, wenn eine schnelle Datenverbindung verwendet wird. Wie es in Figur 2 durch die strichlinierte Datenleitung 13 angedeutet ist, können bei einer alternativen Ausführungsform der vorliegenden Erfindung die eingehenden Druckdaten auch in der Download-Schnittstelle 6 kopiert und von dort an das Spiegel -Computersystem 14 weitergeleitet werden. Eine solche Ausführungsform hat den Vorteil, dass die Spiegelung und Quittierung von einem einzigen Modul, der Download-Schnittstelle 6, kontrolliert wird. Hierdurch kann einfach eine mit dem Spiegeln der Druckdaten synchrone Quittierung realisiert werden.
Alternativ ist es auch möglich, ein zusätzliches Kopiermodul zwischen der Download-Schnittstelle 6 und dem Puffermodul 8 vorzusehen, dessen einzige Aufgabe es ist, die Druckdaten zu kopieren und an das Spiegel - Computersystem 14 weiterzuleiten.
Bei einer Weiterbildung der vorliegenden Erfindung ist es auch möglich, nach bestimmten Bearbeitungsvorgängen, insbesondere am Ausgang des Empfängers 2 die Druckdaten auf das Spiegel -Computersystem 14 zu kopieren. In Figur 2 ist beispielhaft eine Datenverbindung 15 mit einer strichlinierten Linie vom Puffermodul 12 zum Spiegel- Computersystem 14 dargestellt. Das Puffermodul ist derart ausgebildet, dass alle mit dem Puffermodul 12 gespeicherten Druckdaten, bevor sie an das Spool -Modul 7 weitergeleitet werden, über die Datenverbindung 15 auf das Spiegel -Computersystem 14 kopiert werden. Die Datenverbindung 15 ist logisch eine unabhängige Datenverbindung von der Datenverbindung 13. Diese beiden
Datenverbindungen verwenden selbstverständlich die gleiche physikalische Datenleitung. Eine solche zusätzliche Spiegelung der Druckdaten ist insbesondere zweckmäßig, wenn eine aufwendige Bearbeitung der Druckdaten am Empfänger 2 erfolgt. Zum Beispiel können am Empfänger 2 die Druckdaten gerastert werden, was selbst bei den heute zur Verfügung stehenden Rechenleistungen bei großen Druckaufträgen einige Stunden in Anspruch nehmen kann. Diese gerasterten Druckdaten können somit auf das Spiegel - Computersystem 14 kopiert werden. Im Rahmen der Erfindung ist es auch möglich, an mehreren Stellen im Empfänger 2, insbesondere an allen Puffer-Modulen 8, 10, 12 eine derartige Kopierfunktion vorzusehen.
Das System zum automatischen Übertragen von Druckdaten, bei dem die Druckdaten auf ein Spiegel -Computersystem kopiert werden, unterscheidet sich von herkömmlichen
Spiegelverfahren grundsätzlich darin, dass nicht jeder beliebige Schreibvorgang auf ein Speichermedium, insbesondere der Festplatte des Empfängers 2, auf das Spiegel -Computersystem 14 kopiert wird, sondern zum einen nur vorbestimmte Daten, nämlich die Druckdaten, kopiert werden und zum anderen diese Daten nur an bestimmten Prozessstationen kopiert werden. Hierdurch wird der notwendige Datentransfer zwischen dem Empfänger 2 und dem Spiegel -Computersystem 14 im Vergleich zu herkömmlichen Spiegelverfahren gering gehalten.
Die Anwahl/Festlegung der zu kopierenden bzw. zu sichernden Daten und/oder der Spiegel -Computersysteme 14 kann insbesondere durch einen Benutzer menügeführt erfolgen. Das gezielte Kopieren vorbestimmter Daten an bestimmten Prozessstellen im Prozessablauf des Empfängers 2 bewirkt einen weiteren Vorteil gegenüber herkömmlichen Spiegelverfahren. So können am Empfänger 2 und am Spiegel - Computersystem 14 unterschiedliche Rechte für den Benutzer zum Bearbeiten der Druckdaten vergeben werden. Ein Benutzer kann z.B. das Recht haben, am Empfänger 2 Druckdaten zu löschen. Dieses Recht muss sich jedoch nicht automatisch auf das Spiegel -Computersystem 14 erstrecken. Löscht ein Benutzer versehentlich am Empfänger 2 Druckdaten, so bestehen sie am Spiegel -Computersystem 14 weiterhin fort. Weiterhin ist es möglich, eine Löschfunktion am Empfänger 2 derart auszubilden, dass sie automatisch zeitlich versetzt am Spiegel -Computersystem 14 ausgeführt wird. Der Zeitversatz kann zwischen einigen Stunden und einigen Tagen betragen. Hierdurch ist sichergestellt, dass nach einem versehentlichen Löschen die Daten am Spiegel -Computersystem 14 zumindest noch einige Zeit zur Verfügung stehen.
Nachfolgend wird der Ablauf des Verfahrens zum automatiscen Übertragen von Druckdaten anhand des in Figur 3 gezeigten Diagramms erläutert.
In diesem Beispiel wird ein zwei Druckdateien (Datafile 1, Datafile 2) umfassender Druckauftrag vom Sender 1 an den Empfänger 2 übermittelt. In Figur 3 ist die Schnittstelle vom Sender 1 zum Netzwerk 5 mit MF (Mainframe) , die
Schnittstelle zwischen dem Netzwerk 5 und dem Empfänger I- PS (Input Printserver) und die Schnittstelle des Empfängers 2 mit der zum Spiegel -Computersystem 14 (M) führenden Datenleitung 13 mit O-PS (Output Printserver) bezeichnet.
Die erste Druckdatei (Datafile 1) wird mit dem Schritt Sl (siehe Pfeil in Figur 3) vom Sender zum Empfänger übertragen. Im Empfänger wird die erste Druckdatei kopiert und zum Spiegelsystem mit dem Schritt S2 übertragen. Das
Spiegel -Computersystem quittiert den korrekten Empfang der Druckdatei 1 im Schritt S3. Hierauf wird vom Empfänger an den Sender der korrekte Empfang der Druckdatei quittiert (Schritt S4) .
Die gleichen Schritte Sl bis S4 werden zum Übertragen der zweiten Druckdatei (Datafile 2) ausgeführt. Falls der Druckauftrag mehr als zwei Druckdateien umfasst, werden die Schritte Sl bis S4 zum Übertragen jeweils einer Druckdatei entsprechend oft wiederholt. Sind alle Druckdateien korrekt übertragen worden, so wird im Empfänger mit dem Schritt S5 die Ausführung des Druckauftrages gestartet, wobei die Druckdateien an das entsprechende Druckgerät übermittelt werden. Der Empfänger erhält dann nach Ausführung des Druckauftrages vom
Druckgerät eine entsprechende Bestätigung (Schritt S6) .
Das Verfahren zum automatischen Übertragen von Druckdaten ist oben anhand eines Ausführungsbeispieles erläutert, bei welchem die Daten vom Sender zum Empfänger mittels des
Download-Protokolls übertragen werden, wobei der Empfang jeweils einer Druckdatei quittiert wird. Bei Verwendung von Checkpoints erfolgt die Quittierung nach dem korrekten Empfang und dem korrekten Kopieren bzw. Spiegeln einer Dateneinheit der Druckdaten, die durch einen Checkpoint oder das Ende der Druckdatei begrenzt ist. Die zu übertragende und zu kopierende Dateneinheit ist somit nicht immer eine vollständige Druckdatei, sondern kann auch aus Abschnitten einer Druckdatei bestehen.
Sollten beim Speichern der Druckdaten auf dem Empfänger bzw. Druckserver Probleme entstehen, kann das aus dem Druckserver und dem Spiegel -Computersystem bestehende System derart ausgebildet sein, dass das Spiegel- Computersystem automatisch als Druckserver verwendet wird. Hierzu ist das Spiegel -Computersystem mit allen Funktionen bzw. Programm-Modulen des Druck-Servers, die zur Weiterleitung und Bearbeitung der Druckdaten notwendig sind, zu versehen.
Grundsätzlich wird der korrekte Empfang der Druckdaten erst nach dem Kopieren der Druckdaten auf das Spiegel - Computersystem quittiert. Falls das Kopieren der Druckdaten nicht korrekt ausgeführt werden kann, wird die gesamte Übertragung der Druckdaten abgebrochen. Bei einer alternativen Ausführungsform ist es jedoch auch möglich, dass der Empfänger an den Sender den korrekten Empfang der Druckdaten quittiert, selbst wenn die Druckdaten nicht korrekt auf das Spiegel -Computersystem kopiert werden konnten sofern die Druckdaten korrekt empfangen und auf dem Empfänger korrekt gespeichert worden sind. Nach dem Beheben des Fehlers, der die Ursache des nicht korrekten Kopierens war, ist es möglich, die nicht kopierten Druckdaten nachträglich auf das Spiegel -Computersystem zu kopieren.
Das System zum automatischen Übertragen von Druckdaten kann auch mit mehreren Spiegel -Computersystemen versehen sein. Die Druckdaten können hierbei gleichzeitig auf die mehreren Spiegel -Computersysteme kopiert werden. Es ist jedoch auch möglich, die Druckdaten lediglich auf ein einzelnes Spiegel -Computersystem zu kopieren und falls es hierbei Probleme geben sollte, werden die Druckdaten auf ein anderes Spiegel -Computersystem kopiert, damit deren korrekte Speicherung sichergestellt ist.
Wenn mehrere Spiegel -Computersysteme vorhanden sind, ist es auch möglich, dass an einem bestimmten Spiegel- Computersystem beim Auftreten eines Fehlers das Kopieren nur fortgesetzt wird, wenn mindestens eine vorbestimmte Anzahl n Kopien der zu sichernden Daten auf den mehreren Spiegel -Computersystemen erfolgreich erstellt werden konnten.
Auf Fehler (error reaction) kann somit nach den unten aufgeführten Regeln reagiert werden. Diese Regeln für einen Fehlerfall werden am Empfänger 2 konfiguriert. Diese Konfiguration einer bestimmten Regel erfolgt jeweils für ein bestimmtes Spiegel -Computersystem 14. Die Regeln sind:
(1) Abbruch der Datenübertragung vom Sender zum Empfänger, wenn ein Fehler beim Kopieren auf dem konfigurierten Spiegel -Computersystem auftritt. (2) Fortsetzen der Datenübertragung vom Sender zum Empfänger, selbst bei einem Fehler auf dem konfigurierten Spiegel -Computersystem.
(3) Fortsetzen der Datenübertragung vom Sender zum
Empfänger nur wenn n Kopien der zu sichernden Daten erfolgreich erstellt worden sind.
(4) Umschalten des Kopiervorganges auf ein vorbestimmtes anderes Spiegel -Computersystem, wenn ein Fehler an dem konfigurierten Spiegel -Computersystem auftritt.
(5) Verwenden als Ersatz -Spiegel -Computersystem (Standby Mirror Server) , das nur verwendet wird, wenn entweder am Empfänger oder an einem anderen Spiegel - Computersystem ein Fehler auftritt.
Im Fehlerfall gibt es zwei Möglichkeiten, wie ein Fehler an einem Spiegel -Computersystem behoben werden kann (error recovery) . Zum einen kann versucht werden, alle Druckdaten bzw. Dateneinheiten die seit Auftreten des Fehlers am Empfänger empfangen worden sind, auf das Spiegel - Computersystem zu kopieren. Zum anderen kann das Spiegel - Computersystem auch derart konfiguriert sein, dass die seit dem Auftreten des Fehlers empfangenen Druckdaten nicht mehr auf dieses Spiegel -Computersystem kopiert werden.
Figur 4a zeigt ein Konfigurationsbeispiel mit drei Spiegel -Computersystemen die als Primary-Mirror, Secondary 1 -Mirror und Secondary 2 -Mirror bezeichnet werden. Wenn ein Fehler beim Kopieren auf den Primary-Mirror auftritt wird die Datenübertragung vom Sender zum Empfänger abgebrochen. Die Druckdaten bzw. die entsprechende Dateneinheit muss nochmals übertragen werden. Wenn auf dem Secondary 1-Mirror ein Fehler auftritt, wird die Datenübertragung unverändert fortgesetzt. Nach Beheben des Fehlers werden alle zwischenzeitlich am Empfänger empfangenen und dort gespeicherten Druckdaten auf dem Secondary 1-Mirror kopiert.
Beim Secondary 2-Mirror wird bei einem Fehler die Übertragung der Daten vom Sender auf den Empfänger fortgesetzt. Nach Beheben des Fehlers auf dem Secondary 2- Mirror werden die zwischenzeitlich empfangenen Daten jedoch nicht mehr auf diesen kopiert.
Figur 4b zeigt eine zweite Konfiguration. Diese Konfiguration umfasst 4 Spiegel -Computersysteme die mit Mirror 1, Mirror 2, Mirror 3 und Mirror 4 bezeichnet sind. Der Mirror 4 bildet ein Ersatz-Spiegel-Computersystem zum Mirror 3. Der Mirror 1 ist derart konfiguriert, dass die Datenübertragung vom Sender zum Empfänger fortgesetzt wird, selbst wenn ein Fehler an diesem Spiegel- Computersystem auftritt. Der Mirror 2 ist derart konfiguriert, dass die Datenübertragung vom Sender zum Empfänger abgebrochen wird, wenn an diesem Spiegel - Computersystem ein Fehler auftritt und nicht zumindest zwei Kopien erfolgreich erstellt werden konnten. Dies bedeutet, dass die Datenübertragung unterbrochen wird, wenn am Mirror 2 ein Fehler auftritt und der Mirror 1 ausfällt oder der Mirror 3 und sein Ersatz-Spiegel- Computersystem (Mirror 4) ausfällt. Weiterhin wird die Datenübertragung abgebrochen, wenn der Mirror 4 ausfällt.
Da die Regeln für ein jedes Spiegel -Computersystem individuell konfiguriert werden, kann grundsätzlich eine beliebige Anzahl von Spiegel -Computersystemen vorgesehen werden und in unterschiedlichster Weise zusammenwirken.
Bei einer vorteilhaften Weiterbildung des Empfängers ist dessen Schnittstellen-Modul derart ausgebildet, dass es die eingehenden Druckdaten zunächst überprüft, ob sie von einem korrekten Sender stammen, indem das Schnittstellen- Modul die Druckdaten anhand von mehreren Parametern, die gemäß dem Protokoll, mit dem die Druckdaten vom Sender zum Empfänger übertragen werden, in einem Header enthalten sind. Die Korrektheit der Druckdaten wird überprüft, bevor diese durch das Schnittstellen-Modul auf dem Empfänger gespeichert werden. Dieser Aspekt der vorliegenden Erfindung stellt einen selbständigen Erfindungsgedanken dar.
Im vorliegenden Ausführungsbeispiel werden die Druckdaten mittels des Download-Protokolls in Verbindung mit dem TCP/IP Protokoll übertragen. In Figur 4 ist eine Tabelle mit typischen Parametern zum Überwachen der korrekten
Druckdaten dargestellt. Der Parameter „remote hosts" ist im Header des TCP/IP Protokolls. Alle übrigen Parameter aus der Tabelle in Figur 4 sind im Header des Download- Protokolls angegeben. Die Parameter „local ports" und „remote hosts" stellen allgemeine Adressdaten. Derartige Adressdaten werden in Firewall-Programmen zum Überwachen der Korrektheit der entsprechenden Daten verwendet. Die weiteren Parameter „remote users", „remote printers", „remote class" und „remote forms" sind spezifische Parameter für den Druckauftrag bzw. den hierbei zu verwendenden Drucker bzw. zum Benutzer. Derartige spezifischen Parameter werden in Firewall-Programmen nicht zum Überprüfen der eingehenden Daten verwendet . Zum Überwachen der Druckdaten sind die Parameter „remote class" und „remote forms" besonders spezifisch, da diese beiden Parameter den Inhalt der Druckdaten bzw. des Druckauftrages mitbestimmen. So gibt der Parameter „remote forms" an, welche Formulare verwendet werden. Der Parameter „remote class" beschreibt z.B. eine bestimmte Druckerschlange in einem bestimmten Empfänger. Diese
Druckerschlange ist zum Übertragen von Druckdaten an einen bestimmten Drucker oder an eine bestimmte Gruppe von Druckern vorgesehen.
Figur 6a zeigt ein Konfigurationsbeispiel, wobei als Platzhalter ein „Stern" verwendet wird, für den beliebige Werte in die Parameter eingesetzt werden können. Die Konfiguration nach Figur 5a bedeutet somit, dass alle Benutzer ihre Druckdaten mit beliebigen Ports auf beliebige Druckgeräte übermitteln können, sofern ihre IP- Adresse mit „10.54." beginnt.
Bei der Konfiguration nach Figur 6b kann der Benutzer „Natia" vom Drucker „P910" am Sender „Testserver.nowhere.com" Daten auf den Port 5055 übermitteln. Der Benutzer, dessen Name mit „Prod" beginnt, kann vom Sender „Testserver.anywhere.org" seine Druckdaten über den Port 5056 auf das Druckgerät „P950" übermitteln.
Der Benutzer „Admin" kann jeden beliebigen Drucker verwenden, der mit einem „P" beginnt und seine Druckdaten vom Sender „Domain Server" auf einen beliebigen Port übermitteln.
Für die Erfindung ist von Bedeutung, dass der Empfänger die Regeln, nach welchen die Druckdaten zum Empfang zugelassen werden, frei anhand der Parameter aus den Headern definieren kann. Die in obigem Beispiel aufgeführten Parameter werden bevorzugt verwendet . Grundsätzlich können aber auch andere in den Headern aufgeführte Parameter verwendet werden. Figur 7 zeigt eine Liste weiterer derartige JCL-Parameter (JCL: Job Control Language) . Diese Tabelle ist dem Handbuch von IBM zu Print Services Facility for OS/390 & z/OS, Download for OS/390, Version 3, Release 3.0 (S544-5624-02) , 2002 entnommen.
Bei den oben erläuterten Ausführungsbeispielen der vorliegenden Erfindung wird eine Vorrichtung zum Empfangen von Druckdaten (Empfänger 2) verwendet, die als Druckserver ausgebildet ist. Ein solcher Druckserver ist ein Computer mit einer Prozessoreinheit, einer Speichereinheit und einem Computerprogramm, das zum Empfangen, Bearbeiten und Weiterleiten von Druckdaten dient. Das Computerprogramm ist zum Ausführen des Verfahrens zum automatischen Übertragen von Druckdaten ausgebildet .
Die Erfindung selbst kann auch als Computerprogramm- Produkt realisiert werden, das auf einem Datenträger gespeichert ist.
Mit dem Verfahren zum Spiegeln von Druckaufträgen (Fig. 8) werden an einem Druckserver 101 eines ersten Drucksystems I eingehende Druckaufträge automatisch auf einen Druckserver 101 eines zweiten Drucksystems II gespiegelt.
Die Druckserver 101 weisen jeweils einen Druckauftragsmanager 102 (DAM), mehrere Clients 103, ein Puffermodul 104 (PM) , ein Dekomprimierungsmodul 105 (DE) , eine Speichereinheit 106 (SP) und ein Spoolmodul 107 (SM) auf (Figur 1) .
Im vorliegenden Ausführungsbeispiel sind drei unterschiedliche Typen von Clients (CL) vorgesehen, nämlich Inputmodule 103/1, ein Druckauftrag-Client 103/2 und ein Ticket-Regel-Client 103/3.
Üblicherweise sind mehrere Inputmodule 103/1 vorgesehen, die jeweils mit einem oder mehreren Rechnern 108 (RE) zum Erzeugen eines Druckauftrages über Datenleitungen 109 verbunden sind. Die Inputmodule 103/1 dienen zum Empfangen von Druckdaten mittels Protokollen. Ein solches Inputmodul 103/1 kann bspw. zum Empfangen von Druckdaten mittels des Download-Protokolls oder des LP-Protokolls ausgebildet sein. Ein solches Inputmodul kann auch ein HotDir- Verzeichnis sein. Die Download-Schnittstelle ist als Programm, das im Hintergrund abläuft, wobei üblicherweise keine direkten Benutzerinterventionen stattfinden, ausgebildet. Derartige Programme bezeichnet man unter Unix und seinen Derivaten als Daemon (Disc and Execution Monitor) . Bei Microsoft Windows heißen die entsprechenden Programme „Services" bzw. „Dienste". Ein Daemon kann auch laufen, wenn kein Benutzer am Computer eingeloggt ist.
Typischerweise sind der Druckauftragsmanager 102 und die Inputmodule 103/1 bei einem Betreiber eines Druckzentrums angeordnet und die Rechner 108 zum Erzeugen der Druckaufträge stehen bei den Kunden des Betreibers des Drucksystems und übermitteln über ein Netzwerk, wie zum Beispiel das Internet, ihre Druckaufträge an die Inputmodule.
Die Clients 103 und der Druckauftragsmanager 102 sind jeweils Computerprogrammeinheiten. Sie können auf einem gemeinsamen Computer installiert und ausgeführt werden. Es ist jedoch gleichermaßen möglich, zumindest den Druckauftragsmanager 102 und die Clients 103 auf zumindest zwei separaten Computern zu installieren und dort auszuführen.
Der Druckauftragsmanager wird auch als PJM-Server (Printjob-Manager-Server) bezeichnet. Der zum Druckauftragsmanager 102 korrespondierende Druckauftrags- Client 103/2 ist mit diesem über eine Schnittstelle 110 verbunden und dient dazu, dass der Operator des Drucksystems bereits vorliegende Druckaufträge ausführen kann. Derartige Druckaufträge sind zum Beispiel Druckaufträge, die nicht oder nicht korrekt gedruckt werden konnten. Der Operator kann mit Hilfe des Druckauftrag-Clients 103/2 den Druckauftrag und insbesondere das Jobticket eines solchen Druckauftrages verändern und den jeweiligen Druckauftrag zum Druckauftragsmanager 102 übermitteln, um ihn an einem Druckgerät 111 (DR) drucken zu lassen.
Bei den Inputmodulen 103/1 eingehende Druckaufträge, werden über eine Schnittstelle 116 an das Puffermodul 104 weiter geleitet und dort zwischengespeichert. Die zwischengespeicherten Druckaufträge liest das Dekomprimierungsmodul 105 aus und dekomprimiert die Daten. Vorzugsweise ist das Dekomprimierungsmodul 105 auch mit einer Entschlüsselungsfunktion ausgebildet, so dass es die Daten auch entschlüsselt. Die dekomprimierten und entschlüsselten Druckdaten werden in der Speichereinheit 106 abgespeichert.
Die in der Speichereinheit 106 gespeicherten Druckaufträge werden vom Druckauftragsmanager 102 gelesen, um an das Spoolmodul 107 weiter geleitet zu werden.
Der Druckauftragsmanager dient unter anderem zum Überprüfen von in den Druckaufträgen enthaltenen Auftragsbegleitdaten und zum Erzeugen von für das jeweilige Drucksystem spezifischen Jobtickets.
Der Druckauftragsmanager 102 ergänzt die Auftragsbegleitdaten der eingehenden Druckaufträge mit Daten, insbesondere Steuerparametern, aus einem Vorgabe- Jobticket. Insbesondere werden den Auftragsbegleitdaten fehlende, aber bei der vorhandenen Druckumgebung notwendige Steuerparameter hinzugefügt. Falls ein Gesamtauftragsticket vorhanden sein sollte, werden auch die Daten, insbesondere Steuerparameter des Gesamtauftragstickets dem drucksystemspezifischen Jobticket hinzugefügt.
Der Druckauftragsmanager 102 weist ein Ticket-Regelmodul 112 (TRM) auf, in dem Ticket-Regeln gespeichert sind. Die Ticket-Regeln werden mittels des Ticket-Regel-Moduls verwaltet und am Druckauftragsmanager zur Ausführung gebracht .
Das Ticket-Regel-Modul 112 weist eine Schnittstelle 113 zum Ticket-Regel-Client 103/3 auf, über die eine bidirektionale Kommunikation möglich ist. Der Ticket- Regel-Client 103/3 umfasst ein Regel-Editor-Modul, mit dem die im Ticket-Regel-Modul gespeicherten Ticket-Regeln editiert werden können. Das Regel -Editor-Modul ist mit einer graphischen Benutzeroberfläche (GUI) versehen.
Das Ticket-Regel-Modul 112 kann auch mit mehreren Ticket- Regel-Clients 103/3 verbunden sein. Es werden jedoch alle Ticket-Regeln ausschließlich im Ticket-Regel -Modul 112 am Druckauftragsmanager 102 gespeichert. Mit den Ticket- Regel-Clients 103/3 kann lediglich auf die im Ticket- Regel-Modul 112 gespeicherten Ticketregeln zugegriffen und diese dort verändert werden.
Das Jobticket enthält eine Liste von Steuerparametern zum Steuern des jeweiligen Druckauftrages.
Die Ticket-Regeln umfassen eine Folge von Aktionen, die auf eingehende Auftragsbegleitdaten des empfangenen Druckauftrages angewandt werden.
Die an einem ersten Drucksystem I eingehenden Druckaufträge werden vom Puffermodul 104 kopiert und die Kopie wird über eine Datenleitung 114 zu einem Inputmodul 103/1 eines zweiten Drucksystems II übertragen. Diese Kopie enthält die Druckaufträge im komprimierten und verschlüsselten Zustand. Dies ist für die Übertragung vom Drucksystem I zum Drucksystem II vorteilhaft, da diese beiden Drucksysteme normalerweise weit entfernt voneinander angeordnet sind und die komprimierten Daten wesentlich schneller übertragen werden können als nicht komprimierte Daten.
Im übrigen wird bzgl . des Verfahrens der Spiegelung der Druckdaten vom Drucksystem I auf das Drucksystem II Bezug auf die Deutsche Patentanmeldung DE 10 2006 044 870.7 genommen und diese vollinhaltlich in die vorliegende Patentanmeldung einbezogen.
Die gespiegelten Druckdaten werden im zweiten Drucksystem II über das Inputmodul 103/1, das Puffermodul 104, das Dekomprimiermodul 105 in die Speichereinheit 106 geschrieben.
Am ersten Drucksystem I werden die eingehenden Druckdaten auch vom Dekomprimierungsmodul 105 dekomprimiert und entschlüsselt und dann in die Speichereinheit 106 gespeichert. Zu den jeweiligen Druckaufträgen werden vom Druckauftragsmanager 102 des ersten Drucksystems I drucksystemspezifische Jobtickets anhand der Auftragsbegleitdaten erstellt. Dies erfolgt grundsätzlich in der gleichen Weise, wie es in der am 28. Februar 2007 hinterlegten Deutschen Patentanmeldung „Verfahren, Drucksystem und Computerprogramm zum automatischen Bearbeiten von Auftragsbegleitdaten eines Druckauftrags" beschrieben ist, weshalb diesbezüglich auf diese Patentanmeldung Bezug genommen wird.
Bei einer ersten Ausführungsform der Erfindung wird das für das erste Drucksystem I spezifische Jobticket auf den Druckserver des zweiten Drucksystems II gespiegelt. Dieses Jobticket wird dann als Spiegel-Jobticket bezeichnet. Dies ist vor allem dann zweckmäßig, wenn das zweite Drucksystem II die gleichen Ressourcen und Druckgeräte wie das erste Drucksystem I aufweist. Dann kann der Druckauftrag unmittelbar am zweiten Drucksystem ausgeführt werden.
Zum Spiegeln der Spiegel-Jobtickets sind die Druckauftragsmanager 102 der beiden Drucksysteme I und II mit einer Datenverbindung 115 aneinander gekoppelt. Die Datenverbindung weist Schnittstellen zu den beiden Druckauftragsmanagern 102 auf. Physikalisch beruht diese Datenverbindung 115 jedoch auf den gleichen Leitungen wie die Datenleitung 114 zum Spiegeln der eingehenden Druckdaten. Da am zweiten Drucksystem II die Druckdaten zusammen mit den für das erste Drucksystem I spezifischen Spiegel-Jobticket vorgehalten werden, kann bei einem vorübergehenden Ausfall des ersten Drucksystems I, bei dem die am ersten Drucksystem I gespeicherten Druckdaten beschädigt werden, diese zusammen mit dem Spiegel- Jobticket vom Druckserver 101 des zweiten Drucksystems II zurück zum Druckserver 101 des ersten Drucksystems I kopiert werden und am ersten Drucksystem I ohne weitere Verzögerung zur Ausführung gebracht werden.
Nach einer zweiten Ausführungsform des Verfahrens zum Spiegeln von Druckaufträgen wird am Druckserver 101 des ersten Drucksystems I neben dem für das erste Drucksystem I spezifischen Jobticket ein zweites, für das zweite Drucksystem II spezifische Jobticket erstellt. Dieses zweite Jobticket wird auf dem Druckserver 101 des zweiten Drucksystems II gespiegelt und stellt somit ein Spiegel- Jobticket dar. Hierzu wird am Druckserver 101 des ersten Drucksystems I ein für das zweite Drucksystem II spezifisches Vorgabe-Jobticket vorgehalten, dessen Steuerparameter zum Ergänzen der Auftragsbegleitdaten zum Erstellen des für das zweite Drucksystem II spezifischen Jobtickets verwendet werden. Das Überprüfen der Auftragsbegleitdaten und Erzeugen des für das zweite Drucksystem II spezifischen Jobtickets wird mittels der im Ticket-Regel-Modul 112 gespeicherten Ticket-Regeln ausgeführt. Die Ticket-Regeln können für das jeweilige
Drucksystem spezifische Steuerungsparameter enthalten, die sie in ein spezifisches Jobticket eintragen.
Tritt ein Problem am ersten Drucksystem I auf, so kann am zweiten Drucksystem II der Ausdruck des Druckauftrags mit dem für das zweite Drucksystem II spezifischen Spiegel- Jobticket ohne Verzögerung vorgenommen werden.
Bei einer dritten Ausführungsform des Verfahrens zum Spiegeln von Druckaufträgen werden sowohl ein für das erste Drucksystem I spezifisches Spiegel-Jobticket als auch ein für das zweite Drucksystem II spezifisches Spiegel-Jobticket am ersten Drucksystem I erzeugt und beide auf den Druckserver 101 des zweiten Drucksystems II gespiegelt. Bei einem Problem am Druckserver 101 des ersten Drucksystems I besteht sowohl die Möglichkeit, die Druckdaten mit dem entsprechenden Jobticket zurück auf das erste Drucksystem I zu kopieren, oder die Druckdaten unmittelbar am zweiten Drucksystem II auszudrucken. Bei dieser Ausführungsform ist es zudem vorteilhaft, wenn auch am Druckserver des ersten Drucksystems I beide Spiegel - Jobtickets gespeichert werden, da dann an beiden Drucksystemen alle Daten zum Durchführen eines Ausdrucks an einem beliebigen der beiden Drucksysteme I und II vorhanden sind.
Bei einer vierten Ausführungsform des Verfahrens zum Spiegeln von Druckaufträgen werden am Druckserver 101 des ersten Drucksystems I aus den Druckdaten die Auftragsbegleitdaten extrahiert und entweder unmittelbar an den Druckserver 101 des zweiten Drucksystems II oder nach einer Vorverarbeitung an den Druckserver 101 des zweiten Drucksystems II übermittelt. Am Druckserver 101 des zweiten Drucksystems II wird dann aus diesen Auftragsbegleitdaten ein für das zweite Drucksystem II spezifisches Jobticket erzeugt. Die Extraktion der Auftragsbegleitdaten kann einfach durch ein Kopieren der als Datei in Form eines Daten-Tickets vorhandenen Auftragsbegleitdaten erfolgen. Die Extraktion kann jedoch auch das Sammeln von Auftragsbegleitdaten aus unterschiedlichen Quellen, insbesondere dem Dateiname des Druckauftrags und einen oder mehreren Auftragsbegleitdaten enthaltende Dateien umfassen. Die Vorverarbeitung dieser Auftragsbegleitdaten kann z.B. ein Zusammenfassen der Daten aus unterschiedlichen Quellen in einer gemeinsamen Datei beinhalten. Diese Vorverarbeitung kann jedoch auch die Erzeugung des für das erste Drucksystem I spezifischen Jobtickets sein, das an den Druckserver 101 des zweiten Drucksystems II weitergeleitet wird und dort in ein für das zweite Drucksystem II spezifisches Jobticket umgesetzt wird. Das am zweiten Drucksystem II erzeugte und für das zweite Drucksystem II spezifische Jobticket kann wiederum auf den Druckserver 101 des ersten Drucksystems I gespiegelt werden. Gleichermaßen ist es zweckmäßig, das für das erste Drucksystem I spezifische Jobticket auf das zweite Drucksystem II zu kopieren.
Allen oben beschriebenen Ausführungsformen ist gemeinsam, dass die gespiegelten Druckaufträge und die korrespondierenden Jobtickets am zweiten Drucksystem II so lange gesperrt sind, bis die Datenverbindung zwischen den gespiegelten Drucksystemen unterbrochen ist oder wenn die Sperrung manuell aufgehoben wird, gesperrt sind, so dass sie dort während der Sperrung nicht zur Ausführung gebracht werden können. Erst nach Ablauf dieser Zeitdauer kann ein Operator des zweiten Drucksystems II den Ausdruck des jeweiligen Druckauftrags starten oder die entsprechenden Druckdaten zusammen mit dem entsprechenden Jobticket zurück an das erste Drucksystem I übermitteln. Dies muss manuell gestartet werden, damit nicht aus Versehen ein Druckauftrag an zwei unterschiedlichen Drucksystemen gleichzeitig ausgeführt wird, was zu erheblichen Unkosten führen würde. Der Operator kann sich vor dem Starten des gespiegelten Druckauftrags über den Zustand der jeweiligen Drucksysteme informieren.
Da die gespiegelten Druckdaten in herkömmlicher Weise über das Inputmodul 103/1 dem zweiten Drucksystem II zugeführt werden, und die Information, dass die Druckdaten gesperrt sind, bereits im Puffermodul 104 des ersten Drucksystems I den Druckdaten hinzugefügt wird, muss der Druckserver 101 des zweiten Drucksystems II nicht speziell für die Verwendung als Spiegel -Server konfiguriert werden. Er bearbeitet die vom Druckserver 101 des ersten Drucksystems I eingehenden gespiegelten Druckdaten genauso wie alle anderen eingehenden Druckdaten. Am zweiten Druckserver II ist zur Ausführung des Spiegelungsverfahrens lediglich am Druckauftragsmanager 102 eine Schnittstelle zur
Datenverbindung 115 ausgebildet. Diese Schnittstelle ist jedoch gleichermaßen am Druckauftragsmanager 102 des ersten Druckservers 101 angeordnet. Es ist auch möglich, dass die Druckserver 101 der beiden Drucksysteme sich gegenseitig die jeweiligen Druckaufträge spiegeln, wobei dies auch gleichzeitig erfolgen kann. Jedoch werden gesperrte Druckaufträge nicht gespiegelt, denn ansonsten würden sich die beiden Druckserver mit einem einzigen Druckauftrag durch das permanente hin und her Spiegeln eines Druckauftrages gegenseitig blockieren.
Es ist auch möglich, die Spiegelung von einem Ausgangs- Druckserver zu mehreren Spiegel -Druckservern auszuführen, an welchen jeweils eine Kopie der Druckdaten und der entsprechenden spezifischen bzw. nicht-spezifischen Jobtickets hinterlegt werden.
Am ersten Drucksystem I werden die in den Druckaufträgen enthaltenen Druckdaten verarbeitet. Diese Verarbeitung kann unterschiedliche Bearbeitungsvorgänge, wie z.B. das Rastern der in den Druckaufträgen enthaltenen Druckdaten, das Anpassen der Druckseitenanordnung entsprechend der an das Drucksystem angeschlossenen Nachverarbeitungsgeräte umfassen.
Das Rastern der Druckdaten ist ein sehr arbeitsintensiver Vorgang, der lange dauern kann. Es ist deshalb zweckmäßig, dass in Abhängigkeit vom Verarbeitungsfortschritt ein neues Jobticket erzeugt wird, das speziell für die restlichen abzuarbeitenden Bearbeitungsschritte Informationen enthält bzw. Informationen enthält, die den bereits abgearbeiteten Teil erkennen lassen.
Beispielsweise können in einem solchen Jobticket Informationen hinterlegt sein, welche Teile eines Druckauftrags, die einen Rasterprozess (RIP) im Druckserver benötigen, wie z.B. Post-Skript-Daten, bereits verarbeitet worden sind. Dieses den
Verarbeitungsfortschritt widerspiegelnde Jobticket wird zweckmäßigerweise als Spiegel -Jobticket auf dem Druckserver 101 des zweiten Drucksystems II gespiegelt. Vorzugsweise werden auch die bereits verarbeiteten Druckdaten auf den Druckserver 101 des zweiten
Drucksystems II kopiert. Hierdurch ist es möglich, bei einem Problem am ersten Drucksystem I die Abarbeitung des jeweiligen Druckauftrags mit dem bereits erzielten Verarbeitungsfortschritt am zweiten Drucksystem II fortzusetzen.
Grundsätzlich befinden sich die Druckaufträge am Druckserver 101 des ersten Drucksystems I im Ausführungszustand, wohingegen die auf dem Druckserver 101 des Spiegel -Drucksystems II gespiegelten Druckaufträge sich im blockierten Ruhezustand befinden. Diese beiden Druckserver 101 sind derart miteinander synchronisiert, dass, wenn ein im Ausführungszustand befindlicher Druckauftrag vom Operator gelöscht wird, automatisch der korrespondierende gespiegelte Druckauftrag auch gelöscht wird, diese Synchronisation wird aufgehoben, wenn die Datenleitung 114 bzw. die Datenverbindung 115 zwischen den beiden Drucksystemen I, II unterbrochen ist. Eine solche Unterbrechung führt zum Aufheben der Blockierung des gespiegelten Druckauftrags beim Spiegel -Drucksystem II.
Weiterhin ist es möglich, das im Puffermodul 104 ausgeführte Spiegelverfahren unterschiedlich zu konfigurieren. Diese Konfiguration erfolgt im Puffermodul 104 des spiegelnden Druckservers 101. Mit dieser
Konfiguration wird eingestellt, wie das Puffermodul 104 die Spiegelung fortführt, wenn ein Fehler beim Übertragen der gespiegelten Daten bzw. beim Empfangen der gespiegelten Daten durch das Spiegeldrucksystem II auftritt. Hierbei können folgende Regeln eingestellt werden:
(1) Abbruch der Datenübertragung vom sendenden
Druckserver zum empfangenden Druckserver, wenn ein Fehler beim Kopieren auf dem Druckserver des Spiegeldrucksystems auftritt. (2) Fortsetzen der Datenübertragung vom sendenden
Druckserver zum empfangenden Druckserver, selbst bei einem Fehler auf dem empfangenden Druckserver.
(3) Fortsetzen der Datenübertragung vom sendenden Druckserver zum empfangenden Druckserver nur wenn n Kopien der zu sichernden Daten erfolgreich auf anderen Druckservern erstellt worden sind.
(4) Umschalten des Kopiervorgangs auf ein vorbestimmtes anderes Spiegel -Drucksystem, wenn ein Fehler an den eigentlich empfangenden Druckserver des Spiegel - Drucksystems auftritt.
Im Fehlerfall gibt es zwei Möglichkeiten wie ein Fehler an einem Spiegel -Drucksystem behoben werden kann (Error recovery) . Zum einen kann versucht werden, alle Druckdaten bzw. Dateneinheiten, die seit Auftreten des Fehlers am Empfänger empfangen worden sind, auf das Spiegeldrucksystem zu kopieren. Zum anderen kann das spiegelnde Drucksystem auch derart konfiguriert sein, dass die seit dem Auftreten des Fehlers empfangenen Druckdaten nicht mehr auf dieses Spiegeldrucksystem kopiert werden.
Beim Verfahren zum Spiegeln von Druckaufträgen werden zunächst die eingehenden Druckdaten unmittelbar gespiegelt. Dies erfolgt im Puffermodul 104. Dies kann jedoch auch in einem der Inputmodule 103/1 ausgeführt werden. Hierbei werden alle Druckdaten, d.h. die zu druckenden Druckdaten als auch die Auftragsbegleitdaten gespiegelt. Wesentlich für die Erfindung ist, dass zusätzlich aus den Auftragsbegleitdaten für die Drucksysteme spezifische Jobtickets erzeugt werden, die dann auch unverzüglich gespiegelt werden. Das Erzeugen der Jobtickets erfolgt durch Anwenden von Ticket-Regeln auf die eingehenden Auftragsbegleitdaten. Diese Ticket-Regeln verknüpfen die Auftragsbegleitdaten mit Vorgabe- Jobtickets. Die Vorgabe-Jobtickets sind spezifisch für die jeweiligen Drucksysteme. Die Vorgabe-Jobtickets sind auch spezifisch für die unterschiedlichen Inputmodule 103/1, so dass beispielsweise bei drei unterschiedlichen Inputmodulen und zwei unterschiedlichen Drucksystemen insgesamt sechs unterschiedliche Vorgabe-Jobtickets vorzusehen sind.
Die Ticket-Regeln können auf unterschiedliche Weise aufgerufen werden:
(1) Die Ticket-Regeln werden vom Inputmodul bei der Weiterleitung der Druckaufträge aufgerufen, wobei das
Inputmodul mit dem Aufruf einen Parameter weitergibt, der angibt, welche Ticket-Regel auf den jeweiligen
Druckauftrag bzw. dessen Auftragsbegleitdaten angewandt wird. (2) In Abhängigkeit von dem Inputmodul, über das der
Druckauftrag empfangen wird, wird automatisch eine bestimmte Ticket-Regel ausgeführt. (3) In Abhängigkeit vom Spiegel -Verfahren im Puffermodul
104 wird eine bestimmte Ticket-Regel zum Erstellen eines oder mehrerer Spiegel-Jobtickets aufgerufen.
Somit können auch mehrere Ticket-Regeln zum Erstellen jeweils eines spezifischen Jobtickets unabhängig voneinander aufgerufen werden.
Mit dem Verfahren zum Spiegeln von Druckaufträgen werden somit die herkömmlich bekannten Spiegelungsverfahren durch eine Verarbeitungsstufe erweitert, in welcher die Auftragsbegleitdaten weiter so zu den jeweiligen Drucksysteme spezifische Jobtickets verarbeitet werden, die dann auch gespiegelt werden. Bezugszeichenliste
1 Sender
2 Empfänger
3 Druckertreiber
4 Druckgerät
5 Netzwerk
6 Schnittstellen-Modul
7 Spool -Modul
8 Puffermodul
9 Entschlüsselungs- und Dekomprimierungsmodul
10 Puffermodul
11 Druckdatenverarbeitungseinheit
12 Puffermodul
13 Datenleitung
14 Spiegel -Computersystem
15 Datenverbindung
101 Druckserver
102 Druckauftragsmanager
103 Client
103/1 Inputmodule
103/2 Druckauftrag-Client
103/3 Ticket-Regel -Client
104 Puffermodul
105 Dekomprimierungsmodul
106 Speichereinheit
107 Spoolmodul
108 Rechner
109 Datenleitung
110 Schnittstelle
111 Druckgerät
112 Ticket-Regel -Modul
113 Schnittstelle
114 Datenleitung
115 Datenverbindung
116 Schnittstelle
erstes Drucksystem II zweites Drucksystem (Spiegel -Drucksystem)

Claims

Patentansprüche
1. Verfahren zum Empfangen von Druckdaten durch einen Empfänger (2) von einem Sender (1), bei dem der Empfänger (2) nach einem vorbestimmten Protokoll den korrekten Empfang einer vorbestimmten Dateneinheit an Druckdaten an den Sender quittiert, wobei der Empfänger (2) vor dem Ausführen der jeweiligen Quittierung für eine bestimmte Dateneinheit die Druckdaten kopiert.
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t, dass der Empfänger (2) zum Empfangen der Druckdaten einen Druckserver (2) aufweist und die Druckdaten auf ein vom Druckserver separat ausgebildetes Spiegel - Computersystem (14) kopiert.
3. Verfahren nach Anspruch 2 , d a d u r c h g e k e n n z e i c h n e t, dass bei Problemen des Speicherns der Druckdaten auf dem Druckserver (2) automatisch das Spiegel- Computersystem (14) als Druckserver verwendet wird.
4. Verfahren nach einem der Ansprüche 1 bis 3, d a d u r c h g e k e n z e i c h n e t, dass die Quittierung des korrekten Empfanges erst nach erfolgreicher Ausführung des Kopierens der entsprechenden Dateneinheit an Druckdaten ausgeführt wird.
5. Verfahren nach einem der Ansprüche 1 bis 4, d a d u r c h g e k e n n z e i c h n e t, dass die Übertragung der Druckdaten abgebrochen wird, wenn das Kopieren einer Dateneinheit an Druckdaten nicht korrekt ausgeführt worden ist.
6. Verfahren nach einem der Ansprüche 1 bis 4, d a d u r c h g e k e n n z e i c h n e t, dass der korrekte Empfang der Druckdaten vom Empfänger (2) quittiert wird, selbst wenn die Dateneinheit an Druckdaten nicht korrekt kopiert werden konnte, sofern die Dateneinheit ohne Kopieren korrekt empfangen werden konnte .
7. Verfahren nach Anspruch 6 , d a d u r c h g e k e n n z e i c h n e t, dass nach dem Beheben des Fehlers, der die Ursache des nicht korrekten Kopierens ist, die nicht kopierten Druckdaten kopiert werden.
8. Verfahren nach einem der Ansprüche 1 bis 7, d a d u r c h g e k e n n z e i c h n e t, dass die Druckdaten jeweils mehrfach kopiert werden.
9. Verfahren nach einem der Ansprüche 1 bis 8, d a d u r c h g e k e n n z e i c h n e t, dass der Empfänger (2) einen Druckserver, ein erstes Spiegel -Computersystem (14) und ein zweites Spiegel- Computersystem aufweist, wobei die Druckdaten auf das zweite Spiegel -Computersystem nur kopiert werden, wenn das erste Spiegel -Computersystem (14) die Druckdaten nicht korrekt speichern kann.
10. Verfahren nach einem der Ansprüche 1 bis 9, d a d u r c h g e k e n n z e i c h n e t, dass der Empfänger (2) die Druckdaten mittels eines Schnittstellen-Moduls (6) empfängt und das Schnittstellen-Modul (6) das Kopieren der Druckdaten ausführt .
11. Verfahren nach einem der Ansprüche 1 bis 9, d a d u r c h g e k e n n z e i c h n e t, dass der Empfänger (2) die Druckdaten mittels eines Schnittstellen-Moduls (6) empfängt und dem Schnittstellen-Modul (6) unmittelbar ein Kopiermodul nachgeordnet ist, das das Kopieren der Druckdaten ausführt .
12. Verfahren nach einem der Ansprüche 1 bis 9, d a d u r c h g e k e n n z e i c h n e t, dass der Empfänger (2) die Druckdaten mittels eines Schnittstellen-Moduls (6) empfängt und das Schnittstellen-Modul (6) die Druckdaten in ein Puffermodul (8) zwischenspeichert, wobei das Puffermodul (8) die Druckdaten kopiert.
13. Verfahren nach einem der Ansprüche 1 bis 12, d a d u r c h g e k e n n z e i c h n e t, dass die Druckdaten vom Sender (1) zum Empfänger (2) mittels des DOWNLOAD-Protokolls übertragen werden.
14. Verfahren nach einem der Ansprüche 1 bis 13, d a d u r c h g e k e n n z e i c h n e t, dass nach dem Übertragen einer vollständigen Datei eine Quittierung ausgeführt wird.
15. Verfahren nach einem der Ansprüche 1 bis 14, d a d u r c h g e k e n n z e i c h n e t, dass die Dateneinheiten durch vorbestimmte Marken (Checkpoints) begrenzt werden.
16. Verfahren nach einem der Ansprüche 1 bis 15, d a d u r c h g e k e n n z e i c h n e t, dass die Übertragung der Druckdaten vom Sender (1) zum Empfänger (2) mittels einer gesicherten Datenverbindung erfolgt .
17. Verfahren nach einem der Ansprüche 1 bis 16, d a d u r c h g e k e n n z e i c h n e t, dass die Druckdaten vom Sender (1) komprimiert werden und vom Empfänger (2) vor dem Dekomprimieren kopiert werden.
18. Verfahren nach einem der Ansprüche 1 bis 17, d a d u r c h g e k e n n z e i c h n e t, dass die Druckdaten vom Sender (1) verschlüsselt werden und vom Empfänger (2) vor dem Entschlüsseln kopiert werden.
19. Verfahren nach einem der Ansprüche 1 bis 18, d a d u r c h g e k e n n z e i c h n e t, dass der Empfänger (2) die eingehenden Druckdaten blockweise unmittelbar nach dem Empfang eines jeweiligen Datenblockes kopiert.
20. Verfahren nach Anspruch 19, d a d u r c h g e k e n n z e i c h n e t, dass ein Datenblock eine vorbestimmte Datenmenge von z.B. 100 KB bis 1 MB umfasst.
21. Verfahren nach einem der Ansprüche 1 bis 20, d a d u r c h g e k e n n z e i c h n e t, dass der Empfänger (2) die Druckdaten bearbeitet und nach der Bearbeitung der Druckdaten die bearbeiteten Druckdaten kopiert und vorzugsweise an ein separat ausgebildetes Spiegel -Computersystem (14) übertragen werden.
22. Verfahren nach Anspruch 21, d a d u r c h g e k e n n z e i c h n e t, dass das Kopieren der bearbeiteten Druckdaten von einem Puffer-Modul (12) ausgeführt wird.
23. Verfahren zum Empfangen von Druckdaten durch einen Empfänger (2) von einem Sender (1), bei dem die Druckdaten gemäß einem vorbestimmten Protokoll übertragen werden, wobei der Empfänger (2) überprüft, ob die Druckdaten von einem korrekten Sender (1) stammen, indem der Empfänger mit einem Schnittstellen- Modul (6) zum Empfangen der Druckdaten anhand von mehreren Parametern, die gemäß dem vorbestimmten Protokoll der Druckdaten im Header enthalten sind, die Korrektheit des Senders (1) überprüft, bevor die Druckdaten durch das Schnittstellen-Modul (6) zur Speicherung freigegeben werden.
24. Verfahren nach Anspruch 23, d a d u r c h g e k e n n z e i c h n e t, dass zumindest einer der Parameter (class, form) den Inhalt des Druckauftrages mitbestimmt.
25. Verfahren nach Anspruch 23 oder 24, d a d u r c h g e k e n n z e i c h n e t, dass Parameter mehrerer Header zum Prüfen der Druckdaten verwendet werden.
26. Verfahren nach einem der Ansprüche 23 bis 25, d a d u r c h g e k e n n z e i c h n e t, dass die Druckdaten gemäß einem Verfahren nach einem der Ansprüche 1 bis 22 empfangen werden.
27. Vorrichtung zum Empfangen von Druckdaten, die einen Computer aufweist, in dem ein Computerprogramm zum Ausführen des Verfahrens nach einem der Ansprüche 1 bis 26 gespeichert und ausführbar ist.
28. Computerprogrammprodukt, das zum Ausführen des Verfahrens nach einem der Ansprüche 1 bis 26 ausgebildet ist.
29. Verfahren, insbesondere nach einem der Ansprüche 1 bis 26, zum Spiegeln von Druckaufträgen, die Auftragsbegleitdaten enthalten, durch einen spiegelnden Druckserver (101) eines ersten Drucksystem (I) zu einem Druckserver (101) eines zweiten Drucksystems (II) , dem Spiegelserver, wobei der spiegelnde Druckserver (101) - die empfangenen Druckaufträge auf den Spiegelserver spiegelt,
- anhand der Auftragsbegleitdaten zumindest ein Spiegel-Jobticket erstellt, und - das Spiegel-Jobticket auf den Spiegelserver kopiert.
30. Verfahren nach Anspruch 29, d a d u r c h g e k e n n z e i c h n e t, dass das Spiegel-Jobticket spezifisch für das Drucksystem (II) des Spiegelservers ausgebildet ist, so dass die korrespondierenden Druckdaten mit dem Spiegel-Jobticket unmittelbar an diesen Drucksystem (II) zum Ausdruck gebracht werden können.
31. Verfahren nach Anspruch 29, d a d u r c h g e k e n n z e i c h n e t, dass das Spiegel-Jobticket spezifisch für ein den ersten Druckserver (101) umfassendes Drucksystem (I) ausgebildet ist, so dass die korrespondierenden Druckdaten mit dem Spiegel-Jobticket an diesem
Drucksystem (I) zum Ausdruck gebracht werden können.
32. Verfahren nach einem der Ansprüche 29 bis 31, d a d u r c h g e k e n n z e i c h n e t, dass am ersten Druckserver (101) zwei Spiegel- Jobtickets erstellt werden, wobei eines der beiden Spiegel-Jobtickets spezifisch für das erste Drucksystem (I) ausgebildet ist, so dass der korrespondierende Druckauftrag mit dem Spiegel - Jobticket unmittelbar am ersten Drucksystem (I) zum Ausdruck gebracht werden kann, und dass das andere Spiegel-Jobticket spezifisch für das zweite Drucksystem (II) ausgebildet ist, so dass der korrespondierende Druckauftrag mit dem Spiegel - Jobticket am zweiten Drucksystem (II) zum Ausdruck gebracht werden kann.
33. Verfahren nach einem der Ansprüche 29 bis 32, d a d u r c h g e k e n n z e i c h n e t, dass die Druckdaten am spiegelnden Druckserver verarbeitet werden, wobei die Verarbeitung der Druckdaten insbesondere ein Rastern der Druckdaten umfassen kann, und in Abhängigkeit vom Verarbeitungsfortschritt ein oder mehrere neue Spiegel-Jobtickets erstellt und auf den Druckserver (101) des zweiten Drucksystems (II) kopiert werden.
34. Verfahren nach einem der Ansprüche 29 bis 33, d a d u r c h g e k e n n z e i c h n e t, dass der spiegelnde Druckserver (101) anhand der Auftragsbegleitdaten ein Jobticket erstellt, das spezifisch für das erste Drucksystem (I) ist.
35. Verfahren nach einem der Ansprüche 29 bis 34, d a d u r c h g e k e n n z e i c h n e t, dass die gespiegelten Druckaufträge und/oder die auf das zweite Drucksystem (II) kopierten Spiegel- Jobtickets für eine vorbestimmte Zeitdauer gesperrt werden.
36. Verfahren nach einem der Ansprüche 29 bis 35, d a d u r c h g e k e n n z e i c h n e t, dass die Spiegel -Jobtickets bzw. das Jobticket anhand eines Vorlage-Jobtickets erstellt werden, das mit den Auftragsbegleitdaten des jeweiligen Druckauftrages verknüpft wird.
37. Verfahren nach Anspruch 36, d a d u r c h g e k e n n z e i c h n e t, dass beim Verknüpfen der Auftragsbegleitdaten mit dem Vorlage-Jobticket entweder Informationen aus den Auftragsbegleitdaten in das Vorlage-Jobticket eingetragen werden und dieses als Spiegel-Jobticket bzw. als Jobticket verwendet wird, oder ein in den Auftragsbegleitdaten enthaltenes Jobticket durch Informationen aus dem Vorlage-Jobticket ergänzt wird.
38. Verfahren nach Anspruch 36 oder 37, d a d u r c h g e k e n n z e i c h n e t, dass mehrere Vorlage-Jobtickets verwendet werden, die mit für das jeweilige Drucksystem und/oder für ein jeweiliges Inputmodul (103/2) spezifischen Steuerparametern versehen sind.
39. Verfahren nach einem der Ansprüche 29 bis 38, d a d u r c h g e k e n n z e i c h n e t, dass der spiegelnde Druckserver (101) Druckaufträge auf Druckservern unterschiedlicher Drucksysteme spiegelt .
40 Verfahren nach einem der Ansprüche 29 bis 38, d a d u r c h g e k e n n z e i c h n e t, dass die Druckserver der Drucksysteme die jeweils eingehenden Daten gegenseitig spiegeln.
41 Verfahren nach einem der Ansprüche 29 bis 40, d a d u r c h g e k e n n z e i c h n e t, dass die gespiegelten Druckaufträge und/oder die gespiegelten Spiegel-Jobtickets freigegeben werden, wenn eine Datenverbindung (114, 115) zwischen den jeweiligen Drucksystemen unterbrochen ist.
42 Verfahren nach einem der Ansprüche 29 bis 41, d a d u r c h g e k e n n z e i c h n e t, dass die Erstellung für die jeweiligen Drucksysteme spezifischer Spiegel-Jobtickets mittels zentral an einem Druckserver, insbesondere an einem Druckauftragsmanager (102) ausführbarer Ticket-Regeln erfolgt .
43 Computerprogramm, d a d u r c h g e k e n n z e i c h n e t, dass es zum Ausführen des Verfahrens nach einem der Ansprüche 29 bis 42 ausgebildet ist.
44 Computerprogramm nach Anspruch 43, d a d u r c h g e k e n n z e i c h n e t, dass das Computerprogramm auf einem Datenträger gespeichert ist.
45. Drucksystem zum Ausführen eines Verfahrens nach einem der Ansprüche 29 bis 42, mit einem Druckserver (101) umfassend
- zumindest ein Inputmodul (103/1) zum Empfangen von Druckaufträgen, - ein Puffermodul (104) zum Zwischenspeichern der von den Inputmodulen empfangenen Druckaufträgen und zum Spiegeln der Druckaufträge an einem Druckserver (101) eines weiteren Drucksystems (102) , - eine Speichereinheit (106) zum Speichern der eingehenden Druckaufträge,
- einen Druckauftragsmanager (102) zum Erstellen von für die Drucksysteme spezifische Jobtickets, wobei der Druckauftragsmanager (102) zum Spiegeln eines solchen Jobtickets, das als Spiegel-Jobticket bezeichnet wird, auf den Druckserver des weiteren Drucksystems ausgebildet ist.
46. Drucksystem nach Anspruch 45, d a d u r c h g e k e n n z e i c h n e t, dass der Druckauftragsmanager (102) ein Ticket-Regel- Modul (112) umfasst, das zum zentralen Verwalten von Ticket-Regeln dient und diese dem Druckauftragsmanager
(102) zum Erstellen der Jobtickets bereit stellt.
PCT/EP2007/059958 2006-09-22 2007-09-20 Verfahren und system zum automatischen übertragen von druckdaten und insbesondere zum spiegeln von druckaufträgen WO2008034873A2 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP07820398A EP2078241A2 (de) 2006-09-22 2007-09-20 Verfahren und system zum automatischen übertragen von druckdaten und insbesondere zum spiegeln von druckaufträgen
JP2009528725A JP4861480B2 (ja) 2006-09-22 2007-09-20 印刷データの自動的な伝送、特に印刷ジョブのミラーリングのための方法及びシステム
US12/441,551 US8373872B2 (en) 2006-09-22 2007-09-20 Method and system for the automatic transmission of printing data and particularly for mirroring printing orders

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE102006044870.7 2006-09-22
DE200610044870 DE102006044870B3 (de) 2006-09-22 2006-09-22 Verfahren und System zum automatischen Übertragen von Druckdaten
DE102007010277.3 2007-03-02
DE200710010277 DE102007010277B4 (de) 2007-03-02 2007-03-02 Verfahren, Drucksystem und Computerprogramm zum Spiegeln von Druckaufträgen

Publications (2)

Publication Number Publication Date
WO2008034873A2 true WO2008034873A2 (de) 2008-03-27
WO2008034873A3 WO2008034873A3 (de) 2008-06-12

Family

ID=38895952

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/059958 WO2008034873A2 (de) 2006-09-22 2007-09-20 Verfahren und system zum automatischen übertragen von druckdaten und insbesondere zum spiegeln von druckaufträgen

Country Status (4)

Country Link
US (1) US8373872B2 (de)
EP (1) EP2078241A2 (de)
JP (1) JP4861480B2 (de)
WO (1) WO2008034873A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113673832A (zh) * 2021-07-27 2021-11-19 卡斯柯信号有限公司 一种运营指标数据的生成方法、装置、设备及介质

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5430181B2 (ja) * 2009-03-10 2014-02-26 キヤノン株式会社 画像形成装置、その制御方法及びプログラム
JP5482434B2 (ja) * 2010-05-17 2014-05-07 セイコーエプソン株式会社 記録制御装置、記録システム、記録制御方法、及び、プログラム
JP5834550B2 (ja) * 2011-07-05 2015-12-24 株式会社リコー 情報処理装置、データ管理システム、及びデータ管理プログラム
JP5874313B2 (ja) * 2011-10-25 2016-03-02 富士ゼロックス株式会社 画像形成システム、画像形成装置、送信装置及びプログラム
US9292234B2 (en) * 2013-11-04 2016-03-22 Ricoh Company, Ltd. Print job correction mechanism
US10616241B2 (en) 2017-06-05 2020-04-07 Honeywell International Inc. Systems and methods for performing external data validation for aircraft onboard systems

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06259206A (ja) * 1993-03-09 1994-09-16 Ricoh Co Ltd ネットワ−クプリンタ最適化方法
US5586291A (en) * 1994-12-23 1996-12-17 Emc Corporation Disk controller with volatile and non-volatile cache memories
US6292905B1 (en) * 1997-05-13 2001-09-18 Micron Technology, Inc. Method for providing a fault tolerant network using distributed server processes to remap clustered network resources to other servers during server failure
US6313921B1 (en) * 1997-09-24 2001-11-06 Canon Kabushiki Kaisha Image forming system, image forming apparatus and method of controlling the same
KR20040099065A (ko) * 2003-05-14 2004-11-26 이종희 프린팅 시스템의 스풀 데이타 보안 처리 및 출력 방법과그 장치
US20060047836A1 (en) * 2004-08-13 2006-03-02 Rao Goutham P A method for maintaining transaction integrity across multiple remote access servers
DE102004047327A1 (de) * 2004-09-29 2006-04-06 OCé PRINTING SYSTEMS GMBH Verfahren und System zum automatischen Bearbeiten eines Jobtickets für einen Druckprozess

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07219729A (ja) * 1994-02-04 1995-08-18 Fuji Xerox Co Ltd プリントシステム
DE19957594B4 (de) * 1999-11-30 2004-08-26 OCé PRINTING SYSTEMS GMBH Verfahren zum Synchronisieren von threads eines Computerprogramms
JP4546629B2 (ja) * 2000-05-25 2010-09-15 株式会社日立製作所 記憶システム、記憶システムの応答方法及び記録媒体
US6505307B1 (en) * 2000-09-06 2003-01-07 Unisys Corporation Method and apparatus for ensuring data integrity
US6728849B2 (en) * 2001-12-14 2004-04-27 Hitachi, Ltd. Remote storage system and method
US7474426B2 (en) * 2001-12-18 2009-01-06 Oce Printing Systems Gmbh Method, device system and computer program for saving and retrieving print data in a network
JP2007525980A (ja) * 2004-03-04 2007-09-13 ザ ユニバーシティ オブ ブリティッシュ コロンビア 患者結果を予測するトロンボモジュリン（ｔｈｂｄ）ハプロタイプ
US20060047835A1 (en) * 2004-07-02 2006-03-02 Greaux Jeffrey E Method and System for LAN and WLAN access to e-commerce sites via Client Server Proxy
JP2006139477A (ja) * 2004-11-11 2006-06-01 Hitachi Ltd 計算機システム、管理方法及びストレージネットワークシステム
US7366846B2 (en) * 2005-01-14 2008-04-29 International Business Machines Corporation Redirection of storage access requests
JP4696721B2 (ja) * 2005-06-27 2011-06-08 富士ゼロックス株式会社 文書管理サーバ、文書管理システム
DE102006044870B3 (de) 2006-09-22 2008-02-07 OCé PRINTING SYSTEMS GMBH Verfahren und System zum automatischen Übertragen von Druckdaten
DE102007009737B4 (de) 2007-02-28 2010-09-16 OCé PRINTING SYSTEMS GMBH Verfahren, Drucksystem und Computerprogramm zum automatischen Bearbeiten von Auftragsbegleitdaten eines Druckauftrages
JP4798278B2 (ja) * 2009-09-17 2011-10-19 コニカミノルタビジネステクノロジーズ株式会社 ジョブ処理システムおよび画像処理装置、プログラム、画像処理装置の制御方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06259206A (ja) * 1993-03-09 1994-09-16 Ricoh Co Ltd ネットワ−クプリンタ最適化方法
US5586291A (en) * 1994-12-23 1996-12-17 Emc Corporation Disk controller with volatile and non-volatile cache memories
US6292905B1 (en) * 1997-05-13 2001-09-18 Micron Technology, Inc. Method for providing a fault tolerant network using distributed server processes to remap clustered network resources to other servers during server failure
US6313921B1 (en) * 1997-09-24 2001-11-06 Canon Kabushiki Kaisha Image forming system, image forming apparatus and method of controlling the same
KR20040099065A (ko) * 2003-05-14 2004-11-26 이종희 프린팅 시스템의 스풀 데이타 보안 처리 및 출력 방법과그 장치
US20060047836A1 (en) * 2004-08-13 2006-03-02 Rao Goutham P A method for maintaining transaction integrity across multiple remote access servers
DE102004047327A1 (de) * 2004-09-29 2006-04-06 OCé PRINTING SYSTEMS GMBH Verfahren und System zum automatischen Bearbeiten eines Jobtickets für einen Druckprozess

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
IBM: "Print Services Facility for z/OS. DOWNLOAD FOR z/OS (Version 4, Release 1.0)" INTERNET CITATION, [Online] 30. November 2005 (2005-11-30), XP007903856 Gefunden im Internet: URL:http://publibz.boulder.ibm.com/epubs/pdf/apsw1400.pdf> [gefunden am 2008-01-17] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113673832A (zh) * 2021-07-27 2021-11-19 卡斯柯信号有限公司 一种运营指标数据的生成方法、装置、设备及介质

Also Published As

Publication number Publication date
WO2008034873A3 (de) 2008-06-12
US8373872B2 (en) 2013-02-12
JP2010504577A (ja) 2010-02-12
EP2078241A2 (de) 2009-07-15
JP4861480B2 (ja) 2012-01-25
US20090268228A1 (en) 2009-10-29

Similar Documents

Publication Publication Date Title
DE60203571T2 (de) Druckvorrichtung und dessen Verfahren zum Aktualisieren der Betriebsdaten
WO2008034873A2 (de) Verfahren und system zum automatischen übertragen von druckdaten und insbesondere zum spiegeln von druckaufträgen
DE3908459C2 (de) Netzwerkserver
DE69725451T2 (de) Drucken in offenen systemen
DE60130341T2 (de) Fernnetzwerkdrucken
DE60130633T2 (de) Gesicherte Internet-Zwischenablage
DE10257428A1 (de) Steuerung von Software über Bündeln
EP1241563A2 (de) Verfahren zur Verbesserung der Druckeffizienz
DE69525330T2 (de) Wiederherstellung eines Druckerauftrages in einem Druckersystem
EP1197347A2 (de) Schnittstellen-System und Verfahren
WO2009083091A2 (de) Verfahren und einrichtung zur kommunikation gemäss dem standardprotokoll opc ua in einem client-server-system
DE10024715A1 (de) Verfahren und Vorrichtung zum Einrichten einer Zwei-Wege-Übertragung mit einem fernen Drucker
EP1519262A1 (de) Verfahren, Gerätesystem und Computerprogramm zum Speichern und Abrufen von Druckdaten in einem Netzwerk
EP2772856A1 (de) Verfahren zum Ausführen von Tasks auf einem Produktions-Computersystem sowie Datenverarbeitungssystem
DE102018110612A1 (de) Robuste Druckauftrageingabe
EP3152884B1 (de) Verfahren zur weiterleitung von daten zwischen computersystemen, computernetz-infrastruktur sowie computerprogramm-produkt
DE10051022A1 (de) Verfahren, System und Programm für die Neukonfiguration logischer Drucker in einem Druckernetzsystem
DE10212890A1 (de) Dokumenten-Bearbeitungsauftragssteuerungssystem, Verfahren zum Steuern von Dokumenten-Bearbeitungsaufträgen und Softwareprodukt zum Ausführen eines solchen Verfahrens
DE102007009737B4 (de) Verfahren, Drucksystem und Computerprogramm zum automatischen Bearbeiten von Auftragsbegleitdaten eines Druckauftrages
DE102006044870B3 (de) Verfahren und System zum automatischen Übertragen von Druckdaten
WO2010072448A1 (de) Zugriffsverfahren auf ein übertragungsmedium
DE102007010277B4 (de) Verfahren, Drucksystem und Computerprogramm zum Spiegeln von Druckaufträgen
DE10151735B4 (de) System und Verfahren zum Verbinden eines Webservers in einem Peripheriegerät mit einem Netzwerk durch einen Host
DE102004047327A1 (de) Verfahren und System zum automatischen Bearbeiten eines Jobtickets für einen Druckprozess
DE102010016858A1 (de) Verfahren und Vorrichtung zum Überwachen eines Drucksystems und derartiges Drucksystem

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07820398

Country of ref document: EP

Kind code of ref document: A2

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 12441551

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2009528725

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2007820398

Country of ref document: EP