CROSS REFERENCES TO RELATED APPLICATIONSThis application is a reissue of U.S. patent application Ser. No. 10/141,308, filed on May 7, 2002, now issued as U.S. Pat. No. 7,664,956, which is a continuation-in-part of assignee's pending application U.S. Ser. No. 09/774,236 filed on Jan. 29, 2001 now abandoned, entitled “Method and system for copy protection of data content,” which is a continuation-in-part of assignee's application U.S. Ser. No. 09/397,331 filed on Sep. 14, 1999, entitled “Method and system for copyright protection of digital images transmitted over networks” (now U.S. Pat. No. 6,298,446), which claims priority to Israeli patents IL 127093, filed on Nov. 16, 1998, and IL 127869, filed on Dec. 30, 1998 and is a continuation-in-part of assignee's application U.S. Ser. No. 09/313,067 filed on May 17, 1999, entitled “Methods and apparatus for preventing reuse of text, images and software transmitted via networks” (now U.S. Pat. No. 6,209,103), which, in turn, claims priority to Israeli patent IL 124895, filed Jun. 14, 1998, each of which is incorporated by reference herein.
FIELD OF THE INVENTIONThe present invention relates to controlled printing of documents within a content copy protection system.
BACKGROUND OF THE INVENTIONPrinting electronic documents within a personal computer operating system, such as Microsoft Windows, typically involves selecting a printer from a list of available local and network printers, selecting print options for the selected printer, and issuing a print request. A printer driver for the selected printer then sends data for printing to a print spool, which is a buffer feeding into a printer board.
After a print request is issued, the document is listed in a print queue for the selected printer, while the print job is pending. An administrator or the user issuing the print request typically can delete the job prior to its execution, and abort the print job while it is executing.
Prior art print workflows do not enable real-time control of printing, other than deleting and aborting a print job. User and document access control parameters and printer control parameters are pre-configured. Today's digital rights management and secure document environments focus on copy protection, but print control is only enforced by pre-set parameters, and by enabling or disabling printing altogether.
Thus there is a need for a dynamic print controller that can control print jobs on the fly, after the print request is issued.
SUMMARY OF THE INVENTIONThe present invention provides a method and system for controlled printing of documents within a content copy protection system. The present invention enables inter alia real-time document access control, real-time document watermarking, and real-time control of which printers a document can be printed on.
There is thus provided in accordance with a preferred embodiment of the present invention a method for real-time control of document printing, including intercepting a print request for an original document by a user, obtaining print information corresponding to the original document, in response to the intercepting, the print information including an address for a print server, re-issuing the print request by a server computer, and sending the print request and the print information to the print server.
There is further provided in accordance with a preferred embodiment of the present invention a method for real-time control of document printing, including in response to a request by a client computer to print an original document, obtaining document print information corresponding to the original document, generating a modified document comprising embedding the document print information within the original document, and sending the modified document to a print server.
There is yet further provided in accordance with a preferred embodiment of the present invention a system for real-time control of document printing, including an administrative tool for specifying document-specific print information for a collection of original documents, a server computer including an interceptor for intercepting a print request for an original document, a print control processor for obtaining print information specific to the original document, and a request generator for re-issuing the print request, and a client computer including a request generator for issuing a print request for an original document, a transmitter for sending the print request and print information specific to the original document to the server computer.
There is additionally provided in accordance with a preferred embodiment of the present invention a system for real-time control of document printing, including a data storage for providing document print information corresponding to an original document, a document generator for obtaining document print information corresponding to an original document and for generating a modified document by embedding the document print information within the original document, in response to a request by a user to print the original document, and a transmitter for sending the modified document to a print server.
There is moreover provided in accordance with a preferred embodiment of the present invention a method for real-time control of document printing, including intercepting a print request for an original document by a user, obtaining print information corresponding to the original document, in response to the intercepting; and logging the print request and at least a portion of the print information.
There is further provided in accordance with a preferred embodiment of the present invention a system for real-time control of document printing, including an interceptor for intercepting a print request for an original document by a user, a print control processor for obtaining print information corresponding to the original document, in response to the intercepting, and a print event logger for logging the print request and at least a portion of the print information.
There is yet further provided in accordance with a preferred embodiment of the present invention a print server including a pre-check module for dynamically processing print information at run-time, a document requester for requesting a document to be printed from a document management system, a format processor for converting a document from a native format to an internal format, and a print module for delivering content to be printed to a print spool.
There is additionally provided in accordance with a preferred embodiment of the present invention a method for serving documents to a printer, including dynamically processing print information at run-time, requesting a document to be printed from a document management system, converting a document from a native format to an internal format, and delivering content to be printed to a print spool.
There is moreover provided in accordance with a preferred embodiment of the present invention a document management system with secure printing, including a document manager for managing a storage of original documents, a user account manager for managing at least one user account, for at least one user having at least partial access to the original documents, an interceptor for intercepting a print request for an original document, and a print control processor for obtaining print information specific to the original document.
There is moreover provided in accordance with a preferred embodiment of the present invention a method for secure printing within a document management system, including managing a storage of original documents, managing at least one user account, for at least one user having at least partial access to the original documents, intercepting a print request for an original document, and obtaining print information specific to the original document.
BRIEF DESCRIPTION OF THE DRAWINGSThe present invention will be more fully understood and appreciated from the following detailed description, taken in conjunction with the drawings in which:
FIG. 1 is a simplified block diagram of a controlled printing system in accordance with a preferred embodiment of the present invention;
FIG. 2A is a simplified block diagram of a server-side component of a system for controlled printing, in accordance with a preferred embodiment of the present invention;
FIG. 2B is a simplified block diagram of a client-side component of a system for controlled printing, in accordance with a preferred embodiment of the present invention;
FIG. 3A is a simplified block diagram of a print server for controlled printing, in accordance with a preferred embodiment of the present invention;
FIG. 3B is a user interface with a sample print options dialogue, in accordance with a preferred embodiment of the present invention;
FIG. 4 is a simplified flowchart for document preparation within a copy protection application, in accordance with a preferred embodiment of the present invention;
FIG. 5 is a simplified flowchart for a controlled print process, in accordance with a preferred embodiment of the present invention;
FIG. 6 is a simplified data sequence diagram for an authentication and secure print workflow, in accordance with a preferred embodiment of the present invention; and
FIG. 7 is a simplified data flow diagram for setting print and watermark attributes for a document, in accordance with a preferred embodiment of the present invention.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENTThe present invention provides a method and system for printing documents within a secure content copy protection system. In a preferred embodiment, the present invention operates as a component of a “secure display” system. An example of such a system is applicant's Mirage™ enterprise software product, which is used to protect text and image content displayed on a computer monitor for viewing, from being copied. Mirage includes server-side software that encrypts content prior to delivering it to clients, and client-side software for decrypting the content prior to displaying it.
The Mirage technology is described in applicant's U.S. Pat. No. 6,298,446 entitled “Method and System for Copyright Protection of Digital Images Transmitted over Networks,” in applicant's U.S. Pat. No. 6,353,892 entitled “Copy Protection of Digital Images Transmitted over Networks,” in applicant's U.S. Pat. No. 6,992,693 entitled “Method and System for Copy Protection of Images Displayed on a Computer Monitor”, in applicant's U.S. Pat. No. 6,993,662 entitled “Method and System for Copy Protection of Displayed Data Content”, in applicant's U.S. Pat. No. 7,076,469 entitled “Copyright Protection of Digital Images Transmitted over Networks”, in applicant's U.S. Pat. No. 7,155,744 entitled “Copy Protection of Digital Images Transmitter over Networks”. and also in applicant's co-pending patent applications:
- U.S. Ser. No. 09/459,493 filed on Dec. 13, 1999 and entitled “Method and system for copyright protection of digital images transmitted over networks”; and
- U.S. Ser. No. 09/774,236 filed on Jan. 29, 2001 and entitled “Method and system for copy protection of data content”.
 Contents of U.S. Pat. Nos. 6,298,446, 6,353,892, 6,922,693, 6,993,662, 7,076,469 and 7,155,744, and the above two patent applications are hereby incorporated by reference.
 
In a preferred embodiment, the present invention is used to add secure printing functionality to Mirage, to complement its secure display capability. Secure printing functionality enables a user who is viewing a secure document on his display to print the document, yet does not expose to the user an unencrypted document file. In order to print the document, the user must have appropriate authorization and be able to authenticate himself. Additionally, the present invention provides the capability to dynamically watermark the document at print time. Such watermark may include, for example, a CONFIDENTIAL mark or a DO NOT DUPLICATE mark, on each page of the document that is printed, as well as print job and user information and an expiration date and/or time.
In a preferred embodiment, the present invention dynamically logs each print event, as described hereinbelow.
The Mirage system can be integrated within a web server, and used to protect HTML pages, XML pages and other web content. Mirage can also be integrated within a document management system (DMS), such as Livelink, which is a DMS developed and manufactured by Open Text Corporation of Waterloo, Canada, and Documentum, which is a DMS developed and manufactured by Documentum, Inc. of Pleasanton, Calif. Mirage enhances DMS capability by providing copy protection for displayed documents.
A DMS typically includes its own digital rights management, including permissions that require authentication. Mirage authentication preferably operates in conjunction with DMS authentication.
Mirage manages permissions using administrative rules and using a properties file. Administrative rules are typically set by an administrator, and specify paths for directories and files wherein protected content resides, and one or more rules to be associated therewith. In a preferred embodiment of the present invention, administration rules include printing attributes. If an administration rule applies to a specific document, then print attributes within the rule are used for such document. In addition, a properties file is set when Mirage is configured, and typically contains initial permission information and default permission information. In conjunction with Mirage, the DMS may add additional permission information.
In a preferred embodiment, the present invention associates print and watermark attributes with document print permissions. Each such attribute includes a space-delimited list of parameters. The print and watermark attributes are described in Table I hereinbelow, and typically are document-specific.
In a preferred embodiment, the present invention embeds an encrypted header within a document file, prior to sending the document to a client for display. The encrypted header is used inter alia to store print and watermark attributes. Preferably, the encrypted header includes the following fields:
- SU (Print Server URL)—the URL of a print server. Authentication and other information can be encoded in the URL as GET data, as long as the total length of the URL does not exceed a 1024 character limit.
- PD (Print POST Data)—data to be sent as POST data with a print request.
- HD (Print Header Data)—data to be sent as header data with a request.
- MSG (Print Message)—message to be displayed to a user if SU is empty, and thus the document is not printable.
 
Print attributes are collected into the encrypted header as a block denoted PRINTINFO. Thus, the encrypted header includes PRINTINFO::1, {PRINTINFO}, where
- PRINTINFO=SU::1, . . . [PD::1, . . . ] [HD::1, . . . ] [MSG::1, . . . ], and 1 denotes the length in bytes of the respective data segments.
 
In a preferred embodiment of the present invention, relevant print and watermark attributes are included within SU, PD and HD.
Preferably, the encrypted header contains a plain text block and an encrypted block. The plain text block contains inter alia a key ID, for requesting a key from a key server to decode the encrypted block. Preferably, the encrypted block contains inter alia the above PRINTINFO block of data, and also contains a key for encrypting at least a portion of the document text.
Reference is now made toFIG. 1, which is a simplified block diagram of a controlled printing system in accordance with a preferred embodiment of the present invention. The present invention can be integrated with a web server computer, such asweb server computer105, and with a document server computer, such as documentmanagement server computer110.Web server computer105 includes aweb server115.Web server115 may be one of several popular web servers, such as a Netscape Internet server, a Microsoft Internet server or an Apache Internet server.Web server115 delivers web pages to client computers. Shown inFIG. 1 is astorage120 of web pages accessed byweb server115.Storage120 may reside withinweb server computer105, or within one or more other computers, or partly withinweb server computer105 and partly within other computers.
Preferably,web server computer105 also includes server-side software for protecting web content, such as applicant's Mirage™ server software125.Mirage server software125 may operate as an independent application, or in conjunction withweb server115. The operation ofMirage server software125 is described inFIG. 2A hereinbelow.
Preferably,web server computer105 also includes aprint server130, for serving documents to one ormore printers135, for printing. It may be appreciated by those skilled in the art that printserver130 may alternatively reside on a separate computer. The operation ofprint server130 is described inFIG. 3 hereinbelow. Ina preferred embodiment of the present invention,Mirage server software125 contains aninterceptor140, for intercepting client requests toweb server115 and routing them toMirage server software125.
Similarly, documentmanagement server computer110 includes adocument management system145.Document management system145 may be one of several popular document management systems (DMS), such as LiveLink DMS or Documentum DMS.Document management system145 delivers documents to client computers. Shown inFIG. 1 is astorage150 of documents accessed bydocument management system145.Storage150 may reside within documentmanagement server computer110, or within one or more other computers, or partly within documentmanagement server computer110 and partly within other computers.
Preferably, documentmanagement server computer110 also includes server-side software for protecting documents, such as applicant's Mirage™ server software155.Mirage server software155 may operate as an independent application, or in conjunction withdocument management system145. The operation ofMirage server software155 is described inFIG. 2A hereinbelow.
Preferably, documentmanagement server computer110 also includes aprint server160, for serving documents to one ormore printers135, for printing. It may be appreciated by those skilled in the art that printserver160 may alternatively reside on a separate computer. The operation ofprint server160 is described inFIG. 3 hereinbelow. In a preferred embodiment of the present invention, documentMirage Server software155 contains aninterceptor165, for intercepting client requests to documentmanagement system145 and routing them toMirage server software155. It may be appreciated by those skilled in the art that documentmanagement system145 may fully or partially fulfill the functionality ofinterceptor165.
Also shown inFIG. 1 is a client computer170, operated by a user. Client computer170 includes aweb browser175.Web browser175 may be one of several popular web browsers, such as a Netscape Navigator browser or a Microsoft Internet Explorer browser.Web browser175 displays web pages and documents. Client computer170 may contain adocument browser180 for displaying documents, in addition to or instead ofweb browser175.
Preferably, client computer170 also includes client-side software for protecting web content, such as applicant's Mirage™ client software185.Mirage client software185 may operate independently, or in conjunction withweb browser175 or in conjunction withdocument browser180, or in conjunction with bothweb browser175 anddocument browser180. The operation ofMirage client software185 is described inFIG. 2B hereinbelow.
In a preferred embodiment of the present invention, when client computer170 requests a web page or a document fromweb server computer105 or documentmanagement server computer110,interceptor140 or165 intercepts the request and forwards the request toMirage server software125 or155, respectively. In tarn,Mirage server software125 or155 issues a re-request for the web page or the document toweb server115 ordocument management system145, respectively. The web page or the document is delivered toMirage server software125 or155, andMirage server software125 or155 determines if the document is printable based on one or more administration rules, properties files and HTTP headers. If the web page or document is printable, thenMirage server software125 or155 encrypts the web page or document, and embeds an encrypted header including print information denoted PRINTINFO, within the web page or document, respectively. The web page or document is then sent to client computer170.
In an alternative embodiment of the present invention, the functionality ofinterceptor165 may be included withindocument management system145. In such an embodimentdocument management system145 may be configured to automatically deliver a requested document and its print information toMirage server software155, to be encrypted before being returned to the user, without intervention ofinterceptor165.
Upon receipt of the web page or document,Mirage client software185 decrypts encrypted data, and securely renders the web page or document for viewing. While a user is viewing the web page or document on client computer170, he may issue a print command. Preferably,Mirage client software185 intercepts the print command and queries Mirage for print information included within the encrypted header that was embedded in the web page or document; specifically, within the PRINTINFO block, as described hereinabove, If print information is available,Mirage client software185 sends such information to a print server specified in the print information, such asprint server130 orprint server160. If print information is not available, ten either the MSG message or a default message is displayed.
In a preferred embodiment of the present invention,print server130 orprint server160 enables the user to select print options, for example, printer, page orientation and page range, and logs the user's selection.Print server130 orprint server160 requests the web page or document fromweb server115 or fromdocument management system145, respectively. Preferably,print server130 orprint server160 uses authentication information within the PRINTINFO block to request the web page or document, respectively. For document printing, upon receipt of thedocument print server160 determines whether the document can be printed in its native format. If the document is stored in an unsupported format, then preferably an HTML rendition is printed instead. Preferably,print server130 andprint server160 log the print job, and send the web page or document, respectively, toprinter135.
In an alternative embodiment in which some ofMirage server software155 is integrated withindocument management system145, the print request can be recorded bydocument management system145 in a consolidated DMS log.
Regarding the client-side decryption, preferablyMirage client software185 communicates with akey server190 to obtain a key necessary for decoding the web page or document As described hereinabove,Mirage server software125 or155 preferably embeds an encrypted header within the web page or document, respectively. The encrypted header contains a key ID, to request a key fromkey server190 for decoding the encrypted header. Preferably, the encrypted header includes an encrypted key for encrypting at least a portion of the web page or document. Thus the key obtained fromkey server190 enablesMirage client software185 to extract another key for decoding at least a portion of the web page or document.
In an alternative embodiment of the present invention, the encrypted PRINTINFO is sent by client computer170 tokey server190 for decryption. In this embodiment,Mirage client software185 does not decrypt the print information. Instead,key server190 decides whether to decrypt the print information it receives from client computer170, and send decrypted information back to the client, or whether to send updated print information to the client, or whether to decline to decrypt the print information altogether.
Reference is now made toFIG. 2A, which is a simplified block diagram of a server-side component of a system for controlled printing, in accordance with a preferred embodiment of the present invention. Shown inFIG. 2A isMirage server software155 fromFIG. 1.Mirage server software155 includesinterceptor165 for intercepting document requests for a document server. Mirage server software also includes adocument processor210 andindividual components215,220,225,230,235 and240 for processing text, HTML, Word, Excel, PowerPoint and PDF documents, respectively, and acomponent245 for processing images. It is apparent to those skilled in the art that components for processing other types of documents may be included in addition to components215-245, and that some or all of components215-245 may not be included, depending on the types of documents chosen to be supported.Document processor210 preferably includes aprint information processor250, and aheader generator255 for embedding administration rules and print information within a document.
Print information processor250 preferably processes (i) print information included within a document processor configuration file, (ii) administration rule data intercepted byinterceptor165, and (iii) HTTP header data within the web server or DMS re-request response.Print information processor250 also formats the printing information for inclusion within a document header. It is noted that the print information is encrypted, so that only trusted print servers can decrypt it.
In a preferred embodiment of the present inventionprint information processor250 is implemented as a separate module or class or API. This is done so as to simplify customization for different DMSs. DMSs may require different HTTP headings or special encoding for data needed to request an authenticated printable version of a document, web page, ASP page or CGI-generated page.
Finally,document processor210 also includes adocument encrypter260, and an application programming interface (API)265 for communicating withdocument processor210.
Reference is now made toFIG. 2B, which is a simplified block diagram of a client-side component of a system for controlled printing, in accordance with a preferred embodiment of the present invention. Shown inFIG. 2B isMirage client software185 fromFIG. 1.Mirage client software185 includes aTextSafe module270, which intercepts text rendering byweb browser175.Mirage client software185 preferably also includes adocument decrypter275 and acoordinator280.
Upon issuance of a command by client computer170 to view a secure document,TextSafe module270 intercepts encrypted text as it is being rendered, and callsdocument decrypter275 to decrypt the intercepted text. TextSafe inserts the decrypted text into a video frame buffer for secure display.Coordinator280 is responsible for communication with a key server and with print server160 (FIG. 1).Coordinator280 is preferably also responsible for caching of keys and encrypted headers.
APixSafe module285 is used to provide secure display service by protecting displayed content from screen capture.PixSafe module285 operates by patching system graphics display interface (GDI) functions, including inter alia Microsoft Windows' BitBlt and StretchBlt functions, as described in U.S. Pat. Nos. 6,298,446 and 6,353,892.
Upon issuance of a print command by client computer170 to print a secure document,TextSafe module270 intercepts a print event and forwards it to documentdecrypter275.Document decrypter275 analyzes print information within the PRINTINFO block and determines a corresponding action. Specifically,document decrypter275 determines whether (i) to display a default error message; (ii) to display the MSG message; or (iii) to initiate a print request.Coordinator280 then performs the action.
Reference is now made toFIG. 3A, which is a simplified block diagram of a print server for controlled printing, in accordance with a preferred embodiment of the present invention. Shown inFIG. 3A isprinter server160 fromFIG. 1.Print server160 includes two core modules: aprint console305 and aprint engine310.Print console305 is a public interface ofprint server160. Preferably, client communications go throughprint console305.Print console305 preferably accepts print requests and presents a user with a print options interface. In a preferred embodiment of the present invention, a jsp (Java server page) is used in conjunction with a servlet for the print options dialogue.
After print options have been selected,print console305 preferably passes the information to printengine310. In a preferred embodiment of the present invention,print engine310 requests a document from a specified location, viaMirage server software155, watermarks the document as required, and prints the document to aprinter spool315.
Print console305 is responsible for receiving print requests generated by a client computer and sent viacoordinator280. Preferably, the client computer includes print information associated with the document in its request. Such print information is generated by a document processor, such as document processor210 (FIG. 2A), and is preferably encrypted and embedded within a document currently being viewed, as described hereinabove. Preferably, onlyprint console305 can decode print information generated bydocument processor210. In a preferred embodiment of the present invention,print console305 is a Java servelet.
In a preferred embodiment of the present invention, a print console properties file contains the following configuration information:
- Default watermarking options
- List of available printers, and each printer's properties
- List of native document formats supported byprint engine310
 In an alternate embodiment of the present invention,print console305 may receive default print settings from an administration module.
 
Preferably, whenprint console305 receives print information, it analyzes the print attributes together with data in the properties file, and appropriately populates fields in the .jsp print options page. The generated .jsp page is sent back to a user, who can then set print options within a form.
The user selects print options and clicks on “OK.” Print options may include inter alia:
- Page orientation
- Printer
- Page range
- Color/Black & white
- Duplex/Multi-page
- Other print options
 A user interface with a sample print options dialogue, in accordance with a preferred embodiment of the present invention, is illustrated inFIG. 3B.
 
The print option data filled in by the user is then submitted by the form back toprint console305.Print console305 processes the data and callsprint engine310 to print the document. Whenprint engine310 finishes, it returns a value to printconsole305, which preferably sends back an HTML page informing the user of the outcome.
Print console305 includes apre-check module320, which is an API that printconsole305 calls after receiving a request. Print console callspre-check module320 with print information, and pre-check module returns updated print information.Pre-check module320 enables software integrators to dynamically pre-process print information at run-time, before it is acted upon. As only the updated print information is acted upon, it may be appreciated thatpre-check module320 enables software integrators to:
- Perform a check with a hack-end system before showing the user the print options dialogue
- Perform pre-print logging
- Implement digital rights management (DRM) technology
- Perform additional authentication
- Customize print options according to a specific user, such as by filtering a list of printers
 
As such, it may be appreciated thatpre-check module320 may be used to change print properties and permissions at print time.Pre-check module320 may also be used to ensure that a latest version of a document is printed, in conformance with the Food and Drug Administration (FDA) Office of Regulatory Affairs guidelines for electronic records and electronic signatures, relating to document versioning. These guidelines are described in Title 21 of the Code of Federal Regulations (21 CFR Part 11), available on the Internet at http://www.fda.gov/ora/compliance_ref/part11/.
Similarly,pre-check module320 may also be used to control how a document may be printed, through print options that it enables or disables.Pre-check module320 may also be used to enforce DRM rules, including how many times a document may be printed, and when a document may be printed.
Print engine310 preferably includes aprint engine API325 that can only be called byprint console305 or by a third party that desires to implement its own print console, such as a document management system provider. Preferably, theprint engine API325 cannot be called directly by users.Print engine310 includes adocument requester330, for requesting a document from database management server computer110 (FIG. 1) to be printed.
Print engine310 also includes a format pre-processor340 for converting various document formats into an internal format. Various pre-processing units feed into format pre-processor340. Shown inFIG. 3 areunits343,345 and347 for processing Word documents, HTML documents and Excel documents, respectively. Following format pre-processor340, documents are passed to awatermark processor350 for optional watermarking.
It may be appreciated thatwatermark processor350 enables dynamic processing of watermarks at run-time.Watermark processor350 also enables application of usage policies. For example, a watermark “Document valid Until . . . ” may be added at run-time. As such,watermark processor350 can be used to comply with 21 CFR part 11, mentioned hereinabove.
Followingwatermark processor350 documents are passed to aprint processor355, for generating a print command and delivering content to printspool315. As content is being delivered toprint spool315, apost-print API module360 is used for last-minute dynamic updating of print permission.
Implementation Details
In a preferred embodiment of the present invention, a controlled printing process includes three phases, as follows:
Phase I—Document Preparation:
When processing a document, information that the client will need to send to the print engine is included. Such information is either provided as one or more default parameters in a configuration file, or as part of an administration rule, or provided by a back-end web server, such as web server115 (FIG. 1) or a back-end DMS such as DMS130 (FIG. 1) when returning a document to be processed.
Reference is now made toFIG. 4, which is a simplified flowchart for document preparation within a copy protection application, in accordance with a preferred embodiment of the present invention. At step405 a web browser requests a document from a document server computer. Atstep410 the request is intercepted by an interceptor component within Mirage server-side software. The interceptor matches the request against administration rules, which preferably include printing attributes. The interceptor re-directs the request to a document processor, passing it a matching rule ID.
Atstep415 the document processor extracts print information from the rule. Atstep420 the document processor re-requests the document, passing a document URL and print attributes. In a preferred embodiment of the present invention, the print attributes may include a SUPPORTED attribute, indicating that printing is supported. Preferably, the document processor also sets a CKSM_SEED to allow authentication of DMS print attributes. Preferably, a configuration file is used to determine if attributes are to be check-summed.
When the document processor re-requests the document atstep420, the back-end system may return print attributes in its response. Such attributes supplement the print information already obtained through the document processor's properties file and the administration rules. Preferably, the DMS uses the print attributes to provide a print server with sufficient information to make an authorized request for the document at print time.
Atstep425 the interceptor again intercepts the document request, as was done atstep410, but this time the interceptor preferably forwards the request along to the document management system. Atstep430 the web server or DMS sends back the requested document. The DMS may also send print attributes in response to the print attributes received from the document processor. In a preferred embodiment of the present invention, depending on the value of ALLOW, the DMS decides whether or not to return print attributes at in its response If CKSM_SEED is set, the DMS checksums its print attributes. The DMS preferably includes information required by a print engine so as to make an authorized request for a native version of the current document at print time, If supported, the DMS may also include data that enables it to authenticate and authorize a user's print permission For example, this may be a one time token to be used for printing. In a preferred embodiment of the present invention, the DMS sends its print attributes within print headers or, more generally, as document meta-data.
Atstep435 the document processor receives a document. In a preferred embodiment of the present invention, the document processor combines the print attributes from the administration rule with the print attributes in the response from the DMS, and embeds them into an encrypted header. Atstep440 the document processor encrypts the document and sends it to the web browser for viewing. Atstep445 the web browser renders the encrypted document to a Windows API. Atstep450 the Mirage client software intercepts the rendering, decrypts encrypted data and displays it securely.
Phase II—Client-Side Trigger:
A user generally prints by clicking on a print icon in an application's toolbar or within a print preview window, by a mouse right-click and print, by using a CRTL+P shortcut, or by choosing File|Print. Additionally, printing can be requested within JavaScript or within a COM object, or via dynamic data exchange (DDE).
When the present invention is operative, a protected document is typically encrypted within applications. Thus, if an application were to print such document without the intervention of document processor210 (FIG. 2A), only encrypted data is printed.
In a preferred embodiment of the present invention, a user's attempt to print normally is intercepted by interceptor165 (FIG. 1), and printing is initiated withinMirage server software155. Following Phase I (Document Preparation) information necessary to initiate printing of a document byMirage server software155 is already encoded within a document header.
The header of a document to be printed is queried for print information. If such information is available, it is sent to a print server, such asprint server160.
When the header is queried, thee possibilities can arise; namely, (i) the document is not protected, (ii) the document is protected but not printable, and (iii) the document is protected and printable. Reference is now made toFIG. 5, which is a simplified flowchart for a controlled print process, in accordance with a preferred embodiment of the present invention. A user tries to print, and at step510 a web browser accordingly issues a request to print a document. Atstep520 TextSafe module270 (FIG. 2B) ofMirage client software185 intercepts the print request, and documentdecrypter module275 ofMirage client software185 is used to determine whether or not the document is protected. If not—for example, if the document does not have an encrypted header, then atstep530Mirage client software185 instructs the browser to process the print request in the normal fashion, and at step540 the browser prints the document.
Ifdocument decrypter275 determines atstep520 that the document is protected, then atstep550document decrypter275 determines if the protected document is printable. If, for example, the protected document does not include print information in its encrypted header, or if the encrypted header is not decryptable—such as for lack of an available key, or if a print server URL (SU) field has a zero size, then the document is not printable. At step560 a message is returned to the user, preferably using a MSG field in the document header, informing the user that the document is not printable.
If she documentdecrypter275 determines atstep550 that the protected document is printable, then the print request is forwarded tocoordinator module280 ofMirage client software185. Thereafter the web server authenticates the user and presents to the user a print options dialogue generated by print console305 (FIG. 3 A). If the user is authenticated, then atstep570 print server URL and print information (PRINTINFO) is provided to the print dialogue. In a preferred embodiment of the present invention, the print dialogue is a browser control, although this is not necessary. Atstep580 the web browser forwards the print request to a print server designated by a SU, and atstep590 the print server preferably enables the user to select print options.
It is noted that the in a preferred embodiment of the present invention, the process ofFIG. 5 is performed at the client side. This is advantageous for catching print operations as early as possible.
Phase III—Server-Side Printing:
Reference is now made toFIG. 6, which is a simplified data sequence diagram for an authentication and secure print workflow, in accordance with a preferred embodiment of the present invention.
Preferably, sufficient print information (PRINTINFO) is provided in Phase I so that when the client sends printing instructions in Phase II, the print server has sufficient information to request the document and allow the back-end system to authorize the user's request to print the document. In a preferred embodiment of the present invention, PRINTINFO includes inter alia the SU and the document URL.
In the last step of Phase II (Client-Side Trigger); namely, step590 (FIG. 5), coordinator280 (FIG. 2B) opens a browser window to the print server URL (SU). If there was data in the encrypted header Print POST Data (PD) field, this is also sent as POST data. Additionally, there may be parametrized data in the SU and HD.
Preferably, the SU points to print console305 (FIG. 3A), which is a Java servlet.Print console305 decodes data in the SU and header POST buffer, and recreates the print information, PRINTINFO.Print console305 callspre-check module320, passing in PRINTINFO.Pre-check module320 allowsprint console305 to:
- Check against the DMS if the user has permission to print the document
- Check that the document is available and the correct version
- Check digital rights management rules
- Check status of the user
- Get a list of printers and their properties for the user
- Log the begin of the print process and the print options
 
If the user is permitted to print the document, PRINTINFO is preferably saved in a current connection session.Print console305 preferably decides if either the native or HTML version of the document should be printed. Using its internal list of printers and other print information obtained frompre-check module320,print console305 uses a .jsp page to generate an HTML form that allows the user to select print options. The .jsp page is sent back to the user.
Print console305 receives the user's print settings.Print console305 uses the user's print settings to pass appropriate PRINTINFO data to printengine310, for printing the document.
The print engine's document requester330 requests the document from a document management system, such as DMS145 (FIG. 1). Preferably, included in the request are cookies, and headers that the DMS specified when the document was requested for viewing. Such information allowsprint engine310 to request the document for printing, assuming that the DMS has not since revoked the user's permission to print the specified document.Print engine310 also sends print attributes allowing the DMS to choose final print options and set watermark properties. Preferably, the DMS logs the print request for the user.
Print engine310 receives the document and resolves the watermark data, and tries to print the document. If necessary,print engine310 calls an external watermark engine to generate a watermark image, according to watermark values.Print engine310 returns the results to printconsole305, which in turn sends hack an HTML page advising the user whether or not the job was successful.
Print and Watermark Attributes
In a preferred embodiment of the present invention, print and watermark attributes are sent to the recipient either as HTTP header values, or as metadata within a document. Table I hereinbelow indicates a specific set of print attributes used in a preferred embodiment of the present invention. Preferably, all values are URL-encoded.
| Header Name | Values | Description & Notes | 
|  | 
| ALLOW | “YES” | “NO” | Default is “No”. The last value | 
|  |  | received is the one that should be | 
|  |  | used. | 
| The following parameters are only processed after the Document | 
| Processor does a document re-request. These parameters are used by the | 
| print server for re-requesting the document for serving. | 
| H_GENERAL | {Encoded array | Headers common to both native and | 
|  | of headers} | HTML requests. Will be overridden, | 
|  |  | if specified again in the format | 
|  |  | specific headers, (DP re-request only.) | 
| U_HTML | {URL} | The URL of the HTML version of this | 
|  |  | document. Normally will be the URL | 
|  |  | currently processed. | 
|  |  | (DP re-request only.) | 
| H_HTML | {Encoded array | Any special headers/cookies needed | 
|  | of headers} | to request the HTML version. | 
|  |  | (DP re-request only.) | 
| U_NATIVE | {URL} | The URL of the native version. | 
| H_NATIVE | {Encoded array | Any special headers/cookies needed | 
|  | of headers} | to request the native version. | 
|  |  | (DP re-request only.) | 
| M_NATIVE | {MIME TYPE} | | Used by the print engine to determine | 
|  | {file extension} | if it can print the native version, | 
|  |  | otherwise it will print HTML version. | 
|  |  | (DP re-request only. | 
| The following parameters are processed by the Document Processor and | 
| again by the Print Server when the document is re-requested. | 
| WMRK | “YES” | “NO” | Default is “No”. The last value | 
|  |  | received is the one that should be | 
|  |  | used. | 
| WMRK_H | {space delimited | Watermark parameters for the | 
|  | list of | document header. Will be displayed in | 
|  | watermark types} | order specified. See Table II. | 
| WMRK_F | {space delimited | Watermark parameters for the | 
|  | list of | document footer. Will be displayed in | 
|  | watermark types} | order specified. See Table II. | 
| WMRK_B | {space delimited | Watermark parameters for the | 
|  | list of | document body. Will be displayed in | 
|  | watermark types} | order specified. See Table II. | 
| WMRK_P | {space delimited | The current list of parameters that will | 
|  | list of | be used. | 
|  | watermark types} |  | 
| The following parameters are for security, to ensure that the data source | 
| is valid. | 
| CKSM | 128-bit value | Can only be returned in a HTTP | 
|  |  | header and not in document Meta | 
|  |  | Data. | 
| CKSM_SEED | 128-bit value | Cannot appear in a response, only a | 
|  |  | request. | 
| ALLOW | “YES” | “NO” | Default is “No”. The last value | 
|  |  | received is the one that should be | 
|  |  | used. | 
| The following parameter enables bypass of default print server and use | 
| of another print server instead. | 
| SU2 | {URL} | Only for DMS. Overrides SU value. | 
| PD2 | Byte data | Only for DMS. Overrides PD value. | 
| PH2 | Header | Only for DMS. Overrides HD value. | 
| MSG2 | String | If specified at document re-request | 
|  |  | time, will be used for MSG value. If | 
|  |  | used at print-request time, then used | 
|  |  | in results page. Binary values (e.g., | 
|  |  | \r\n) should be escaped. | 
|  | 
As can be seen from Table I, print attributes generally fall into two sets. The first set includes attributes used by the print server to determine how to print. Such parameters preferably allow the print server to decide whether it wants to print the native version of the document, when available, or alternatively to print an HTML version, when available. The first set of attributes includes U_HTML, U_NATIVE, M_GENERAL, H_HTML, H_NATIVE, and M_NATIVE. Preferably, these attributes are only processed by the document processor after the re-request of the document from the DMS. If the native format of the document is available, then preferably the U_NATIVE and M_NATIVE attributes are defmed and sent. The M_NATIVE attributes enable the print server to decide if it can print a specific format. Otherwise, if the U_HTML attribute is defmed, the HTML version can be printed.
The second set of print attributes are used to aid the back-end DMS to re-authenticate the print server and user when requesting the document for printing. Using H_GENERAL, the DMS can insert any headers that it needs to authenticate and authorize either the users or print servers to access the document. Preferably, H_GENERAL holds common headers. If specific headers are needed for the native or HTML version, they are preferably set using H_NATIVE and H_HTML, respectively.
The present invention also enables the DMS to use its own print server. In such a case, the DMS can override the print server URL (SU) by specifying SU2. Typically, SU2 is specified in the document processor's configuration or properties file. SU2 is encoded in the encrypted header as SU, which is the URL that the coordinator calls when attempting to print. Authentication information is preferably encoded in SU as a GET string.
If a DMS specifies its own print server, it can also set PD2, which overrides other data set by the document processor when processing the attributes. The PD2 attributes are preferably included in the encrypted header as a PD field. PD2 is preferably sent as POST data when the coordinator calls SU2. If SU2 together with the GET data exceeds a 1024 character limit, then the data is preferably included in PD2 rather than SU2.
In an alternate embodiment of the present invention, an API for the DMS is created, and sent a URL including a server IP and port number, a document ID and a username. In addition, a special account is created within the DMS that the print server can log into and impersonate a user and request a document in the user's name. For such an embodiment it is only necessary to send the URL.
Table II hereinbelow indicates a specific set of watermark attributes used in a preferred embodiment of the present invention. Preferably, all values are URL-encoded, and watermark attributes are not sent without a CKSM, if CKSM SEED was sent in the request.
| TABLE II | 
|  | 
| Watermark Attributes | 
| Header Name | Values | Description | 
|  | 
| STRING | String | User defined string | 
| USERNAME | String | Username | 
| PRINT_DATETIME | String | Time of printing | 
| CLIENT_IP | String | Address of client machine | 
| DOCUMENT_NAME | String | Document Name/URL/ID | 
|  | 
In a preferred embodiment of the present invention, watermarking parameters are either specified when the document is requested in Phase I, or when it is requested for printing in Phase III. Watermarking occurs if SUPPORT is set and WMRK is YES. The attribute WMRK is preferably sent both at document request and document print request.
The attributes WMRK_B, WMRK_F, and WMRK_H are preferably set by the DMS if watermarking is enabled. These attributes specify a watermark format for the body, footer and header, respectively. Each of these attributes takes a space-delimited list of watermark types, as specified in Table II. Default values are typically specified in the document processor's properties file.
During Phase I and Phase m, the attribute WMRK_P is preferably sent with the request. The DMS can specify a value for either of these attributes, and for others as well, by including in the header a parameter name and value. If the DMS specifies WMRK_B, WMRK_F, and WMRK_H, then preferably it should also set values for any new watermark parameters and for parameters specified in WMRK_P. The DMS can either set parameter values in Phase I or Phase III. There is no need in Phase III to send back an updated WMRK_P. If the print server is unable to calculate a value for a required watermark parameter, it does not include it in the watermark.
During Phase I and Phase III, the attribute WMRK_P is preferably sent with the request. The DMS can specify a value for either of these attributes, and for other as well, by including in the header a parameter name and value. If the DMS specifies WMRK_B, WMRK_F, and WMRK_H then preferably it should also set values for any new watermark parameters and for parameters specified in WMRK_P. The DMS can either set parameter values in Phase I or Phase III. There is no need in Phase III to send back an updated WMRK_P. If the print server is unable to calculate a value for a required watermark parameter, it does not include it in the watermark.
Reference is now made toFIG. 7, which is a simplified data flow diagram for setting print and watermark attributes for a document, in accordance with a preferred embodiment of the present invention.FIG. 7 illustrates how print and watermark attributes are provided from several different sources, including document processor210 (FIG. 2A), interceptor165 (FIG. 1),DMS145 andprint server160. As shown inFIG. 7, atstep1 the interceptor ascertains print and watermark attributes from a properties file and from administrative rules. The rules may contain the attributes ALLOW and WMRK. Such print and watermark attributes are sent to the document processor.
At step2, the document processor preferably sends the attribute SUPPORTED to the document management system. At step3, the document management system generally sends the ten attributes CKSM, ALLOW, WMRK, WMRK_P, U_HTML, U_NATIVE, H_GENERAL, H_HTML, H_NATIVE and M_NATIVE.
Atstep4, the document processor generates an encoded header including the print server URL (SU), print POST data (PD), header data (HD) and a print message (MSG). Preferably, the latter parameters are optional. The encoded header is embedded within the document, and the document is then sent to a client for secure viewing. Mirage client software at the client decrypts the encoded header and then decrypts the document for display.
The client subsequently issues a print request and, atstep5, the print request is sent to the print server along with the SU, PD and HD. At step6, the print server requests the document from the document management system. The print server preferably sends the attribute SUPPORTED.
At step7, the document management system sends the requested document to the print server. The document management system may send the four attributes CKSM, ALLOW, WMRK, and MSG.
After receiving the document, the print server prints it on a designated printer and, atstep8, issues a print report with MSG to the client.
In a preferred embodiment of the present invention, the print and watermark attributes sent atsteps1,2,3,5,6 and7 are sent as HTTP headers. The encoded header sent atstep4 is embedded within the document itself.
Preferably, the present invention imposes rules for order of processing attributes. Specific rules used in Mirage are as follows. Print and watermark attributes are processed in the order (i) document processor properties files; (ii) interceptor and administration rule attributes; and (iii) web server/DMS attributes. Relative to this order, the latter value specified for an attribute is used, overriding previous values, except for ALLOW and WMRK. Regarding ALLOW and WMRK, latter values of these attributes must complement and include previous values at their beginnings, or else they are ignored.
Additional Considerations
In reading the above description, persons skilled in the art will realize that there are many apparent variations that can be applied to the methods and systems described.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made to the specific exemplary embodiments without departing from the broader spirit and scope of the invention as set forth in the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than in a restrictive sense.