WO2000068817A1 - Generalized resource server - Google Patents

Abstract

A technique for controlling network resources. The resources are controlled by a generalized resource server (629). The user communicates with the server by means of a control client (613). To control a resource, the user provides control inputs to the client. The client uses the inputs to make a package (615) including sender control information (617) which the client sends via email to the server. The server augments the package with additional information where necessary to produce output (622) which controls the resource. The server further permits administrators to monitor and control the use of the resources. One application of the technique is to control printers. Users, administrators, and recipients can control use of the printers. The techniques can further implement a system (2201) which permits a user to order an electronically-distributed document and receive a printed copy of the document without having access to the document's electronic form.

Description

Generalized resource server

Background of the invention

1. Field of the invention

The invention relates generally to techniques for making the resources provided by a computer system available to users of the computer system and more specifically to techniques for simplifying access by remote users to such resources.

2. Description of the prior art: FIG. 5

For purposes of the present discussion, a resource is any hardware or software component of a computer system which is available to users of the computer system. Examples of resources are printers, displays, storage devices, and so on. One of the commonest kinds of resources is a printer, and printers will be used as example resources in the following discussion.

From the time computer systems began to be connected with each other, the users of one computer system have wanted to be able to use resources on other computer systems. For example, one easy way of providing a copy of a document to a colleague is simply printing the document out on a printer in the colleague's office. System 501 in FIG. 5 shows a typical arrangement for permitting a user of a personal computer 503 to print out documents not only on the user's own printer 521(i), but also on a number of other printers 521 that are connected to a local area network (LAN) 523 to which PC 503 is connected.

Continuing in more detail with system 501, PC 503 and any other PC connected to LAN 523 has a display device 505, a keyboard 509, and a mouse 517. PC 503's processor consists of a memory 515 and processing hardware 513. PC 503 is coupled to a private printer 521(i) and via LAN 523 to a number of other printers 521. Shown in display 505 and memory 515 are the components of PC 503 involved in printing a document 517 on a printer 521. When a user wishes to print a document, the user selects the print operation from a menu of file operations and a print screen 507 appears. Print screen 507 permits the user to select one of the printers 521 coupled to PC 503, and the appearance of print screen 507 changes depending on the printer selected. That is, print screen 507 is per-printer. The purpose of print screen 507 is to i obtain the information which a particular printer 521(1) requires to print document 517, and the information which the user provides depends on the printer. In many cases, the user provides information by default, that is, the information was provided earlier and is used by the computer system unless the current user of the printer changes it.

The default information and the information which the user explicitly enters in print screen 507 make up parameters 518, which serve together with document 517 as inputs for printer driver 519 for the selected printer. The simplest case is private printer 521(i). This printer uses printer driver 519(i). A printer driver is software which takes its inputs and produces printer code 520 for the particular printer. Printer code 520 is a sequence of codes which represent document 517 and inputs received in print screen 507 and which printer 521(1) interprets to do the actual printing of the document on paper 522. Here, private printer 521(i) is directly coupled to PC 503, so printer driver 519(k) outputs printer code 520 to hardware 513, which in turn transmits it to printer 521(i)

In the case of the printers connected to LAN 523, each of these printers is equipped with a LAN interface 524, as is hardware 513. Presuming this time that the desired printer is printer 521(j), whose driver is driver 519(k), printer driver 519(k) again outputs the printer code 520 required for printer 521(j) to hardware 513, but since the destination is a printer connected to LAN 523, LAN interface 524 outputs printer code 520 in the format required for messages sent by LAN 523. This format is shown at LAN message 525. The exact format of LAN message 525 of course depends on the nature of LAN 525. Typically, printer message 525 is packaged as a sequence of LAN packets, all of which are addressed to the printer in question, here, printer 521(j). LAN interface 524 in printer 521(j) removes the packaging from printer code 520 and provides printer code 520 to printer 521(j), which interprets the code to print the document.

System 501 of course does "remote" printing only to the extent that the remote printer is accessible via LAN 523, which typically connects all of the printers in an office. LAN 523 may be replaced by a wide-area network (WAN), and the WAN may be world- wide in its scope, but even the WAN permits remote printing only to those who have some kind of access to the WAN. For those who do not, the only recourse is to send email to someone on the WAN via which the document may be accessed and ask that person to print the document on a printer attached to the WAN.

With the development of the Internet, it has become possible to assign an email address to a printer and use the email address to do remote printing on the printer from any system which has access to the Internet. A system which does remote printing in this fashion has been developed by XCD Incorporated, 1692 Browning Street, Irvine, CA 92606. A white paper describing this system could be found on 10/20/98 at http://www.xcd.com/white2.html . System 526 in FIG. 5 is an example of the kind of system described in the white paper. Using this system, PC 527 can print document 517 on a printer 535 which has an email interface 537 and has access to an email server 533. PC 527 is a standard PC, except that in addition to document 517 and PDR 519(i), its memory 515 contains email message maker 529, which takes the printer code 520 output by driver 519(i) and makes it into an attachment for an email message 539. The user of PC 527 specifies printer 535 in print screen 507 by means of its email address, and email message maker 529 sends email message 539 containing printer code 519 via internet 531 to email server 533, which handles email for printer 535. Printer 535 is connected to email server 533 by internet 531 or some other networking arrangement. Email interface 537 in printer 535 periodically polls email server 533 for email messages addressed to printer 535; when a message is present, email server 533 responds to the poll by downloading the message to email interface 537. Email interface 537 extracts printer code 520 from email message 539 and provides it to printer 535, which interprets it to print document 522.

An important advantage of system 526 is its use of email to transfer printer code 520. Private networks that are connected to the Internet use access filters at the point where they are connected to the Internet to establish a security domain that determines what kinds of messages on the Internet will be permitted to enter the private network's security domain. The boundary of such a security domain is shown at 541 in FIG. 5. Since email messages are generally read by humans instead of machines, they are generally permitted to enter the private network's security domain, and system 526 is thus able to avoid the complexities involved in dealing with security domains.

While both system 501 and system 526 permit remote printing, they have a number of problems. Foremost among them is the fact that both types of system require detailed knowledge about the printer to which the remote printing is being done. In the case of system 501, the remote user must know the topography of the network connecting the printers; in the case of system 526, the remote user must know the email address of the printer. More seriously, the remote user must in either case know what kind of printer the local printer is, must be able to associate the printer with the right printer driver 519(i) on the user's local system, and must be able to specify the proper information in the per-printer print screen.

The knowledge about the printer must of course not only be detailed, it must also be current. For example, the detailed information that a remote user has may be months or even years old, and when the remote user attempts to print, it may turn out that the printer no longer exists or has been replaced with a different model and therefore requires the use of a different driver. Moreover, much of the detailed information is subject to frequent change. For instance, if a printer may be loaded with either standard or legal-sized paper, the remote user must specify which paper should be used. Specifying this information is of course particularly troublesome in system 526, since there may be considerable delay between the time email message 539 is sent from PC 527 and the time it arrives in printer 535, and paper of the specified size must be available in printer 535 when the message arrives, not when it is sent. In no case can the remote user do what he or she would really like to do: simply specify that the document be printed at the desired location (perhaps expressed as "Joe Smith's printer", where Joe Smith is the ultimate recipient of the document), without concern for which printer it is printed on, what kind of printer it is, or what kind of paper the printer presently has loaded.

While the need for detailed knowledge about the printer on which the remote printing is being done is inconvenient for the remote user, it also causes problems for local users of the printer and for the manager of the system to which the printer belongs. Since a remote user who has the requisite knowledge about a printer can do anything a local user of the printer can do, the remote user can cause problems for the local users, for instance by using the printer to print unsolicited documents addressed to the local users. The fact that the remote user can do anything a local user can do further causes problems for the system manager, since it is far easier to enforce rules for the use of the printers on the local users than it is to enforce them on remote users. O 00/68817

The need for detailed knowledge about a printer upon which remote printing is done also makes it impossible for the system manager to hide the topology of the system from outsiders. Hiding the topology is good practice first, because it protects the system from misuse by outsiders. Hiding is good practice second, because it changing the system much easier. If the system topology is hidden, changing a printer does not affect remote users of the printer; if it is not hidden, changing a printer requires notification of all remote users of the printer.

Another problem that is not solved by systems of the type of system 501 or system 506 is the protection of intellectual property in digital representations of documents or images. The only source of a digital representation to be printed in system 501 or system 526 is the user's PC; the user can print any digital representation which the user can access from his or her PC, without regard to any copyright restrictions that may exist. On the other hand if a digital representation is not accessible from the user's PC, the user cannot print it on his or her printer. Distributors of digital representations are thus left with an unpleasant choice of either completely losing control over the digital representation or refusing to permit electronic access to it.

The detailed knowledge of the printer that is needed to do present-day remote printing is required because what is sent from the remote user to the printer is printer code 520, which completely specifies how the printer is to print the document. Sending printer code 520 has a number of other disadvantages:

• printer code 520 is typically very large; the size is a problem even in LANs, and in WANs and on the Internet, the result can be serious performance problems;

• because printer code 520 completely specifies what the printer is to do, the remote print job will fail if the printer cannot do what is specified, for example, if it has the wrong size of paper.

• the remote user's computer system must have the proper printer driver for each of the printers the remote user wishes to use and must know which printer takes which driver.

While remote printing has been used as an example here, variations on the above problems occur wherever remote resources are used. For instance, a remote user may wish to archive a document at a remote archive; the same need for detailed knowledge of the archive site and of the archiving protocols is required as with printing, and the required detailed knowledge presents the same kinds of problems for the remote user and the system manager.

It is an object of the invention disclosed herein to solve these and other problems of remote printing in particular and remote resource usage in general.

Summary of the invention

The foregoing problems are solved by interposing a generalized resource server between the user of the resource and a set of resources and providing the user with a generalized resource control client to communicate between the user and the generalized resource control server. The generalized resource control client sends a job specification message to the generalized resource server. As its name implies, the message indicates the job the user wants done by one of the resources. Because the generalized resource server is interposed between the user of the resource and the resources, the job specification message need not provide all of the information needed to do the job; instead, the generalized resource server produces the resource job specification that actually causes a specific resource to do the job by augmenting the job specification message with the information needed to actually cause a specific resource to do the requested job.

For example, if the resource is a printer, the user need not specify a particular printer to the generalized resource control client, but only the person for whom the document is to be printed. The generalized resource control client specifies the person in the job specification message and the generalized resource server determines from the job specification message which printer is currently being used to print documents for that person and makes a resource job specification message for that printer. Similarly, the user need not specify a paper size to the generalized resource control client; instead, the generalized resource server determines what size the printer that is going to print the document is currently loaded with and specifies that size.

The user can additionally specify rules and preferences for the print job. For example, if the document to be printed requires a color printer, the user can so indicate to the generalized resource control client and the job specification will include a rule to that effect; if there is no color printer available to the generalized resource server, the generalized resource server will O 00/68817 not print the document and will send the user an e-mail message indicating why. With regard to preferences, the user can for example indicate that he or she prefers the document to be printed on both sides of the page; if the generalized resource server has a printer available that meets the other criteria specified by the user and can print a document on both sides of the page, it will use that printer; otherwise, it will print the document on one side of the page.

As will be immediately apparent from the foregoing, interposing a generalized resource server between the user and the resource make things much easier for the user, who is no longer required to have a detailed knowledge of the resource he or she wants to use. A corollary of the fact that the user no longer need have a detailed knowledge of the resource is that the generalized resource server hides the resources from the user. Thus, since the user specifies a printer by the name of a person, the printer that is actually used by the person can be changed without affecting the user at all.

Interposing the generalized resource server also gives the users, system administrators, and others involved in the use of the resources much greater control. The use of rules and preferences by users has already been illustrated above; the generalized resource server can, however, also apply rules and preferences from other sources, for example system administrators and in the case of printers, the recipients of the printed documents. When the resources are printers, the administrators determine rules for use of the printers, for example, the hours of availability of the printer or the manner in which a recipient of a document must identify himself. A recipient can indicate whether he or she wants a document that has been sent to be printed and delivered to him or her to be in fact printed and delivered.

Another advantage of interposing the generalized resource server is that it is able to carry out other actions in the course of dealing with the job specification message. One class of such actions is notifications to parties involved in the use of a resource. Again taking the printer example, when the generalized resource server cannot print a package as indicated by the sender, the generalized resource server notifies the sender; similarly, the generalized resource server notifies the recipient when a package has arrived for him or her, giving the recipient the opportunity to accept or reject the package, as described above. The generalized resource server may further send notifications to administrators, to document handlers, and to accounting departments. O 00/68817

The techniques described above can also be used to electronically distribute documents without making the document's electronic form publicly available. In this application, a generalized printer server mediates between a person who orders an electronically-distributed document and the owner of the document as well as between the person and the printer the document is printed on. The person who orders an electronically-distributed document provides a specifier for the document to the generalized printer server, and the printer server makes whatever licensing arrangements are needed, fetches the document, and has a printer print a hard copy of the document. The person who orders the document thus has all of the advantages of electronic distribution, but never receives a usable electronic copy of the document.

Other objects and advantages will be apparent to those skilled in the arts to which the invention pertains upon perusal of the following Detailed Description and drawing, wherein:

Brief description of the drawing

FIG. 1 is an overview of a presently-preferred embodiment of the invention;

FIG. 2 is a detailed block diagram of the package interpreter in a preferred environment;

FIG. 3 is a flowchart of threads employed in a preferred embodiment of the package interpreter; FIG. 4 is a flowchart of a processing thread employed in a preferred embodiment of the package interpreter;

FIG. 5 is a block diagram showing prior art techniques for doing remote printing;

FIG. 6 is a block diagram showing an overview of a generalized printer server;

FIG. 7 is a block diagram showing how a generalized printer server may be used within an organization;

FIG. 8 shows a sender print screen for the printer server;

FIG. 9 shows a second sender print screen for the printer server;

FIG. 10 shows how a sender sets sender policy for a job;

FIG. 11 shows how a sender sets control information for paper and print; FIG. 12 shows how a sender sets control information for recipients;

FIG. 13 shows how a sender sets delivery control information;

FIG. 14 shows how a sender sets notification control information;

FIG. 15 also shows how a sender sets notification and delivery control information; FIG. 16 shows how a sender adds or modifies addresses of recipients;

FIG. 17 shows how a recipient sets recipient policy on receipt of a package;

FIG. 18 is another example of how recipient policy is set;

FIG. 19 shows how the front panel of a printer may be used to authenticate a recipient; FIG. 20 shows the contents of a sender notification message;

FIG. 21 shows the contents of a recipient notification message;

FIG. 22 shows an embodiment of a generalized printer server that is utilized to protect intellectual property rights in documents;

FIG. 23 is a table of control information in a preferred embodiment; FIG. 24 shows a first part of an example package;

FIG. 25 shows a second part of an example package;

FIG. 26 shows a third part of an example package;

FIG. 27 shows a fourth part of an example package;

Reference numbers in the Figures have three or more digits: the two right-hand digits are reference numbers in the drawing indicated by the remaining digits. Thus, an item with the reference number 503 first appears as item 503 in FIG. 5.

Detailed Description The following detailed description will begin with an overview of the invention, will continue with an overview of how the invention is typically used in an organization such as a business, will then present details of the user interfaces for senders, recipients, and system managers in a preferred embodiment, and will finally present details of the implementation of the preferred embodiment.

Overview of a generalized printer server: FIG. 6

What is termed herein a generalized printer server is an entity in a system which mediates between users of printers and the printer. The generalized printer server receives requests for print jobs from users, processes the requests, and selects a printer to perform the print job. Because the generalized printer server mediates between the users of the printers and the printers, it is able to provide a printing interface to the users which hides the details of the printers and of network configurations and to give system administrators and recipients of printed documents control over whether a document is to be printed and if so, how and where it is to be printed. Similar entities can of course be employed to mediate between users of other resources and the resources themselves.

FIG. 6 shows a system 601 in which a generalized printer server 629 mediates between a sender at a sender PC 613 and a set of printers 623 which are either directly coupled to printer server 629 or are coupled thereto by means of a network, in this case, a LAN 523.

Communication between printer server 629 and sender PC 613 is by means of email messages sent via Internet 531. The email messages contain what are termed herein packages that describe the print job that the user of sender PC 613 desires printer server 629 to perform for him or her. Any communications technique could be used to send the package between sender

PC 613 and printer server 629; email is particularly advantageous because it is able to traverse any domain boundaries between sender PC 613 and printer server 629.

Continuing in more detail, sender PC 613 is an ordinary PC (or other type of processor) that has a connection to Internet 513 and is able to send and receive email. Sender PC 613 includes an email package maker program 611 which, when executed, causes sender PC 613 to make an email message containing a package 615 describing a print job. Package 615 has two main components, a set of package sender control information 617 which describe how the user of sender PC 613 wants printer server 629 to do the print job for him or her, and a set of one or more document representations 605 that represent the documents or other digital representations to be printed. In a preferred embodiment, document representations 605 are in Postscript®, a well-known document representation language provided by Adobe Systems Incoφorated.

In the following discussion, control information is information that determines whether, and if so, where and how the operation of printing the digital representations are to be performed. There are two broad classes of control information: rules, which set forth one or more conditions which must be satisfied for an action to take place or things that must be done if an action takes place, and preferences, which add information that should be taken into account if possible during the processing of a document. For example, there may be a rule in package sender control information 617 that requires that the print job be canceled if it cannot be done on a color printer. There may be a preference that the document be printed on both sides; if that is not possible, the document will be printed on one side. The document representations may be in any useful form; for example, they may be the representations employed by a particular kind of word processor. The representations may further be compressed or encrypted. A representation may further even represent a document indirectly; for example, if the user of sender PC 613 has found a document on the World Wide Web which he or she would like to have printed for a recipient (including him or herself) whose printer is controlled by printer server 629, the user may simply include the URL for the document in package 615; in that case printer server 629 can itself fetch the document and print it. An advantage of this arrangement is that printer server 629 can operate as an intermediary between the owner of the document and the user. While the owner of the document might not trust the user to simply print the document without saving it or distributing it further in electronic form, it may be able to trust printer server 629, and when that is the case, the owner can use printer server 629 to distribute hard copy of the web page without concern that the electronic version will thereby become obtainable.

As can be seen from the foregoing description of the contents of a package 615, email package maker 611 receives two kinds of input from the user of sender PC 613: control information 607, which becomes sender control information 609, which in turn determines how printer server 629 will print the job, and specifications of document representations 605. Control information 607 may be either global or per-document. In the former case, control information 607 establishes default sender control information 609 which is used when no special control information 607 for a given document is provided. An important difference between sender control information 609 and the kind of information provided in prior-art systems is that the user of sender PC 613 need have neither drivers for the particular printers coupled to printer server 629 in PC 613 nor any particular knowledge of the printers available to printer server 629 to make sender control information 609. For instance, instead of specifying a particular printer, the user of sender PC 613 may simply specify the name of the recipient and perhaps also the type of printer~for example, black and white or color.

The user interface which the user of sender PC 613 employs to make a package is as like as possible to that used in systems such as system 501 or system 506 to specify a print job. When the user of sender PC 613 wishes to print a document, the user opens the document and then specifies that it be printed. A printer server print screen 603 appears and the user specifies the per-document sender control information by filling in the print screen. When the user clicks the "done" button, email package maker 611 takes the input from the print screen and any necessary default control information from sender control information 609 to make package sender control information 617 and combines them with the document(s) to be printed in package 615. The documents will be printed as a single document, with continuous pagination.

Package 615 is an email message 616 that is directed to the email address of printer server 629. It goes to email system 612, which then sends it via Internet 531 (where Internet 531 is to be understood as any network upon which Internet protocols may be used) to email server 535 for printer server 629. Printer server 629 periodically polls email server 535 for messages, including messages 616 containing packages 615. When it finds such a package, it provides the package to an execution of package interpreter 621 program, which interprets the package to provide document representation 605 to a printer driver 519(i) for a specific printer 623(j) coupled to printer server 529 and then sends printer code 520 to printer 623(j).

In interpreting package 615, package interpreter 621 uses not only the information in package 615, but also information contained in administrative control information 618 and recipient control information 619 in printer server 629. Administrative control information 618 includes information which provides an administrator control over the following;

• who will use printer server 629;

• how printer server 629 will be used.

It should be noted here that the administrator has no control over the content of a document. The administrator further cannot access a document or force a document to be printed (unless he or she is a recipient of the package 615 to which the document belongs).

Recipient control information 619 includes at least information which indicates how a recipient is to authenticate him- or herself to printer server 629 and which of a list of packages received in printer server 629 the recipient has authorized to be printed.

Overview of control information: FIG. 23

Fig. 23 gives an overview of the kinds of control information employed in a preferred embodiment. Table 2301 has three columns. Column 2303 indicates general kinds of control information; arguments 2305 indicates the kind of information to which the control information is applied; kind 2307 indicates whether the control information is sender control information, recipient control information, or administrator control information; as may be seen from column 2307, some kinds of control information may be provided by both; for example, both the sender and the recipient may specify people to be notified of the print job. If the sender originates the control information, it is part of sender control information 609 if the recipient does, it is part of recipient control information 619; if the administrator does, it is part of administrator control information 618. In some cases, for example security control information, the administrator may set requirements globally, and to the extent that the administrator has not done so, a sender or recipient may set his or her own security policies.

Continuing in more detail, the control information in table 2301 is divided into three subclasses: general control information 2309, security-related control information 2325, and administrator-specific control information 2331. General control information includes the following:

• print for information 2311 , which indicates the recipient of a document by a user name or email address;

• print to information 2313, which indicates a specific printer and is used when the sender can and desires to specify the printer; • notify list 2315, which indicates who is to be notified about actions involved in the print job; both the sender and recipient may make notify lists;

• print after 2317, which specifies a time before which the job is not to be printed; either the sender or the recipient may indicate such a time;

• ask me before processing 2319, which specifies classes of print jobs that the recipient wishes to be asked about before permitting printing;

• confirm after picking up printed copy, which specifies that the sender wishes to receive an acknowledgement that the printed copy has been picked up; and

• printing options, which specify in detail how the document is to be printed. The printing options may be rules or preferences; in the former case, the document will not be printed unless all of the options can be satisfied; in the latter case, printer server 629 will make substitutions when it cannot satisfy an option. The security-related control information includes rules 2327 specifying that a receiver or administrator will accept only print jobs from packages 615 that include the sender's digital signature will be accepted in printer server 629 (these may be either global or per-sender) and rules 2329 specifying that a sender or administrator will permit only acknowledgements that contain the digital signature of the person making the acknowledgment. These, too, may be either global or per-acknowledger. Administrator control information 2331 includes rules 2333 specifying per-sender or recipient quotas on the use of printers, rules 2335 specifying notifications to an audit server, rules 2337 specifying notifications to billing or metering servers, and rules and/or preferences 2339 specifying which printers are authorized for which recipients.

Administrator control information 618 is typically global, that is, it applies to all packages received in printer server 629. The sender control information contained in package sender control information 617 is per-package; in some embodiments, the sender may be able to set global sender information in printer server 629. The recipient control information may be either global, for example the recipient may require that he or she be asked before a print job is done, or per-package, as is the case when the recipient accepts or denies the request to print the package. Package sender control information can be specified in the package using

Extensible Markup Language (XML). Serialized XML can also be used in printer server 629 to specify administrative control information 618 and recipient control information 619.

When a package 615 is received in printer server 629, it will typically be processed as follows: 1. Authentication phase

- Read email containing the package. Extract package signature if any. - Check administrator rules regarding senders - if there is no signature is this allowed ? is the signer a valid sender ?

- Check for undesired print requests.

2. Authorization phase

- Check admin rules - is user allowed to print on requested printer? Is the time range acceptable (a guest user may be allowed to print only during official working hours)?

- Check for recipient rules for this package (based on sender and subject) and take the appropriate actions (such as "Ask me before printing", "Delete" ).

3. Preprocessing phase - Typically things like quota checking. Also all control information is now extracted and is available to all other phases. Some resolution of conflicts (between sender/receiver rules) may occur at this stage. Also defaults are determined here (such as, if no printfor in the package, then which printer is to be used?). 4. Processing phase

- Typically the printer options. 5. Post-print phase

- Notifications to sender, audit server, billing/metering server.

What happens at each stage will of course depend on the content of package sender control information 617, administrator control information 618, and recipient control information 619.

Package inteφreter 621 begins by consulting administrative control information 618 to determine whether printer server 629 is presently permitted to perform print jobs for the sender and/or the recipient. If it is, the next step is to determine whether the recipient control information 619 indicate that the recipient desires the document to be printed. If it is clear from the package sender control information 617, administrative control information 618, and recipient control information 619 that the document(s) in package 615 is to be printed, package inteφreter 621 uses the recipient information from package sender control information 617, the information concerning printers associated with a recipient in administrative control information 618, and the requirements for the print job specified in package sender control information 617 to select a printer 623 (i) that fulfills the requirements of the control information. It then does whatever is necessary with document representation 605 from package 617 to put it into the proper form 622 for driver 519(j) for printer 623(i). What needs to be done will of course depend on the form of document representation 605 and on the local details that need to be added in order for the intended printer to inteφret the document representation correctly. If representation 605 has a form that driver 5190) can handle, it might not be necessary for package inteφreter 621 to do anything at all, or only to add local information before the representation is provider to driver 519(j); otherwise, package inteφreter 621 may have to translate the representation into a different form, as well as adding any necessary local details. If representation 605 is compressed, package inteφreter 621 will decompress it; if it is encrypted, package inteφreter 621 will decrypt it. If representation 605 is not the document itself, but rather an identification for it such as a URL, package inteφreter 621 will use the identification to fetch the document to printer server 629 and then do whatever is necessary for it to be sent to driver 519(j). When all this is done, the proper form 622 of the document for the driver is provided to driver 519(j), from whence it is output as printer code to printer 623 (i), which prints the document. As will be explained in more detail in the following, during the process of inteφreting and printing a document, printer server 629 sends notification messages to the sender, the recipient, and others involved in the printing process. For example, the recipient receives a notification when the document arrives and the sender receives a notification when it is printed. In a preferred embodiment, the notifications are sent by email. Notifications may also be used to log printer usage and where necessary to bill users.

Generalized printer server 629 in an office environment: FIG. 7

The foregoing description of generalized printer server 629 has presumed an environment in which there are only three classes of parties: a sender, a recipient, and an administrator. In a typical office environment, other classes of parties may be involved. For example, the person who creates a document may be different from the one who sends it, so a document creator may be involved in the process of specifying the print job as well as a document sender. Similarly, the recipient may not him- or herself interact directly with the printer, but may instead receive the document from someone who does. In the following, persons other than recipients who interact with the printers are termed document handlers. Finally, people other than the document sender, recipient, or handler may want to be notified when a document is printed; such people (or systems, for example an accounting system) are termed in the following notification recipients.

FIG. 7 shows how a system 701 involving a printer server 629 relates to these groups. Where an element of FIG. 7 corresponds to an element of FIG. 6, it carries the reference number of FIG. 6. All of the people who interact with printer server 629 in system 701 do so by means of email or equivalent messaging systems; as we have already seen, packages 615 are sent by email, notifications are sent by email, and control information is provided to printer server 629 by email. Beginning with sending system 613, two classes of users may be involved: document creator 703, who simply creates documents 605 that are to be printed using printer server 629, and document sender 705, perhaps creator 703 's administrative assistant, who actually makes a package 615 as required to print a document. To make the package, sender 705 sets sender control information 609 as required for the package, selects documents for the package, and uses the application program 707 that created the document to "print" the document using package maker 611 as the "driver" for printer server 629. Package maker 61 1 makes package 615 as described above and sends it via email to printer server 629.

Printer server 629 receives package 615 and uses package inteφreter 621 to inteφret its contents. Package inteφreter 621 has two main parts: unpackager 725 and policy manager 721. Unpackager 725 parses the package and sends its components to their destinations, with the package sender control information going to sender policy 721 and the documents to drivers 519. Of course, unpackager 725 may also decompress, decrypt, or in some cases actually fetch the documents to be printed.

Policy manager 721 updates and enforces the package sender control information 617, recipient control information 619, and administrative control information 618 which control printing in printer server 628. The complete set of control information in each of these areas is termed a policy; thus, in FIG. 7, we have sender policy 716, recipient policy 619, and administrator policy 618. As mentioned above, control information may be either global or per-print job. In the case of sender policy 716, the per-print job control information is package sender control information 617. In addition, there may be control information for senders that limit their use of the system. With recipient or administrative policy that is per-job, when a package arrives in printer server 629, policy manager 721 sends a notification 711 to the person who is to determine what the per-print job policy is for that job and receives an email response that indicates what the policy is to be. For example, the recipient control information for a given recipient 717 may indicate that the recipient is to be asked whether he or she wants to receive the document to be printed; when that is the case, policy manager 721 sends a notification to the recipient and the recipient responds by indicating which documents he or she wishes printed. The response establishes the per-package policy for that package, and only the documents indicated by the recipient are printed.

Policy maker 721 may also use notifications to inform users of the printers of policies concerning the printers. For example, if the office which printer server 629 serves is only open Monday-Friday 9-5, there may be a rule in administrator policy 618 that indicates that packages 615 will only be received during those hours and that when a package 615 arrives outside those hours, a notification is to be sent to the sender indicating that the package was not accepted and reminding him or her of the hours. Notification may similarly be sent to a sender if he or she is about to or has violated administrator policy concerning his or her use of a printer.

When policy manager 721 has determined from the global and per-job control information whether and where a job is to be printed, it notifies handler 717 who is responsible for the printer where the job is to be printed. Notification may again be by email, or may also involve a device such as a pager carried by handler 717. When printer 623 has finished printing the document, handler 717 delivers the document to the recipient. Of course, in many cases, the notification that the document is being printed is sent directly to the recipient, who then fetches the document from the printer him- or herself. In some systems, there may be administrator control information which permit printing of a document only if the proper recipient or handler is present at the printer to receive it. In such a system, the recipient or handler must identify him- or herself to printer server 629 by inputting an authentication code to the printer 623 and policy manager 721 will begin printing the document only after it has received the authentication code.

User interface for sender PC 613: FIGs. 8-16, 20 In a preferred embodiment, a user of sender PC 613 establishes global and per-package sender policy by means of print screens displayed on sender PC 613. FIGs. 8-16 show screens presently used to establish sender control information 609 in sender PC 613 (there may of course be other sender control information established as part of sender policy 716 in printer server 629 by an administrator or even a recipient). The screens of FIGs 8-16 closely resemble those used generally to control printers in PCs, but those familiar with such screens will notice differences that illustrate how printer server 629 differs from prior-art arrangements for controlling printers.

Beginning with Fig. 8, screen 801 is the screen that is actually used to print a document via printer server 629. All the user need do at this point to print the document on print server 629 is click on the "OK" button. The chief difference between screen 801 and standard print screens is shown at 803: instead of the name of a printer, there appears the name of a recipient; the name is one on a list of names which may be viewed by clicking on the button to the left of the name. Thus, the user of sender PC 613 need know only the name of the person for whom the document is to be printed; printer server determines from this name and other information in package sender control information 617 which printer 623(i) will actually be used to print the document. The information below the selected name indicates the following: • at 805, it is indicated that a printer server 629 is being used;

• at 807, it is indicated that the printer for John Reilly is on a printer server 629 whose email address is calypsoδrose . hp . com.

• at 809 is indicated a sender-assigned name for John Reilly.

At subject box 811, the user of sender PC 613 may type in a short description of the subject of the package being sent. This description becomes part of package sender control information 617.

FIG. 9 shows how the use of a recipient name instead of a printer name simplifies printing documents for multiple recipients. In print screen 901, recipient name 903 is the name of a group: the NPSD marketing team. As is apparent from the identification of the printer(s) at 905, the group consists of three individuals whose printers are on a printer server 629 whose email address is secure_mkt@rose . hp . com . Package sender control information 617 for the package 615 that will be produced when the OK button is clicked in print screen 901 will indicate that the document contained in the package is to be printed on printers used by the three members of the marketing group, and printer server 629 will print three copies of the document, one for each member of the group, with the copy for each member being printed on a printer with which administrative control information 618 associates the group member.

FIG. 10 shows how sender control information other than the recipient are established. FIG. 10 is the "Printers" screen that is reached in PCs using the Windows® 98 operating system manufactured by Microsoft Coφoration from the "My Computer" screen. As shown in this "Printers" screen 101, the printers include a printer icon 1003 which represents one or more printer servers 629. To make sender control information 1006 for packages sent to those printer servers 629, the user selects printer icon 1003, then clicks on the right mouse button. Menu 1005 appears, and by selecting "Properties" 1007 from that menu, the user of sender PC 613 gets access to the screens which are used in the preferred embodiment to define further sender control information. Beginning with the first of these screens, "Setup" screen 1101, this screen permits the user to specify paper size at 1103, paper type at 1105, and print quality at 1107. What the user specifies here may of course be overridden by control information in administrator policy 618. The second screen, "Print for" screen 1201 defines the recipients to whom the user of sender PC 613 may send messages. Menu 1202 has two columns: a list of recipient names 1205, which may represent either individuals or groups, and column 1203, which indicates for each recipient name 1205 the email address of a printer server 629 for the recipient. In some cases, documents for a given recipient 1205 may be printed at more than one printer server 629. By checking a box next to a name in column 1205 the user indicates that the person or group so indicated will appear in the list of recipients at 803 of screen 801. At 1207, the user indicates whether the recipient must authenticate himself to receive the printed document. Box 121 1 is checked if the user wishes to use an Internet courier service to deliver the document to the recipient. Document instructions 1213, finally, are instructions for a cover sheet that will be printed out with the document.

FIG. 13 shows the screen 1301 that is used when the document is sent via an Internet courier service. At 1303, the URL of the Internet courier service is specified; at 1305, the username by which the recipient is known to the Internet courier service; and at 1307, the password that the recipient must use to retrieve the document from the Internet courier service.

Fig. 14 shows the screen used to specify recipients of notifications when a package 615 is sent to a generalized printer server 629. Menu 1402 specifies recipients by name in column 1403 and notification address in column 1405, generally the recipient's email address. When the box next to a recipient's name in column 1403 is marked, the recipient will receive a notification when generalized printer server 629 has finished printing the documents in the package. At 1407, the sender indicates to generalized printer server 629 whether he or she is to be notified if generalized printer server 629 cannot satisfy a requirement of package sender control information 617, and at 1409, the sender indicates that the package should not be printed if any item of control information cannot be satisfied. Both these indications become part of package sender control information 617 for the package, as does comment 1411 for the notification messages. FIG. 15 shows the screen reached by clicking on advanced button 1413 in screen 1401. This screen permits the user of sender PC 613 to add further sender control information to package sender control information 617: at 1503, the user can indicate that he or she wants to be notified when the document is printed; at 1505 through 1509, the user can indicate a date before which the document should not be printed (1509) and what to do if printing of the document does not occur within a prescribed time period (1505 and 1507).

Screen 1601 is the screen used by a user of sender PC system 613 to modify recipient addresses for generalized printer server 629 contained in sender control information 609 in sender PC 613. Each row 1617 in menu 1602 represents a recipient address; a complete recipient address has three parts: a recipient name 1603 which the user selects to identify the recipient in sender PC system 613, the email address of the recipient's generalized printer server 629, and the email address at which the recipient will receive notifications. If an address is incomplete, generalized printer server 629 cannot perform the function associated with that part of the address. Thus, as shown at 1605, the recipient name NPSD Audit System has no generalized printer server address, so NPSD Audit System can be used as a name to which notifications are sent, but not as a name to which printer jobs are sent. Because that is the case, NFS Audit System appears in the list of recipient names in Notify screen 1401, but not in the list of recipient names in Print For screen 1201. Similarly, as seen at 1607, there is no notification address for the recipient NPSD Labstock, and consequently, that name appears in Print For screen 1201 , but not in Notify screen 1401. The user can use boxes 1611-1615 and button 1619 to add or modify recipient addresses; import 1621 permits the user to import a list of user addresses from a printer server 629.

FIG. 20 shows the notification 2001 received by the user of sender system 613 when he or she has sent a package 615 to a printer server 629. As shown by email message header 2003, Notification 2001 is an email message sent by printer server 629 to the email address of sender system 613. The information contained in the message is shown at 2005; the reason the notification was sent is indicated by one or more of the notification text strings shown at 2007. The sending user of course uses notification screen 1401 to specify to printer server 629 the control information for sending a notification to sender system 613. The control information is part of package sender control information 617.

Details of a package: FIGs. 24-27

A package 615 may have any format which will serve to transfer package sender control information 617 and one or more document representations 605 to printer server 629, though Postscript® is used in a preferred embodiment. The document representation may even be nothing more than a descriptor for a document that is located elsewhere, for example, a universal resource locator (URL) for a document that is available via the World Wide Web. In a preferred embodiment of system 601, a package 615 is an email message that contains email mime multipart messages. The body of the email message is empty. The first attachment contains package sender control information 617. The subsequent attachments contain the document content with a mime type appropriate to the content of each attachment. The Calypso server can handle multiple attachments in a single email and can print the attachments as a single document.

Control information 617 is specified using Extensible Markup Language (XML). For a description of XML, see Extensible Markup Language at http : //www . w3 . org/TR/PR- xml-971208. XML permits specification of control information 617 in a way that is both human readable and easily processed by a program. It is language independent and at the same time, tools exist in both Java and C/C++ to manipulate XML data. XML also provides for extensibility. Within package 615, the XML for control information 617 is contained in an attachment to the email message of type application/xml or text/xml(see RFC 2376 - XML Media types). Note that this method for representing control information can be used with files as well as in email messages. In these cases, the file will contain a multi-part mime message with parts containing the control information and the document content.

The document content is sent in subsequent attachments, all of which have the same type. In other embodiments, they may have different types. In the preferred embodiment, the type may be either PDF or compressed Postscript®. The mime type to be used for PDF is application/pdf and for compressed Postscript® is application/x-zip-compressed. Note that in the case of a compressed attachment the mime type does not reflect that of the inner content (i.e. postscript).

FIGs. 24-27 show details of an example package 615. Fig. 24 shows email header 2401. Header 2401 is constructed according to the norms defined in Internet RFCs related to mail - in particular RFC 822, RFC 2045 and RFC 2046. The following MIME message headers should always be filled in: From:, To:, Message-id:, Subject:, Date:, Content-Type:. The MIME message header Content-Type is multipart/mixed with a boundary delimiter line. An example is listed below

Content-Type: multipart/mixed; boundary="gcOpJqOM: 08jU534c0p"

Each body part should have a Content-Type header and a Content-Transfer-Encoding header. Examples are :

For XML body parts

Content-type: text/xml; charset="utf-8" Content-transfer-encoding: base64

For compressed body parts

Content-type : application/x-zip-compressed; name=test .ps . zip Content-transfer-encoding: base64

The package's package sender control information 617 is shown in detail in FIGs. 25 and 26. The XML that actually defines the control information is shown at 2501. In XML, there is an outer language construct and all other language constructs are nested—either directly within the outer language construct or in other language constructs. Here, the outer construct is a job, identified by the name c j ob . The beginning of each language construct is indicated by the language construct's name, for example <c Job> (2505), while its end is marked by the name preceded by a backslash, for example < \ c Job> (2505 in FIG. 26). The components of the control information in the example of FIGs. 24-27 are summary control information 2507, a document specifier 2509, scheduler information 2515, media information 2521 , and continuing in FIG. 6, notify information 2601, recipient information 2611, and rules information 2619. Each of these will be discussed in turn.

Summary

This group contains the elements that describe the general processing options for the job. Printer server 629 requires the following elements: sName (job identifier) , cSubmitter( seτ creating the job), kPDL (PDL for the job)., UobByteSize (size of job in bytes) and iPagelmageCount (number of pages in the job). Additionally, summary 527 in the example control information 617 includes iCopies (the number of copies— here 2) and bColorRequired (whether color is required— 0 indicates that it is not).

Documents 2509

The documents included in the print stream are specified here. The document may be included as an attachment in the package or it may be specified by an URL or by a name that refers to a data stream accessible by printer server 629.

• The document's name is specified in the element nName . The name in nName should be the same as the name used in Content-Type 2702 (FIG. 27) of the attachment for the document. Example nName = "calypso_package_format . doc" and Content - type : application/x- zip-compressed ; calypso_package_format . ps . zip.

• The element kType indicates the location of the document; attach in that element indicates that the document is attached to the email message.

Scheduler 2515

This group contains the options related to the scheduling of the job. The elements of interest are : iDiscard, iHoldUntil, iRetainUntil. iDiscard 2517 indicates a time period after which the package may be discarded if it has not yet been printed. The element bAuthRequired 2519 indicates whether the sender would like the receivers to identify themselves before the job is printed. However the mechanism by which such identification is performed is defined by administrative control information on server 629.

Media 2521

The elements of interest here are kCategory 2523 and kSize 2525. kCategory identifies the kind of medium being printed on: ordinary stationery (as here), letterhead, transparency, and so forth. kSize specifies the size of the medium, here A4.

Notify 2601 aNotify element 2601 is shown in FIG. 6. It specifies the notifications that the sender of the package wishes sent. aNotify 2601 is made up of a cNotify element 2603 for each notification that is to be sent. Each cNotify element 2603 contains an element 2605 which specifies the notification message, an element 2607 that specifies how the notification is to be sent (here, by email), and an element 2609 that specifies the email address to which the notification is to be sent. In a preferred embodiment, a cNotify element specifying the package sender is included in aNotify by default.

Recipients 2611 aRecipient element 2611 specifies the recipients of the package. Each recipient is specified by a cRecipient element 2613. That element contains an element 2615 that specifies the name of the recipient and an element 2617 that specifies the recipient's email address.

Rules 2621 aRules element 2619 specifies rules established by the sender. Here, there is one rule element 2621. bNotify 2621 specifies whether the sender is to be notified if the job described in the package cannot be printed as specified by the sender. Here, the value "1" indicates that the sender is to be notified.

Other elements that may be contained in control information 617 but are not in the example of FIGs. 25-26 are a banner element that defines a banner text to be printed on the document's cover page and a printers element that permits the sender to directly specify the printer(s) that the document is to be printed on.

FIG. 27, finally, shows document 605, which in this case, is compressed as a Zip archive and attached to the package. The compressed Zip archive is shown in part at 2701.

User interface for a recipient: FIGs. 17-19, 21

Like the user of sender system 613, the recipient uses screens which appear on his or her own PC to set recipient policy. The result of the policy settings in a preferred embodiment is an email message to policy manager 721, which reads the email message and uses its content to modify control information for the recipient in recipient policy 619. There are two kinds of control information for a given recipient: global control information, which apply to all packages 615 received by the recipient, and per-package control information, which specify what the recipient wants done with the contents of a particular package 615. The recipient sets the per-package control information when he or she responds to a notification that a package has been delivered. In a preferred embodiment, the global control information for the recipient use at least the following information:

• the default type of authentication which the recipient will employ.

• the PIN (personal identification number) used by the recipient. • whether the notification should include an electronic copy if permitted by the sender;

• the interval after which another notification should be sent;

• identification of a handler for the recipient's documents;

• identification of parties who are to receive notifications sent by printer server 629 to the recipient. per-package control information applies to at least the following:

• whether the recipient wishes to print the contents of a package at all;

Some aspects of recipient policy may be overridden by administrator policy; for example, the administrator policy may require recipients to go personally to the printer and authenticate themselves there.

FIG. 21 shows how the recipient uses the notification he or she receives when a package 615 arrives in printer server 629 to establish per-package recipient control information for the package. Notification email 2101 contains a header 2103 which identifies the recipient and the sender, and if the sender so indicated in the per-package sender control information and the administrator control information for printer server permit it, an attachment 2105 containing an electronic version of the package contents. 2107 contains information about the package. Of special interest are the document instructions, which also come from the per-package sender control information, personal PIN 2111, which is a copy of the recipient's personal PIN if one is needed for authentication by the recipient (the value is not displayed in the email message), and authentication method 2113. In a preferred embodiment, there are three authentication methods: none at all, that is, no authentication is required, authentication at the front panel of the printer, and authentication by means of an authentication message. The authentication method appears as a button in the email message.

When the recipient clicks on the button in a situation where authentication by means of the recipient's personal PIN is required, the recipient's system outputs the URL of an authentication Web page provided by printer server 629. FIG. 17 shows authentication Web page 1701. It includes radio button 1703 indicating whether the recipient is authenticating all of the packages which printer server 629 has not yet printed for the recipient and radio button 1703 indicating whether the recipient wishes to authenticate individual packages. In other embodiments, authentication of documents within a package may be permitted. To identify him- or herself to printer server 629, the recipient enters his or her PIN at box 1707; if the PIN matches PIN 2111 received in the notification message, print button 1709 becomes active, and by clicking on print button 1709, the recipient sends a response to Web page 1701 to printer server 629 which indicates to it that the documents in the pending packages are to be printed. If the recipient has specified a handler for his or her documents, printer server 629 will send a notification message to the handler prior to printing the documents. If authentication at the printer is required, printer server 629 will wait for further authentication from the handler before printing. If no authentication is required or if authentication is to be done at the printer , clicking on the button in the email message will produce a Web page like that of 1701 which contains only radio buttons 1703 and 1705 and print button 1709.

FIG. 18 shows package selection Web page 1801, which appears when the recipient selects radio button 1705 in Web page 1701. List 1803 shows the packages that the recipient has received but have not yet been printed. Subject 1807 comes of course from the contents of box 811 in print screen 801. The recipient may select individual packages from list 1803 by the usual methods, and having done so, the recipient clicks on the print button. The response sent to printer server 629 indicates which of the packages are to be printed, and printer server 629 begins to print the documents belonging to the selected packages at the printer associated with the recipient.

FIG. 19 shows a detail of front panel 625 in a preferred embodiment of a printer 623 to be used with printer server 629. Where authentication at the printer is required for either a recipient or a handler, the authentication is done using front panel 625. Front panel 625 has four main elements: a LCD display 1903, a set of navigation and selection buttons 1905, and an alphanumeric keypad 1913 for entering a PIN. LCD display 1903 displays a list of recipients with packages which are to be printed at the printer to which front panel 625 belongs. Using navigation buttons 1909, the handler or recipient at the printer can navigate up or down the list; selection button 1911 permits the handler or recipient to select an item on the list and cancellation button 1907 permits the handler or recipient to cancel a selection. Once the selection is made, the handler or recipient inputs his or her PIN at 1913. If the PIN is that specified for handlers for recipients of the selected packages, the printer prints the documents in the package. If the document fails to print, LCD display 1903 will display a notification of that fact.

User interface for an administrator

As noted above, an administrator has control over who uses a printer server 629 and how the printer server is to be used. In making administrative control information for printer server 629, the administrator in a preferred environment does the following:

Global Policy

• Set anti-SPAM filters based on regular expressions.

• Determine availability of server 629 (times of day, days of week)

Recipient Policy Allow/disallow auto-generation of Recipients when a Package is received for a Recipient that doesn't currently exist:

• Assign default Recipient Policies.

• Generate random PIN (sent via email to Recipient on first Notification).

• Assign Recipient Policy for the null Recipient. This Policy is used when the sender does not specify a specific Recipient (i.e. for unattended/unauthenticated printing).

• Assign authentication policy. The nature of the authentication is up to the Administrator and the Recipient. It may be as simple as no authentication, up to Smart Card and PIN entry server 629. Each organization must determine the necessary level of authentication required to meet its security requirements. Authentication may be limited to: - Front panel PIN

- Email/Web PIN

- Email/Web

- None

• Manually create Recipients: For each new Recipient, start with Default Recipient Policies. Then:

- Set Recipient specific Administrative Policies.

- Optionally assign PIN (sent via email to Recipient on first Notification).

- Allow/disallow Recipient changes to his or her Recipient Policy. - Set Handler Configuration Identify a default Handler for all Recipients. Identify a specific Handler for each set of Recipients. Set Notification Recipient Policy. Identify a set of default Notification Recipients for all Recipients.

Identify a specific set of Notification Recipients for each set of Recipients.

Using a printer server to protect intellectual property rights: FIG. 22

The digital age has posed a pressing problem to purveyors of information such as publishers and libraries: how to take advantage of digital communications to increase the market for their information without losing control over it. The simplest public way to transfer information in the digital age is to put it on a Web site, from which interested parties can download a digital representation of the information to their own systems. The simplest private way is to attach a digital representation of the information to an email message. In both cases, the sender of the information loses control over it. Once the recipient has the digital representation, the recipient can print as many copies of the electronic representation as he or she pleases and worse, can him or herself make the digital representation available to others on a Web site or email copies of the digital representation to friends and acquaintances. Making or distributing copies of a digital representation without permission is of course a violation of the copyright laws, but copying is too easy and legal pursuit too expensive for the copyright law to operate as much of a deterrent.

One way a purveyor of information can keep the convenience of access provided by digital communications without losing control of the information is by permitting the user to order the desired information digitally, but providing the user with a paper copy of the information instead of an electronic copy. The user can of course still make copies, but to make paper copies, the user must employ a xerographic copier and to produce an electronic copy, the user must employ a scanner and an OCR program. The latter is laborious, requires special equipment, and with all but the simplest and cleanest documents, produces imperfect copies.

Fig. 22 shows how a printer server 629 may be modified so that it can be employed to provide paper copies of electronically-ordered documents to users. In system 2201, there are three main components, all connected by internet 531 : Orderer PC 2203, printer server 2207, which is a modified printer server 629, and document server 2219, from which electronic copies 2223 of the documents may be obtained.

PC 503 has a program which makes a document order package email message 2205 based on input from a document selection screen 2205. Document selection screen 2205 may be a Web page received from printer server 2207 that contains a list of documents that may be ordered for printing in printer server 2207. When the user of orderer PC 2203 selects one or more documents from document selection screen 2205, the program produces a document order package 2206 which contains order control information 2207 and a list of document identifiers 2209 identifying the documents being ordered. Order control information 2207 is analogous to sender control information. They specify information such as the orderer' s identification, perhaps a credit card number to which the price of the documents can be charged, and the location to which the orderer wishes the printed copy to be delivered.

Document order package 2206 goes to printer server 2207 in exactly the same fashion as package 615. It is received at 2208, which is an unpackager like unpackager 725. Printer server 2207 is generally like printer server 629, except that policy manager 721 now includes orderer policy 2211 and intellectual property policy 2217 and the policy in recipient policy 2213 and administrative policy 2215 have been modified as required for the new function. It should be pointed out here that printer server 2207 may also serve as a printer server 629. For example, a printer server located in an industrial research laboratory might be used both in the fashion described with regard to printer server 629 and also to obtain and print journal articles for employees of the research laboratory.

Package inteφreter 2209 inteφrets order package 2206 under control of policy manager 721. If IP policy manager 2217 determines that the orderer specified in order control information 2207 may in fact order the documents identified in order package 2209, it uses requester component 2210 to make and send a notification email message 2235 to document server 2219. Notification email message 2235 contains recipient control information 2233 for the documents and the identifiers for the documents. Document server 2219 has three programs: notification inteφreter 2220, which inteφrets document order notification 2231 and if the order is accepted, passes recipient control information 2233 and document IDs 2235 on to package maker 2222 and accounting program 2224. Accounting program 2224 does any necessary accounting, for example, charging either the orderer or the owner of printer server 2207 for the copy. Package maker 2222 fetches copies of the documents identified by document IDs 2235 from document storage 2221, encrypts them so that they can be decrypted only by printer server 2207, and makes document package 2225, which contains recipient control information 2227 made using recipient control information 2233 and perhaps other information provided by document server 2219, and the encrypted document representations 2229. Document package 2225 then goes by email to package inteφreter 2209, which deals with package 2225 substantially as described for package 625. If the policies in policy manager 721 permit, package inteφreter 2209 decrypts the documents and prints them out on a printer at a location specified in order control information 2207. The orderer is at this point effectively a recipient, and can pick up the documents as described above for recipients.

A key aspect of system 2201 is that the user of orderer PC 2203 cannot obtain an electronic copy of the document at PC 2203, but instead can only use PC 2203 to order a paper copy printed by printer server 2203. In system 2207, that is achieved by only making document identifiers available to orderer PC 2203; in other embodiments, it might be achieved by making only an encrypted version of the document available to orderer PC 2203. In such an embodiment, orderer PC would be unable to decrypt the encrypted version to obtain a digital copy in orderer PC, but would instead have to send it in a document order package to printer server 2207, which could decrypt and print it in the manner described for document package 2225. If orderer PC 2203 were equipped with a program (perhaps a Web browser plug-in) that could read and display the encrypted version on PC 2203, but would not copy a decrypted version to persistent storage, the user of orderer PC 2203 could preview the document before ordering the paper copy.

Details of a preferred embodiment of printer server 629: FIGs. 1-4 FIG. 1 shows a block diagram depicting the concept of the present invention and its environment. Referring now to FIG. 1, a computer system 102 has access to the public internet or private intranet 105 via a communications link 122 and possibly other facilities such as a firewall server and email server (not depicted separate from 122). One method that the computer system 102 generates a request to utilize a remote device is by posting an electronic mail message addressed to a name which represents the device server 109 and which may contain instructions in the message and one or more MIME attached files which contain the data to be printed. This message arrives at electronic mail system 107 accessible to the generalized device server via link 124 to the Internet or intranet. The mail system 107 has storage means to hold the request message and attached file(s). The electronic mail system 107 is typically in a different administrative domain than the computer system 102 and is typically attached to a different LAN 126. A firewall server 106 is typically installed between link 124 and the electronic mail server 107, although this is optional and, if present, may be combined on one computer with 107.

Alternately, the computer system 102 uses the Universal Resource Locator (URL) address of the device server 109 to establish a connection to the server utilizing the http capabilities of link 124 and firewall 106, with or without SSL. Via this connection computer system 102 generates an http-based request.

Connected to the second LAN 126 is generalized device server 109 which optionally may have local devices 112 (such as printers) attached via serial and/or parallel ports 128. Network devices 111 (such as network printers) may also or instead be attached to the second LAN 126. For some or all of the devices 112 and 111 there are typically software printer queuing mechanisms 110 installed, although this is optional and not required for all devices 112 and 111. Each queuing mechanism 110 supports one of the printers 112 and/or 111 by receiving jobs for said device, queuing them on storage means and sending them to said device in a prescribed order.

As noted previously, the server 109 has an electronic mail address and periodically polls the electronic mail system 107 for messages destined for its address. When such a message is delivered to the server 109 from the electronic mail system 107 in response to a poll, the server automatically performs the actions (described later) necessary to carry out the request contained in the message, resulting in output on one of the devices 112 or 11 1 , via the queuing mechanism 110 if appropriate. The server may take several actions such as rendering the data on several devices, or archiving the data in the course of carrying out the instructions associated with a single request. The server operates in accord with configuration information and control parameters provided via an administrator computer 108. Web browser software which implements http message protocol and implements HTML document format executes on computer 108 to provide the client-side administrator functions. The server 109 supports trusted device handling of controlled intellectual property by interacting with an agent 104 such as an EnTrust system to either obtain authorization or to report the usage made of the property on the devices as a result of requests made to the server. Interaction with block 104 is via the LAN 126, firewall 106, if present, link 124 and Internet or intranet 105 and a link 123 to block 104.

FIG. 2 shows a block diagram wherein the server of the present invention is more fully revealed. Referring now to FIG. 2, the server 209 is connected to the LAN 226 as previously discussed in FIG. 1 through which it can interact using various protocols with other LAN- based servers and functions, specifically the electronic mail system as discussed in FIG. 1. The server 209 utilizes multiple independent loci of execution ("threads") to perform its functions. One thread listens and waits for http-based input from the LAN in block 232. Such input is the means by which an administrator can control and monitor the operation of the print server and is one of the means for making requests to utilize devices. Block 235 analyzes http messages. If a message is an administration message, the authorization block 236 interacts via HTML- format messages sent and received via http protocol to request and receive identity information and to determine whether or not input messages should be acted upon. Administrative messages act on (by adding, deleting or modifying) or request the return of information in the databases 250 maintained by administration module 237.

The generalized device server databases 250 are:

• A database of administrators where each record contains the name and password of a user allowed to act as an administrator of the server, and the kinds and types of notifications that the administrator wishes to receive about the server's operation.

• A database of user profiles where each record contains a user name, the name of preferred devices and options. A user does not need to have a record in the user profile database to utilize the remote printing system, nor does a person or entity that should ultimately receive a document after it is printed need to have a record in the user profile database. However, if the output of a request, such as a print request, is intended for a particular user, and the user has a profile, the profile information is used in selecting a device, conversions, etc.

• A database of devices where each record contains the name of a device, how to access it (via a queuing mechanism or via a driver interface), the status of the device (available, not available), features of the device (such as model, number of paper bins, type of printing stock in each bin, choices for speed or print quality), and maintenance intervals (such as number of sheets of paper held by each bin and expected life of the printer's ink cartridge(s)). • A database of control parameters where each record names a user or device or the device server itself and gives a limit that relates to that entity. Limits on users include (a) the maximum number of requests (such as print jobs) per day or total number of requests, (b) the maximum size of a request (in bytes or pages), and (c) the names of devices that can or cannot be used. Limits on devices include (a) the maximum size of a request (in bytes or pages, and (b) the times of the day or week when the device may be utilized. Limits on the server itself include (a) the maximum size in bytes of a mail message to be received, and

(b) the times of the day or week when the server will poll for messages or accept http requests (other than administrative requests).

• A database of statistics where each record names a user or device or the device server itself and gives accumulated usage information about that entity. Accumulated statistics include

(a) for each user from whom a remote request has been received, the total number of requests, the total number of requests for the current day, and the total size of all requests for the current day in bytes and pages, (b) for each device which has been utilized by the device server, the total number of all requests, the total size of these requests (in bytes and pages), and these same totals for the current day. A printer statistics record also contains the accumulated use of the resources of the printer (sheets of paper, ink) since the last maintenance interval when an administrator would have reset these values.

Continuing now with FIG. 2, in block 231 a second thread of the print server polls the electronic mail system for new messages. When a message is present, it is transferred to the server and deleted from the electronic mail system. Another thread within the print server is started in order to process the received message. This thread may utilize the cryptography component 233 if the message is not entirely in clear text. The email analysis component 234 parses the mail message and examines the attached files to determine the format of the attached files and what instructions have been provided. The instructions provided may be incomplete. Utilizing the server's databases 250 of profile data and device data to augment the instructions contained in the message, the augmentation component 238 generates a complete request which designates a specific device. The limits block 243 checks that the request is within the limits given in the limits database. If the data to be acted on by the requested is tagged as controlled intellectual property, the IP authentication block 244 obtains permission on behalf of the requester or the intended recipient of the device output. This may require separate message exchanges with an outside agent. Typically the processing of the request will require the formatting of each attached file into a device-ready format, which is done via the appropriate conversion components 240. Conversion components are separate computer programs that are started as needed by the server and terminate each time a conversion task is completed. A commonly utilized conversion component is one which converts files from the PDF format to postscript™ print-ready format. When a single device-ready file has been prepared, it is sent to the designated device either via that device's queuing mechanism 210 or directly by utilizing the device interface 227 of the operating system of the host computer system on which the server is executing. Subsequently, output is produced either at a designated local device 212 or network attached device 21 1. During these processing steps the thread accumulates statistics in block 239 and monitors all processing steps for errors or warnings in block 240. In addition, auditing to on-line disc storage occurs in block 241. A single request may involve more than one action, and hence may involve repeated use of many of the blocks discussed in FIG 2.

Finally, the thread generates notifications in block 245. Notifications are via email to the requester and possibly to one or more administrators, based on the contents of the administrator's database 250. A notification message shows the disposition of the request (success or failure), the device used, errors, warnings and statistics. If the request involved the use of controlled intellectual property, Block 242 carries out the reporting of the usage made to the agent or owner of the intellectual property.

FIG. 3 and FIG. 4 together show a flowchart wherein the logic of the server of the present invention is more fully revealed. Referring now to FIG 3, the server begins execution within a single protected address space (known within the art as a "task"). In block 329 it creates two independent loci of execution (known within the art as "threads"). One thread processes administrative requests and updates. In block 332 this thread listens for http input. Until input arrives, the execution of this thread is suspended. When input arrives, block 333 determines if it is a device usage request or if it is an administrative request. In the case of the former, a processing thread is created to handle the request in block 353. If an administrative request does not contain a key value (as described below), block 361 generates a response in the form of an HTML-based form window soliciting a user name and password which is displayed by browser software on the display of the administrator's computer 108. Subsequent input from the administrator's browser software contains the user identity and password as provided by the administrator. This is compared with the server's database of administrators in block 361. If there is no match, an appropriate error message is generated in block 364, sent to the browser on computer 108, and logged in the server's disk-based log file in block 366. If there is a match, then the authorization block 361 sends the administrator's browser software a key value which is retained by the browser and returned on each subsequent input message, all in accord with the http protocol. Input that contains a key value passes to block 362. Input can contain instructions to update a record or records in one of the servers databases 250(by adding, deleting or modifying), to produce a human-readable display of database entries, or both. Block 362 examines the input for update instructions. If found, execution passes to block 363 which performs the required updates. Block 364 generates the required HTML-based response which is sent back to the browser software executing on computer 108 and displayed to the administrator. Block 366 logs all administrative activity.

Continuing with FIG. 3, the other thread, created when the server begins execution, polls the electronic mail system in 331 in accord with the server limits database 250. If the electronic mail system replies that there are no messages waiting to be delivered, then block 351 causes the thread to suspend execution for a brief time in block 352, and then poll again. If one or several messages are waiting, and are within the server's size limit, and are successfully retrieved in block 351, then block 353 creates a separate additional message processing thread for each message, after which the creating thread again polls the mail system. This creating thread does not wait for the completion of each message processing thread it has created.

Referring now to FIG. 4, the execution of a message processing thread is illustrated. Each email message contains header text, optional message body text, and one or more attached files with data to be printed. The body text and or the attached file(s) may be encrypted using either PGP or S/MIME or another encryption technique particular to an organization employing the present invention. Block 401 determines if decryption is needed. If so, block 433 is invoked to produce a clear text version of the message and its attachments. Block 434 then analyzes the message to discover what instructions have been provided, and the format of the attached file(s). Instructions in the body of the message may be explicit, such as a designation of a specific device; may be indirect, such as a designation to select the default device for a particular user; may include a designation of important attributes, such as a request to use a color printer with size A4 paper; or may be omitted. The example of device selection instruction is illustrative but not exhaustive. In block 444 the printing instructions are combined with default values and profile values, as needed, taken from the server's databases 250, and the indirect instructions are resolved to produce a specific set of instructions, including selecting a specific device. In block 445 the server determines if it can execute the specific set of instructions. Reasons for rejecting a request include: • A size or usage limit for the device or for the user would be exceeded

• There is no device which matches the designated requirements that is available

• The format of an attached file cannot be determined or is not supported.

If the data to be acted on is tagged as controlled intellectual property, this is detected in block 437, and block 438 is invoked to obtain the necessary authorization via message interactions with a server elsewhere on the LAN, Internet or intranet. Authorization may not be needed provided that usage of the intellectual property is reported. (This is done later in block 436.)

If there is only one attached file and it is in a format supported by the selected device (such as a postscript format file destined for a postscript capable printer, then block 440 takes no action. If an attached file is in PDF format, then block 440 produces a converted file by starting a separate program which produces the converted file. The PDF example is illustrative but not exhaustive. If there are several attached files, a converted version of each may need to be produced. If there are several attached files, the final action of block 440 is to combine them all into a single device-ready file, such as a postscript format file for a printer. In block 447, the appropriate method for sending the device-ready file to the selected device is determined based on the device server's database record for the selected device. Block 427 is utilized if there is a spooler for the device. Block 410, the operating system driver interface, is utilized if there is no spooler.

The instructions may include instructions to perform several actions such as printing and archiving. If so, block 448 repeats the processing steps until all actions are complete. Whatever the outcome of request processed by the message processing thread, notification messages are generated by block 435 describing the success or failure of the request, any warnings, which device was used, and the extent to which the limitations imposed on the requester by the server's control parameters database have been reached as a result of the completed request. If the request used controlled intellectual property, notification of the usage made is generated. Block 436 sends the notification messages using the return address contained in the request email header, and also sends a similar message to each administrator whose entry in the administrator database indicates a desire to be notified about server activity. Finally, block 441 logs the information about the request to the end of a disk-based log file to create a permanent audit of server activity. Then the thread terminates.

Conclusion

The foregoing Detailed Description has disclosed to those skilled in the arts to which the invention pertains how to make and use a generalized resource server and a generalized resource control client and has disclosed the best mode known to the inventors of implementing the generalized resource server and the generalized resource control client. The Detailed Description has further given detailed examples of two species of generalized resource server, namely a generalized printer server and a generalized printer server adapted to protect intellectual property rights. The principles disclosed herein are however not limited to those species, but may be used for many other species of the invention. It will also be immediately apparent to those skilled in the relevant arts that the choice of control information, of rules and preferences, and of notifications will depend on the resources being controlled and the particular circumstances in which they are being controlled, and that many particular implementations of the inventions are possible. For all of the foregoing reasons, the Detailed Description is to be regarded as being in all respects exemplary and not restrictive, and the breadth of the invention disclosed here in is to be determined not from the Detailed Description, but rather from the claims as inteφreted with the full breadth permitted by the patent laws.

Claims

What is claimed is:

1. A resource server (629) that controls a resource (623), the resource server comprising: a message receiver (725) that receives a sender message (616) via a messaging interface from a sender, the sender message including a sender job specification (615) that must be augmented to control the resource; and a resource job specification maker (721) that responds to the received sender job by making a resource job specification (622) that is augmented as required to control the resource and thereupon using the resource job specification to control the resource.

2. The resource server set forth in claim 1 wherein: the resource is a printer; the sender job specification includes a representation (605) of a document; and the resource job specification controls the printer to print the document.

3. The resource server set forth in claim 2 wherein: there is a plurality of the printers; the sender job specification includes a specification (2613) of a recipient for the printed document; the resource server includes control information (618) that relates the recipient specification to a given one of the printers; and the resource job specification maker further responds to the control information by making the resource job specification for the given one of the printers and thereupon controlling the given one of the printers therewith.

4. The resource server set forth in claim 1 wherein: the sender job specification includes at least one specification (2621) of a condition on the manner in which the resource job specification maker responds to the sender job specification; and the resource job specification maker takes the specified condition into account in responding to the sender job specification.

5. The resource server set forth in claim 4 wherein: the specification of the condition specifies a condition which must be satisfied by when the resource job specification maker responds to the sender job specification.

6. The resource server set forth in claim 4 wherein: the specification of the condition specifies a condition for which it is preferable that the condition be satisfied when the resource job specification maker responds to the sender job specification.

7. The resource server set forth in claim 4 wherein: the resource is a printer; the sender job specification includes a representation (605) of a document; and the resource job specification controls the printer to print the document.

8. The resource server set forth in claim 7 wherein: the specification of the condition specifies a manner in which the printer is to print the document.

9. The resource server set forth in claim 1 wherein: the sender job specification includes at least one specification (2603) of an additional action (711) to be taken when the resource server responds to the sender job specification; and the resource job specification maker performs the specified additional action in responding to the sender job specification.

10. The resource server set forth in claim 9 wherein: the specified additional action is a notification of an entity that is interested in the resource job specification maker's response to the sender job specification.

11. The resource server set forth in claim 1 further comprising: a policy manager (721) that specifies at least one condition on the manner in which the resource job specification maker responds to the sender job specification; and the resource job specification maker take the specified condition into account in responding to the sender job specification.

12. The resource server set forth in claim 11 wherein: the policy manager specifies the condition in response to an input (618) from an administrator of the resource server.

13. The resource server set forth in claim 12 wherein: the resource produces an output (522) for a recipient; and the policy manager specifies the condition in response to an input (619) from the recipient.

14. The resource server set forth in claim 1 further comprising: a policy manager (721) that specifies at least one additional action (71 1) to be taken when the resource job specification maker responds to the sender job specification; and the resource job specification maker performs the specified additional action in responding to the sender job specification.

15. The resource server set forth in claim 14 wherein: the policy manager specifies the additional action in response to an input (618) from an administrator of the resource server.

16. The resource server set forth in claim 14 wherein: the resource produces an output (522) for a recipient; and the policy manager specifies the additional action in response to an input (619) from the recipient.

17. The resource server set forth in claim 15 wherein:

the specified additional action is a notification of an entity (715,717,719) that is interested in the resource job specification maker's response to the sender job specification.

10982369-1

1 18. The resource server set forth in claim 16 wherein: the specified additional action is a notification of an entity (715,717,719) that is interested in the resource job specification maker's response to the sender job specification, l

1 19. A generalized resource control client that executes on a computer system (613),

2 the generalized resource control client comprising:

3 a request receiver (609) that receives a request (607) to use a resource (623) from

4 a program executing on the computer system;

5 a sender message maker (611) that makes a sender message (617) from the

6 request, the sender message not being specific to a particular type of the resource, but

7 being augmentable in a resource server (629) that has access to the resource to produce a

8 message (622) that is specific thereto; and

9 a sender message provider (612) for providing the sender message to the resource 0 server. l

20. Apparatus for making non-digital copies of digital representations, the apparatus comprising: a copy request receiver (2208) that receives a digital message from a requesting source (2203) external to the trusted apparatus that specifies a digital representation of which the requesting source may not make a digital copy and requests a non-digital copy thereof; a digital representation requester (2210) that responds to the digital message by obtaining a copy (2229) of the digital representation; and a non-digital copy producer (623) that responds to the copy of the digital representation by producing the non-digital copy (522) for provision to the requesting source, whereby the non-digital copy is produced without giving the requesting source access to the digital representation.