Approach for securely printing policy-enabled electronic documents based on print driver and printing device support

An approach is provided for securely printing policy-enabled electronic documents. According to the approach, a determination is made at a client device whether policy-enabled printing has been specified for a particular electronic document. If policy-enabled printing has been specified for the particular electronic document, then a determination is made whether a print driver, installed on the client device for supporting printing for a particular printing device, is configured to support policy-enabled printing. Also, a determination is made whether the particular printing device is currently configured to support policy-enabled printing. The particular electronic document is allowed to be processed at the client device for printing only if both the print driver is configured to support policy-enabled printing and the particular printing device is currently configured to support policy-enabled printing.

RELATED APPLICATION DATA

This application is related to U.S. patent application Ser. No. 12/059,836 entitled APPROACH FOR PRINTING POLICY-ENABLED ELECTRONIC DOCUMENTS USING LOCKED PRINTING, filed Mar. 31, 2008; U.S. patent application Ser. No. 12/059,916 entitled APPROACH FOR PROCESSING PRINT DATA USING PASSWORD CONTROL DATA, filed Mar. 31, 2008; U.S. patent application Ser. No. 12/059,986 entitled APPROACH FOR PRINTING POLICY-ENABLED ELECTRONIC DOCUMENTS USING LOCKED PRINTING AND A SHARED MEMORY DATA STRUCTURE, filed Mar. 31, 2008; and U.S. patent application Ser. No. 12/166,741 entitled PRINT DRIVER FOR PRINTING POLICY-ENABLED ELECTRONIC DOCUMENTS USING LOCKED PRINTING, filed Jul. 2, 2008; the contents all of which are incorporated by reference in their entirety for all purposes as if fully set forth herein.

FIELD OF THE INVENTION

This invention relates generally to printing of electronic documents.

BACKGROUND

The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, the approaches described in this section may not be prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.

The proliferation of communications networks, and in particular the Internet, has raised growing concerns about the security of information transmitted over networks. Numerous protection schemes have been implemented to secure electronic documents transmitted over the Internet, ranging from simple passwords to strong encryption. Policy-based solutions have also been developed that allow business organizations to control access to electronic documents. An electronic document for which the access thereto is controlled using a policy is referred to hereinafter as “policy-enabled document.” A policy defines the conditions under which a user is granted access to an electronic document. For example, a policy might specify that particular users are allowed access to the electronic document. Alternatively, the policy might specify that all users on a particular project, or all users at a specified level or higher within a business organization, may access the electronic document.

When a user attempts to open the electronic document through an application, the application prompts the user for user credentials, typically in the form of a user ID and password. The user credentials are authenticated to verify the user. Then, the credentials are provided to a policy server along with data that identifies the electronic document that the user is attempting to access. The policy server retrieves a policy associated with the electronic document and then determines, based upon the policy, whether the user should be allowed to access the electronic document. The policy server returns data to the application that indicates whether the user is allowed to access the electronic document. The application selectively allows the user access to the electronic document based upon the data provided by the policy server.

One of the main benefits of the policy-based approach is that the access rights for any number of electronic documents may be changed by changing single policy, without having to change each of the electronic documents. For example, a business organization may change a single policy for a product that may affect access to a hundreds or even thousands of electronic documents.

One of the limitations of using policies to control access to electronic documents is that once a user has been granted access to an electronic document, the electronic document may be distributed to and accessed by other users, either in electronic or printed form. For example, once a user has been granted access to a policy-enabled electronic document and requested that the policy-enabled electronic document be printed, the print data generated by the print driver may no longer contain the data that indicates that the electronic document reflected in the print data is a policy-enabled electronic document. This may occur, for example, when the print driver performs a data conversion or translation, e.g., from Portable Document Format (PDF) to a Printer Command Language (PCL). The result is that third parties intercepting the eavesdroppers can access any portion of the print data. Furthermore, once received by a printing device, the printed data will not be treated as containing a policy-enabled electronic document, since the print data no longer contains the data that indicates that the electronic document reflected in the print data is a policy-enabled electronic document. Based on the foregoing, there is a need for an approach for securely printing policy-enabled electronic documents.

SUMMARY

An approach is provided for securely printing policy-enabled electronic documents. According to the approach, a determination is made at a client device whether policy-enabled printing has been specified for a particular electronic document. If policy-enabled printing has been specified for the particular electronic document, then a determination is made whether a print driver, installed on the client device for supporting printing to a particular printing device, is configured to support policy-enabled printing. Also, a determination is made whether the particular printing device is currently configured to support policy-enabled printing. The particular electronic document is allowed to be processed at the client device for printing only if both the print driver is configured to support policy-enabled printing and the particular printing device is currently configured to support policy-enabled printing.

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention. Various aspects of the invention are described hereinafter in the following sections:I. OVERVIEWII. ARCHITECTURE FOR SECURELY PRINTING POLICY-ENABLED ELECTRONIC DOCUMENTSIII. SECURELY PRINTING POLICY-ENABLED ELECTRONIC DOCUMENTSIV. IMPLEMENTATION MECHANISMS
I. Overview

An approach is provided for securely printing policy-enabled electronic documents. According to the approach, a determination is made at a client device whether policy-enabled printing has been specified for a particular electronic document. If policy-enabled printing has been specified for the particular electronic document, then a determination is made whether a print driver, installed on the client device for supporting printing to a particular printing device, is configured to support policy-enabled printing. Also, a determination is made whether the particular printing device is currently configured to support policy-enabled printing. The particular electronic document is allowed to be processed at the client device for printing only if both the print driver is configured to support policy-enabled printing and the particular printing device is currently configured to support policy-enabled printing.

This approach ensures that policy-enabled electronic documents are processed for printing when it is known that the policy information specified for the policy-enabled electronic documents will be retained and used during printing.

II. Architecture for Securely Printing Policy-Enabled Electronic Documents

FIG. 1is a block diagram that depicts an arrangement100for securely printing policy-enabled electronic documents. Arrangement100includes client devices102,104,106, a printing device108and a document policy management system110communicatively coupled via network112. Client devices102,104,106may be implemented by any type of client devices. Example implementations of client devices102,104,106include, without limitation, workstations, personal computers, laptop computers, personal digital assistants (PDAs), cellular telephony devices and any type of mobile devices. In the example arrangement depicted inFIG. 1, it is assumed that client devices102,104,106are configured with an application program and a print driver that corresponds to printing device108. Example application programs include, without limitation, a Word processor, a spreadsheet program, an email client and financial software.

The print driver on each client device102,104,106is configured to process data from the application program and generate print data that is provided to printing device108for processing. The print data includes a plurality of print commands which, when processed by the printing device108, cause a printed version of the electronic document to be generated at the printing device108. Thus, the application program and the print driver on each client device102,104,106operate together to generate and provide print data to printing device108.

The print driver on each client device102,104,106is also configured to generate a graphical user interface that allows a user to specify attributes of one or more access policies to be applied to an electronic document. Example attributes include, without limitation, a name of an access policy and a location of an access policy. The access policies define what users may access certain electronic documents. For example, an access policy may define that users having certain characteristics, e.g., being at a certain level or being a member of a group or project within an organization, may access an electronic document. The print drivers obtain document policy data from the document policy management system110and present the information on the graphical user interface and allow a user to select a particular policy to be applied to an electronic document. As described in more detail hereinafter, the print drivers then include in print data, data that indicates the one or more attributes of the access policies selected by the user. The graphical user interface also allows a user to specify that locked printing is to be used to print a particular electronic document. Client devices102,104,106may be configured with other mechanisms, processes and functionality, depending upon a particular implementation.

Printing device108may be implemented by any type of device that is capable of processing print data and generating printed versions of electronic documents reflected in the print data. For example, printing device108may be a multi-function peripheral (MFP) that includes any combination of printing, copying, facsimile and scanning capability, etc. Document policy management system110is an entity that stores and manages access policies and is capable of determining, based upon a policy, whether a user is authorized to print an electronic document. For example, given a user ID, password and identification of an electronic document, document policy management system110is able to determine whether, based upon a policy, the user is authorized to print the electronic document.

Network112may be implemented by any type of medium and/or mechanism (wired or wireless) that facilitates the exchange of information between the client devices102,104,106and printing device108. Furthermore, network112may use any type of communications protocol and may be secured or unsecured, depending upon the requirements of a particular application. Note that although arrangement100includes a single printing device108, the approach is applicable to any number of printing devices. Also, although the document policy management system110is depicted inFIG. 1as a separate network entity, the functionality of the document policy management system110may be co-resident on other devices, such as client devices102,104,106and printing device108.

FIG. 2is a block diagram of an arrangement200for securely printing policy-enabled electronic documents according to one embodiment of the invention. Arrangement200is similar to arrangement100, except that only a single client device is depicted, for purposes of explanation, and additional details are depicted for the various elements. Arrangement200includes a client device202, a printing device204and a document policy management system206that are communicatively coupled via a network208. Client device202includes an application program210and a print driver212.

Printing device204is configured with a user interface214, a print process216, a locked print process218and storage220that stores print data222. User interface214may be any mechanism and/or medium that provides for the exchange of information between a user and printing device204. Examples of user interface214include, without limitation, a control panel with a display and keypad or keyboard, a cathode ray tube (CRT), a liquid crystal display (LCD), a keyboard, touchpad, mouse, trackball, a microphone and speakers, and any combination thereof. Printing device204may be configured to display information on user interface214in any number of languages, depending upon a particular implementation. As with conventional printing devices, the user interface214on printing device204may provide limited capability to easily enter alphanumeric strings.

Print process216may be implemented by one or more processes for processing print data received from client device202and for generating a printed version of an electronic document reflected in the print data. Print process216and locked print process218may be implemented as resident processes on printing device204. Alternatively, print process216and locked print process218may be made available to printing device204on a removable media or may be implemented at a remote location with respect to printing device204. Locked print process may be implemented by one or more processes for providing locked print services on printing device204. Locked print process218may include a policy client224that interacts with the document policy management system206, as described in more detail hereinafter. The document policy management system206includes access policy data226that defines one or more access policies that may be applied to electronic documents to control user access to the electronic documents on printing device204. For example, suppose that a particular user requests access to particular print data stored in print data222. The particular print data may represent a particular locked print job stored at printing device204. The user typically enters user credentials, for example a user ID and password, via user interface214. After the user credentials are verified, policy client224contacts document policy management system206to determine whether the user is authorized, based upon a policy reflected in access policy data226, to access the particular print data. This may include policy client224sending to document policy management system206data that indicates the user and the particular print data. Document policy management system206determines, based upon access policy data, whether the user is authorized to access the particular print data and informs policy client224. For example, suppose that an access policy reflected in access policy data226specifies that a user must be at an executive employment level to access the particular print data. Document policy management system206determines whether the user has the required employment level of at least executive. If so, then the user is authorized to access the particular print data. Once the determination has been made, locked print process218then grants the user access to the particular print data, e.g., to print the particular print data, if the user is authorized to access the particular print data.

Storage220may be implemented by any type of storage, including volatile storage, non-volatile storage, or any combination of volatile and non-volatile storage. Examples of storage220include, without limitation, random access memory (RAM) and one or more disks. User interface214, print process216, locked print process218and storage220may be implemented in hardware, software, or any combination of hardware or software, depending upon a particular implementation.

In arrangement200, a user generates or accesses an existing electronic document via application program210. Example application programs include, without limitation, a Word processor, a spreadsheet program, an email client and financial software. The user indicates a desire to print the electronic document via a graphical user interface generated by application program210. Print driver212generates a graphical user interface that allows a user to specify attributes of one or more access policies to be applied to an electronic document. Print driver212may obtain document policy data from the document policy management system110that identifies available policies and/or policy attributes. Print driver212displays the available polices and attributes on a graphical user interface and the user selects one or more policies and/or attributes to be applied to the electronic document.

For example, suppose that the electronic document contains sensitive or confidential information. The user may specify that only users of a particular executive employee group are allowed to print the electronic document by specifying that an executive employee group policy be applied to the electronic document. The graphical user interface also allows a user to specify that locked printing is to be used to print a particular electronic document. Print driver212generates print data that includes print data that indicates the one or more attributes of the access policies selected by the user. For example, the print data may include information that indicates one or more attributes of one or more access policies to be applied to the electronic document. For example, the print data may include an APSPASSWORD command indicating that the electronic document contained in the print data is a policy-enabled electronic document. As another example, the print data may include a PDFPASSWORD command indicating that the electronic document contained in the print data is a password protected PDF document. The following Printer Job Language (PJL) headers are examples of data that may be included with the print data to indicate that access policies are applied to the electronic data:

In this example, the PJL headers indicate the URL of document policy management system206, a policy server user ID and a policy server password. Document policy management system206manages the access policies used to control access to the electronic document. The policy server user ID and policy server password are used by document policy management server206to authenticate the user. In addition to the foregoing example PJL headers, other PJL headers may be included to specify the particular access policies selected by a user. If the print driver supports policy-enabled printing, then the example foregoing information associated with the electronic document to be printed will be included in or with the print data generated by the print driver, so that the policy can be applied by the printing device. As previously described herein, the approach may be used in conjunction with locked printing. Therefore, in situations where a user designated locked printing, the print data also includes data that indicates that locked printing has been specified for the electronic document.

The data indicating that an electronic document is a policy-enabled electronic document, as well as other information such as whether locked printing is to be used, may be contained in a header portion of the print data, in the body portion of the print data, or any combination of a header portion and body portion of the print data. For example, in some implementations, the application that generates the print data in conjunction with a print driver may create a header that is appended to the print data and the header contains one or more commands that indicate that the electronic document contained in the print data is a policy-enabled electronic document. According to one embodiment of the invention, the presence in the print data of an APSPASSWORD command indicates that the electronic document is a policy-enabled electronic document.

Print driver212then causes the print data to be transmitted over network208to printing device204where the print data222is stored on storage220and managed as locked print data. A user then logs into printing device204and is authenticated. For example, the user may be queried to enter a user ID and password via user interface214and the user ID and password are verified by locked print process218. Policy client224interacts with document policy management system206to determine the policies that the user satisfies. For example, policy client224may transmit the user ID to document policy management system206which, based upon access policy data226, identifies one or more groups that the user is a member of and/or one or more policies that the user satisfies. Locked print process218then grants the user access to print data222based upon the user credentials and the policies applied to the print data222. Referring to the prior example, suppose that the user is an executive of a business organization. Policy client224supplies the user ID to document policy management system206and receives data that indicates the authorized policies for that user ID which, in the present example, includes an executive level policy. Locked print process218determines which print data222the user is allowed to print based upon the user being allowed to access print data222having an executive level policy or lower and generates data on a graphical user interface, e.g., on user interface214, that indicates the electronic documents that the user is allowed to print. The user selects one or more of the electronic documents for printing and the electronic documents are printed. As an alternative, policy client224may provide to document policy management system206the user ID and policies specified for print data222and receive data indicating which policies the user satisfies.

FIG. 3is a data flow diagram300that depicts relationships between various example client processes executing on a client device, such as client device202. In this example, a client device includes an application program302, a print driver304, printer capabilities data306, a print data submission client308and a spooler310. Application program302may correspond to application program210and print driver304may correspond to print driver212inFIG. 2. The printer capabilities data306, print data submission client308and spooler310are not depicted inFIG. 2for purposes of explanation, but might also be implemented on client device202. Application program302generates and provides application data to print driver304. Print driver304processes the application data in conjunction with printer capabilities data306and generates print data that is in a format understood by a target printing device that was selected by a user through application program302. Printer capabilities data306is data that describes the current capabilities of the target printing device. In the context of Postscript printing, an example of print driver304is a Postscript print driver and an example of printer capabilities data306is a Postscript Printer Description (PPD) file.

Print data submission client308receives the print data from print driver304and adds policy and security information received from application program302. For example, print data submission client308may add policy and security information to a job control header in the print data. Print data submission client308provides the modified print data to spooler310, which queues and transmits the modified print data to the target printing device.

III. Securely Printing Policy-Enabled Electronic Documents

FIG. 4is a flow diagram400that depicts an approach for securely printing a policy-enabled electronic document. In step402, a user initiates printing of an electronic document. For example, a user may create a word processing document using application program210(in the context of application program210being a word processor) and initiate printing of the electronic document. The electronic document may be in a particular format, for example PDF. A user typically initiates printing of an electronic document by selecting one or more graphical user interface objects, such as buttons and menus. A user will typically also select a target printing device on which the electronic document is to be printed. The user may also apply various protections and controls that apply to the printing of the electronic document. For example, the user may apply a policy to the electronic document that specifies that only individuals who are members of a particular group may print the electronic document. The particular group may represent a group within a business organization, such as a department, a project team, or an executive level. Policies are typically applied by a user selecting one or more user interface objects that indicate attributes of a policy. Once the print data is received by printing device204, the print data222is stored on storage220and access to print data222is managed by locked print process218. A user enters user credentials, e.g., a user ID and password, via user interface214. The user credentials are verified and the user is given access to, e.g., the ability to print, certain stored print data222based upon the access policy data226.

In step404, the application program determines whether policy-enabled printing is specified for the electronic document. This may be determined, for example, by the application program recognizing that the user has specified that a particular policy is to be applied to the electronic document. Alternatively, the application program may examine metadata associated with the electronic document that indicates that policy-enabled printing has been specified for the electronic document.

In the present example, it is presumed that policy-enabled printing has been specified for the electronic document. In step406, a determination is made whether the print driver212supports policy-enabled printing. In the context of printing electronic documents in PDF, this may include, for example, determining whether the print driver212supports direct PDF printing. If print driver212does support policy-enabled printing, then data related to policy-enabled printing will be preserved by print driver212and included in or with the print data generated by print driver212and transmitted to printing device204.

If, in step408, a determination is made that print driver212supports policy-enabled printing, then in step410the current configuration of printing device204is retrieved. The current configuration of printing device204may be reflected in configuration data stored on client device202. The current configuration of printing device204may also be retrieved from printing device204. For example, application program210or print driver212may generate and transmit to printing device204a request for configuration data. Printing device204supplies the configuration data in response to the request. The configuration data specifies the current configuration of printing device204including, for example, whether printing device204currently supports policy-enabled printing.

In step412, a determination is made whether the printing device supports policy-enabled printing. This may be performed, for example, by examining the configuration data retrieved from printing device204. If, in step414, a determination is made that the printing device supports policy-enabled printing, then in step416, printing proceeds. This typically includes querying the user for information related to a policy to be applied to the electronic document.FIG. 5is an example user interface screen500displayed to query the user for this information. User interface screen500includes a user name field502for a policy server, or in the present example, for document policy management system206. User interface screen500also includes a policy server password field504and a document password field506. User interface screen500also includes a job type field508for specifying a print job as being, for example, a normal print job or a locked print job. User interface screen500includes example user interface fields for purposes of explanation. The particular fields used may vary, depending upon the requirements of a particular implementation.

Returning toFIG. 4, if in step408, the printer driver does not support policy-enabled printing or, if in step414, the printing device does not support policy-enabled printing, then in step418, printing of the electronic document is prevented.

IV. Implementation Mechanisms

The approach described herein for printing policy-enabled electronic documents using locked printing may be implemented on any type of computing platform or architecture. For purposes of explanation,FIG. 6is a block diagram that depicts an example computer system600upon which embodiments of the invention may be implemented. Computer system600includes a bus602or other communication mechanism for communicating information, and a processor604coupled with bus602for processing information. Computer system600also includes a main memory606, such as a random access memory (RAM) or other dynamic storage device, coupled to bus602for storing information and instructions to be executed by processor604. Main memory606also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor604. Computer system600further includes a read only memory (ROM)608or other static storage device coupled to bus602for storing static information and instructions for processor604. A storage device610, such as a magnetic disk or optical disk, is provided and coupled to bus602for storing information and instructions.

The invention is related to the use of computer system600for implementing the techniques described herein. According to one embodiment of the invention, those techniques are performed by computer system600in response to processor604executing one or more sequences of one or more instructions contained in main memory606. Such instructions may be read into main memory606from another computer-readable medium, such as storage device610. Execution of the sequences of instructions contained in main memory606causes processor604to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

The term “computer-readable medium” as used herein refers to any medium that participates in providing data that causes a computer to operation in a specific manner. In an embodiment implemented using computer system600, various computer-readable media are involved, for example, in providing instructions to processor604for execution. Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device610. Volatile media includes dynamic memory, such as main memory606. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or memory cartridge, or any other medium from which a computer can read.

Computer system600can send messages and receive data, including program code, through the network(s), network link620and communication interface618. In the Internet example, a server630might transmit a requested code for an application program through Internet628, ISP626, local network622and communication interface618. The received code may be executed by processor604as it is received, and/or stored in storage device610, or other non-volatile storage for later execution.

In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is, and is intended by the applicants to be, the invention is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.