DE10212637A1

DE10212637A1 - Druckerprioritäts-Gebotsschema

Info

Publication number: DE10212637A1
Application number: DE10212637A
Authority: DE
Inventors: Richard Alexander
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 2001-03-21
Filing date: 2002-03-21
Publication date: 2002-10-02
Anticipated expiration: 2022-03-22
Also published as: US6987578B2; US20020135796A1; DE10212637B4

Abstract

Eine Druckpriorität wird gemäß einem Gebotsprozeß gesichert, der es Benutzern ermöglicht, Gebote zusammen mit ihren Druckaufträgen vorzulegen. Der Drucker ordnet die Druckaufträge von dem höchsten zum niedrigsten Gebot. Dies ermöglicht es individuellen Benutzern, die Wichtigkeit jedes Druckauftrages zu bestimmen. Ist derselbe wichtig, kann der Benutzer ein höheres Gebot vorlegen, um den Druckauftrag oben in der Warteschlange zu plazieren, vor Druckaufträgen, die durch die Benutzer, die dieselben vorgelegt haben, als weniger wichtig erachtet wurden. Ein Priorisieren der Druckaufträge gemäß vom Benutzer vorgelegten Geboten ermöglicht es dem Drucker, die Dringlichkeiten und Druckbedürfnisse aller Benutzer besser zu reflektieren.

Description

Die vorliegende Erfindung befaßt sich mit Druckern und spe zieller mit Verfahren zum Priorisieren von Druckaufträgen basierend auf Geboten.

In der Netzwerkumgebung ist es üblich, daß mehrere Benutzer einen oder mehrere Drucker auf einem Netzwerk gemeinschaft lich verwenden. Üblicherweise legen Benutzercomputer Druck aufträge über das Netzwerk an einen Drucker vor, und dieser Drucker plaziert den Druckauftrag in einer Warteschlange. Die Druckaufträge werden nachfolgend in der Reihenfolge ge druckt, in der sie in der Warteschlange erscheinen. Auf diese Weise weist der Drucker den Druckaufträgen auf einer Zuerst-Hinein-Zuerst-Heraus (FIFO = first-in-first-out)- Basis eine eigene Priorität zu.

Wenn viele Benutzer die gleichen Druckressourcen gemein schaftlich verwenden, gibt es Zeiten, zu denen unterschied liche Benutzer unterschiedliche Prioritätsbedürfnisse ha ben. Ein Benutzer könnte zum Beispiel einen Eilauftrag ha ben, der ein sofortiges Drucken erfordert, während andere Benutzer keine zeitlichen Einschränkungen haben. Mit der traditionellen FIFO-basierten Priorität wird der Bildruck auftrag nachteilhafterweise für den ersten Benutzer einge reiht und in der Reihenfolge gedruckt, obwohl andere Druck aufträge, die in der Warteschlange weiter vorne sind, nicht die gleichen Zeiteinschränkungen aufweisen, und einfach zu rückverschoben werden könnten, bis der Eilauftrag fertigge stellt ist. Die Tatsache, daß der erste Benutzer großen Wert darauf legt, daß sein Druckauftrag so schnell wie mög lich gedruckt wird, wird von dem Drucker nicht bemerkt, was zu einem ungeduldigen und häufig frustrierten Benutzer führt.

Dementsprechend besteht ein Bedarf nach einem verbesserten Druckschema in der Netzwerkdruckumgebung, das Druckaufträge gemäß der Wichtigkeit priorisiert, die durch individuelle Benutzer zugeschrieben wird.

Es ist die Aufgabe der vorliegenden Erfindung, Verfahren, und Vorrichtungen zu schaffen, die eine flexiblere Nutzung eines Druckers ermöglichen.

Diese Aufgabe wird durch Verfahren gemäß Anspruch 1, 5 oder 14, ein Netzwerkdrucksystem gemäß Anspruch 19, einen Dru cker gemäß Anspruch 26, eine Architektur gemäß Anspruch 30, ein computerlesbares Medium gemäß Anspruch 36 und eine Gra phikdruckmenü-Benutzerschnittstelle gemäß Anspruch 40 ge löst.

Eine Druckpriorität wird gemäß einem Gebotsprozeß gesi chert, der es Benutzern ermöglicht, Gebote zusammen mit ih ren Druckaufträgen vorzulegen. Der Drucker ordnet die Druckaufträge von dem höchsten zum niedrigsten Gebot. Dies ermöglicht es individuellen Benutzern, die Wichtigkeit je des Druckauftrags zu bewerten. Ist derselbe dringend, kann der Benutzer ein höheres Gebot vorlegen, um den Druckauf trag oben an der Warteschlange zu plazieren, vor den Druck aufträgen, die durch die Benutzer, die dieselben vorgelegt haben, als weniger wichtig erachtet wurden. Durch ein Neu ordnen der Druckerwarteschlange gemäß der Gebote verbessert der Drucker das Netzwerkdrucken durch eine bessere Abde ckung der sich ständig ändernden Druckbedürfnisse aller Be nutzer.

Bei einer Implementierung umfaßt das Netzwerkdrucksystem mehrere Benutzercomputer, die über ein Netzwerk mit einem oder mehreren Druckern verbunden sind. Individuelle Benut zerCOmputer sind mit einem Druckermodul ausgestattet, das vorangehend zugewiesene Druck-Token speichert, die beim An bieten einer Druckpriorität verwendet werden müssen. Das Druckermodul weist ferner eine Benutzerschnittstelle auf, die es einem Benutzer ermöglicht, ein anfängliches Gebot von Token sowie ein maximales Gebot zu spezifizieren, das der Benutzer bereit ist zu verbrauchen, um die beste Prio rität zu erlangen. Wenn der Druckauftrag gestartet wird, legt der Benutzercomputer den Druckauftrag zusammen mit dem Anfangs- und Maximal-Gebot vor.

Ein priorisierendes Modul befindet sich an dem Computer, um die momentan aufgereihten Druckaufträge zu priorisieren. Die Druckaufträge werden zuerst gemäß der Anzahl von Druck- Token priorisiert, die für die Druckaufträge geboten wur den. Wenn einer oder mehrere Druckaufträge identische Gebo te aufweisen, versucht das Priorisierungsmodul, die Gebote jedes Druckauftrags zu steigern (bis sie ihr Maximal-Gebot erreichen), bei einem Versuch, ein Gewinner-Gebot zu fin den. Wenn mehrere Druckaufträge immer noch gleichauf lie gen, werden die Druckaufträge zweitrangig gemäß einem zwei ten Kriterium priorisiert, wie z. B. der Empfangszeit, dem Benutzerdienstalter, der Benutzernähe zu dem Drucker, usw.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:

Fig. 1 ein Netzwerkdrucksystem, das ein gebotsbasiertes Prioritätssystem für das Priorisieren von Druck aufträgen implementiert.

Fig. 2 ein graphisches Benutzerschnittstellenfenster, das es Benutzern ermöglicht, Token für ihre Druckaufträge anzubieten.

Fig. 3 ein Blockdiagramm eines Druckers, der in dem Netzwerkdrucksystem verwendet wird, und konfigu riert ist, um Druckaufträge gemäß Geboten zu pri orisieren, die durch die Benutzer vorgelegt wur den.

Fig. 4 ein Flußdiagramm eines Prozesses zum Zuordnen ei ner Priorität zu Druckaufträgen basierend auf den Benutzergeboten.

Die gleichen Bezugszeichen werden durch alle Figuren ver wendet, um auf gleiche Komponenten und Merkmale Bezug zu nehmen.

Die Druckpriorität wird gemäß einem Gebotsprozeß gesichert, der es Benutzern ermöglicht, Gebote zusammen mit ihren Druckaufträgen vorzulegen. Der Drucker ordnet die Druckauf träge von dem höchsten zum niedrigsten Gebot. Dies ermög licht es einzelnen Benutzern, die Wichtigkeit ihres Druck auftrages zu bewerten. Ist derselbe dringend, kann der Be nutzer ein höheres Gebot vorlegen, um den Druckauftrag oben an der Warteschlange vor den Druckaufträgen zu plazieren, die durch die Benutzer als weniger wichtig erachtet wurden, die dieselben vorgelegt haben. Das Priorisieren der Druck aufträge gemäß vom Benutzer vorgelegten Geboten ermöglicht es dem Drucker, die Dringlichkeiten und Druckbedürfnisse aller Benutzer zu reflektieren.

Obwohl sich die nachfolgende Erörterung auf den Kontext von Druckern bezieht, kann das Gebotsbasierte Prioritätssystem mit anderen Vorrichtungen verwendet werden, die Auftragsan fragen aufreihen, wie z. B. Scanner, Photokopierer und ähn liches.

Netzwerkdrucksystem

Fig. 1 zeigt ein exemplarisches Netzwerkdrucksystem 100, in dem mehrere Benutzerrechenvorrichtungen 102(1), 102(2), . . ., 102(n) über ein Netzwerk 104 mit einem oder mehreren Druckern 106(1), . . ., 106(p) verbunden sind. Das System 100 implementiert einen Gebotsprozeß für das Priorisieren von Druckaufträgen, die von den Benutzerrechenvorrichtungen 102 zu den Druckern 106 gesendet werden.

Das Netzwerk 104 stellt unterschiedliche Typen von Netzwer ken dar, einschließlich öffentlicher Netzwerke (z. B. das Internet, etc.) und privater Netzwerke (z. B. Intranet, lo kales Netzwerk, weites Netzwerk, etc.). Das Netzwerk 104 kann unter Verwendung einer Vielzahl von Techniken imple mentiert werden, einschließlich auf Draht basierenden Tech niken (z. B. Faseroptik, Kabel, etc.) und drahtlosen Tech niken (z. B. RF, Bluetooth, IR, Mobiltelephon, etc.).

Die Benutzerrechenvorrichtungen 102 können als jegliche aus einer Vielzahl von Computertypen implementiert sein, ein schließlich dem dargestellten Tischpersonalcomputer 102(1), dem Laptop 102(2), und dem drahtlosen PDA (PDA = portable digital assistant = tragbarer, digitaler Assistent) 102(n). Andere mögliche Typen von Rechenvorrichtungen umfassen No tebook-Computer, Palmtop-Computer, Mobiltelephone, Arbeits stationen und ähnliches. Benutzerrechenvorrichtungen können ferner andere Typen von Verbraucherelektronikartikeln um fassen, die zum Drucken in der Lage sind, wie z. B. Digi talkameras, Scanner und ähnliches.

Die Drucker 106 können als unterschiedliche Typen von Drucksystemen implementiert sein, wie z. B. Laserdrucker, Tintenstrahldrucker, Punktmatrixdrucker, usw. Ferner sind die Drucker 106, wie oben erwähnt wurde, repräsentativ für andere Vorrichtungen, die Druckaufträge von mehreren Benut zern aufreihen, wie z. B. Scanner, Photokopierer, und ähn liches.

Ein Token-Server 108 ist ferner mit dem Netzwerk 104 ver bunden. Der Token-Server 108 implementiert eine Token-Bank 110, die digitale Token bzw. Münzen erzeugt, die als Wäh rung in dem Gebotsprozeß verwendet werden sollen. Der To ken-Server 108 weist die Token jeder Benutzerrechenvorrich tung 102 auf einer periodischen (z. B. täglich, wöchent lich, monatlich, etc.) oder gelegentlichen Basis zu. Die Anzahl von Token, die individuellen Benutzern zugeordnet werden, und die Zuordnungszeitgebung, können auf jeglicher Anzahl unterschiedlicher Taktiken basieren, einschließlich Dienstalter, Angestelltenposition, Nähe zum Drucker, etc. Bei einer Implementierung weist der Token-Server 108 jeder Benutzerrechenvorrichtung 102 automatisch eine Defizitan zahl von Token zu, um das Token-Gleichgewicht zurück auf eine vorbestimmte Anzahl zu bringen. Zusätzlich können die Token konfiguriert sein, um nach einer eingestellten Zeit spanne, wie z. B. einem Monat, abzulaufen. Auf diese Weise kann der Token-Server 108 automatisch eine vorbestimmte An zahl von Token in jeder Zeitspanne einer Benutzerrechenvor richtung 102 zuweisen, und weiß, daß die Token entweder verwendet werden oder am Ende dieser Zeitspanne ablaufen.

Die Token können auf unterschiedliche Arten implementiert werden. Wenn Diebstahl oder Vervielfältigung ausgeschlossen wird, können die Token ein einfacher, digitaler Wert oder ein Zählwert sein, der verringert wird, wenn die Benutzer rechenvorrichtungen dieselben verwenden, um eine Drucker priorität anzubieten. Wenn jedoch Diebstahl oder Verviel fältigung erwartet wird, können die Token kryptographisch erzeugt und den individuellen Benutzerrechenvorrichtungen zugewiesen werden, so daß jeder Token eindeutig und nach verfolgbar ist. In diesem letzteren Fall können die Token für eine Bewertung eines betrügerischen Verbrauchs zurück zu dem Token-Server gebracht werden.

Jede Benutzerrechenvorrichtung 102 ist mit einem Drucker treiber 120 ausgestattet. Zu Zwecken des Implementierens des Gebotssystems ist der anderweitig herkömmliche Treiber 120 mit einer Token-Geldtasche 122 ausgestattet, um die To ken zu speichern, die dem Token-Server 108 zugewiesen wer den, und mit einer Gebots-Benutzerschnittstelle (UI user interface) 124, die es dem Benutzer ermöglicht, Gebote für individuelle Druckaufträge einzugeben.

Jeder Drucker 106 ist mit einem gebotsbasierten Priorisie rer 130 ausgestattet. Der Priorisierer untersucht die Druckaufträge in der Druckerwarteschlange und verleiht eine Priorität basierend auf zwei Kriterien. Erstens werden die Druckaufträge basierend auf der Anzahl von Token geordnet, die durch einen Benutzer geboten werden. Dem Druckauftrag mit dem höchsten Gebot wird die höchste Priorität in der Warteschlange zugewiesen. Dem Druckauftrag mit der nächst hohen Anzahl von Token wird die zweithöchste Priorität ge währt, usw.

Wenn mehrere Druckaufträge die gleiche Anzahl von Token an bieten, was zu einem Gleichstand unter dem ersten Kriterium führt, verwendet der Priorisierer ein zweites Kriterium, um den Gleichstand zwischen den mehreren Druckaufträgen zu brechen. Das zweite Kriterium kann auf mehrere Arten imple mentiert werden, wie z. B. dem ersten, empfangenen Druck auftrag eine Priorität verleihen, oder Gewähren einer Prio rität basierend auf dem Benutzerdienstalter oder der physi schen Nähe zu dem Drucker, oder Zuweisen einer Priorität gemäß anderer Verfahrensweisen.

Der zweistufige Priorisierungsprozeß spiegelt die sich dau ernd ändernden Druckbedürfnisse verschiedener Netzwerkbe nutzer wieder. In Fig. 1 wird zum Beispiel angenommen, daß der Benutzer des Klienten-PC 102(1) ein Dokument sehr schnell drucken muß und somit einen Druckauftrag (PJ = print job = Druckauftrag) 140 mit einem Gebot von vier To ken 142 vorlegt. Zu ungefähr der gleichen Zeit steht der Benutzer des Klienten-Laptops 102(2) ferner unter Zeitdruck und entscheidet sich, einen Druckauftrag 144 mit einem Ge bot von drei Token 146 zu senden. Der Benutzer des drahtlo sen PDA 102(n) jedoch legt keinen Wert auf Priorität und leitet somit einen Druckauftrag 148 mit einem Gebot von ei nem Token 150 weiter. Bei diesem Beispiel verleiht der Dru cker dem Druckauftrag 140 mit einem Gebot von vier Token 142 oberste Priorität, zweite Priorität dem Druckauftrag 144 mit einem Gebot von drei Token 146 und eine letzte Pri orität mit dem Druckauftrag 148 mit einem Gebot von einem Token 150.

Jeder Benutzer gibt sein Gebot über die Gebots-UI 124 ein. Fig. 2 zeigt ein exemplarisches Graphikfenster 200, das durch die Gebots-UI 124 vorgelegt wird, wenn der Benutzer bereit ist, einen Druckauftrag an den Drucker zu übermit teln. Das Fenster 200 umfaßt ein Gebotsfeld 202, das es dem Benutzer ermöglicht, die Anzahl von Token für den Druckauf trag einzugeben. Je mehr Token eingegeben werden, desto größer ist die Chance, daß die erste Priorität zugewiesen wird und man oben an die Warteliste bewegt wird. Das Fens ter 200 weist ferner ein Token-Restfeld 204 auf, das die Anzahl von Token auflistet, die in der Geldtasche 122 verbleiben.

Das Fenster 200 kann ferner optional mit einem Grenzfeld 206 ausgestattet sein, das es dem Benutzer ermöglicht, eine maximale Anzahl von Token zu plazieren, die er bereit ist in dem Fall anzubieten, daß andere Benutzer das anfängliche Gebot überbieten. Bei diesem Beispiel gibt der Benutzer ein anfängliches Gebot von zwei Token ein, ist aber bereit bis zu fünf Token anzubieten, wenn ein anderer Benutzer die zwei Token überbietet. Nachdem das Gebot eingegeben wurde, klickt der Benutzer auf das "OK"-Feld 208, um den Druckauf trag und das Gebot an den zugeordneten Drucker zu übertra gen.

Der Drucker 106 empfängt die unterschiedlichen Druckaufträ ge und bietet dieselben in einer Warteschlange an und pla ziert sie. Anfänglich können die Druckaufträge in der Rei henfolge aufgereiht werden, in der sie empfangen wurden, und nachfolgend können dieselben neu geordnet werden. Al ternativ können die Druckaufträge vorübergehend anderswo gespeichert und überprüft werden, um ihre Priorität zu bestimmen, bevor sie in die Warteschlange gestellt werden.

Fig. 3 zeigt den Drucker 106 detaillierter. Der Drucker 106 ist mit einer Verarbeitungseinheit 300, einem Druckermecha nismus 302 und einem Speicher 304 ausgestattet. Der gebots basierte Priorisierer 130 ist derart gezeigt, daß er sich in der Verarbeitungseinheit 300 befindet, um zu demonstrie ren, daß derselbe in der Hardware als Teil des Verarbei tungschips implementiert sein kann, oder daß er Soft ware/Firmware sein kann, die auf der Verarbeitungseinheit 300 Befehle ausführt.

Eine Warteschlange 310 ist in dem Speicher 304 gespeichert. Die Warteschlange 310 hält die Druckaufträge, die von den Benutzercomputern über das Netzwerk empfangen werden. Bei diesem Beispiel enthält die Warteschlange 310 vier Druck aufträge 312(1)-312(4). Für jeden Druckauftrag listet die Warteschlange 310 verschiedene Felder auf, einschließlich eines Benutzer-ID-Feldes 314, um den Benutzer zu identifi zieren, ein Gebotsfeld 316, das das Gebot des Benutzers für diesen Druckauftrag spezifiziert, ein Gebotszeitfeld 318, das notiert, wann der Druckauftrag empfangen wurde und ein Grenzfeld 320, das die obere Gebotsgrenze identifiziert. Zusätzlich dazu weist die Warteschlange 310 ein Empfangs reihenfolge-Feld 322 auf, das die Reihenfolge nachverfolgt, in der die Druckaufträge empfangen wurden, und ein Auf tragsnummerfeld 324, das die aktuelle Priorität zeigt, die den Druckaufträgen gegeben wurde.

Der gebotsbasierte Priorisierer 130 bewertet die Druckauf träge in der Warteschlange und priorisiert dieselben basie rend auf ihren Geboten (und wenn nötig sekundär basierend auf anderen Kriterien). Bei dem Beispiel von Fig. 3 wurde der erste Druckauftrag 312(1) eigentlich als letztes emp fangen, aber aufgrund des höchsten Gebots von vier Token wurde derselbe oben an die Warteschlange bewegt. Der zweite Druckauftrag 312(2) wurde eigentlich als erstes empfangen, aber da der Benutzer nur drei Token geboten hat, mit einer Obergrenze von drei Token, konnte derselbe nicht mit dem Gebot des ersten Druckauftrags von vier Token konkurieren. Daher wurde der als erstes eingereichte Druckauftrag zu gunsten des später eingereichten Druckauftrages nach hinten verschoben, der mehr Token geboten hat.

Wenn ein Druckauftrag gerade überboten wird, steigert der Priorisierer 130 automatisch das Gebot für diesen Druckauf trag um je ein Token, bis das Gebot entweder das oberste Gebot in der Warteschlange wird, oder seine Obergrenze er reicht, die in dem Grenzfeld 320 spezifiziert ist. Um die ses Merkmal darzustellen, wird angenommen, daß der erste Druckauftrag 312(1), der oben an der Warteschlange 310 ge zeigt ist, ursprünglicherweise als Gebot von zwei Token vorgelegt wurde, wie bei der UI 200 von Fig. 2 dargestellt ist. Wenn der Drucker 106 dieses Gebot empfängt, wird das selbe anfänglich hinter einem anderen Druckauftrag 312(2) mit einem höheren Gebot von drei Token priorisiert.

Beim Versuchen, den Druckauftrag 312(1) zu priorisieren, bestimmt der Priorisierer 130, daß das Gebot auf vier Token erhöht werden kann, ohne die Obergrenze von fünf Token zu überschreiten und erhöht automatisch das Gebot. Der Priori sierer 130 überprüft ferner den anderen Druckauftrag 312(2) und stellt sicher, daß derselbe nicht erhöht werden kann, da sich derselbe bereits an dessen Obergrenze von drei To ken befindet. Somit wird dem später eingereichten Druckauf trag 312(2) oberste Priorität gegeben.

Der Priorisierer 130 kann ferner konfiguriert sein, um we niger Token zu verwenden als geboten sind. Dies ist beson ders in jenen Fällen nützlich, wenn das Gebot jegliche an deren Gebote um mehr als ein Token schlägt, oder wenn keine anderen Druckaufträge in der Warteschlange vorhanden sind. Man betrachte zum Beispiel die Situation, in der ein Benut zer mit einem Eilauftrag ein Gebot von fünf Token vorlegt, doch das höchste Gebot aller Druckaufträge in der Warte schlange ist nur zwei Token. In diesem Fall wird der Druck auftrag des Benutzers aufgrund seines hohen Gebots als ers tes verarbeitet. Es wird jedoch darauf hingewiesen, daß der Auftrag des Benutzers mit einem niedrigeren Gebot, das zwei Token überschreitet, immer noch verarbeitet werden würde. Dementsprechend reduziert der Priorisierer 130 automatisch die Anzahl von Token, die ausgegeben wurden, um den Druck auftrag zu verarbeiten, auf den geringsten Wert, der trotz dem die Absicht des Benutzers ausführt. Hier reduziert der Priorisierer das Gebot auf drei Token. Wären überhaupt kei ne Druckaufträge vorhanden gewesen, könnte der Priorisierer 130 die Anzahl von Token ferner automatisch auf null redu zieren.

Sobald die Druckaufträge fertiggestellt sind, kann der Dru cker optional die eigentliche Anzahl von Token zurück an die Benutzercomputer berichten, die ausgegeben wurden, um den Druckauftrag zu verarbeiten. Diese Beträge werden dann von der Geldtasche 122 an den jeweiligen Benutzermaschinen abgezogen. Wenn die Token kryptographisch erstellt sind, können sie entweder an dem Drucker zerstört werden oder zu rück an den Server berichtet werden, um nachzuverfolgen, ob die Benutzer ihre Token legitim verbrauchen oder dieselben betrügerischerweise doppelt verbrauchen.

An der oben beschriebenen Architektur können Modifikationen vorgenommen werden. Bei einer alternativen Implementierung kann der Drucker 106 zum Beispiel konfiguriert sein, um die Token zu speichern und die Tokenverwendung für den Benutzer nachzuverfolgen. Diese Alternative würde die Verwendung der Token-Geldtasche 122 an den Benutzercomputern 102 beseiti gen. Als eine andere Alternative kann der Drucker selbst konfiguriert sein, um Token individuellen Benutzerkonten zuzuordnen, die an dem Drucker beibehalten werden, wodurch die Funktion des Token-Servers 108 in dieser modifizierten Architektur entfernt wird.

Verfahren

Fig. 4 zeigt einen Prozeß für das Zuweisen einer Priorität an Druckaufträge basierend auf einem Gebot. Der Prozeß 400 deckt Operationen ab, die an unterschiedlichen Komponenten des Druckerprioritäts-Gebotssystems durchgeführt werden, und somit sind die Blöcke in Fig. 4 unter den Überschriften angeordnet, um exemplarische Komponenten zu identifizieren, die derartige Operationen durchführen. Der Prozeß 400 kann in der Software implementiert sein oder in einer Kombinati on aus Hardware und Software. Als solches können gewisse Operationen, die in Fig. 4 als Blöcke dargestellt sind, computerausführbare Befehle darstellen, die den Server, die Benutzerrechenvorrichtungen oder den Drucker anweisen, wenn dieselben ausgeführt werden, um diese Operationen durchzu führen.

Bei Block 402 ordnet ein Token-Server 108 den Benutzerre chenvorrichtungen Token zu. Diese Zuordnung kann wiederum gelegentlich, periodisch, nach Bedarf oder gemäß einer be liebigen Verfahrensweise durchgeführt werden, die durch den Systemverwalter eingerichtet wurde. Die Anzahl von Token, die jedem Benutzer zugeordnet wird, kann konstant oder va riabel sein.

Bei Block 404 speichert die Benutzerrechenvorrichtung 102 die zugeordneten Token in der Token-Geldtasche 122. Wenn sich der Benutzer entscheidet, ein Dokument oder einen an deren Auftrag zu drucken (d. h. für den Zweig "JA" von Block 406), präsentiert die Gebot-UI 124 ein Druckfenster, wie zum Beispiel Fenster 200 in Fig. 2, das es dem Benutzer ermöglicht, die Anzahl von Token einzugeben, die er/sie für diesen Druckauftrag anbieten möchte (Block 408). Der Benut zer plaziert effektiv eine Wichtigkeit an den Druckauftrag durch Anbieten von mehr oder weniger Token.

Die Benutzerrechenvorrichtung 102 kann konfiguriert sein, um sicherzustellen, daß der Benutzer nicht mehr Token ein gibt, als tatsächlich in der Geldtasche 122 vorhanden sind. Alternativ kann es die Benutzerrechenvorrichtung 102 dem Benutzer ermöglichen, Token an mehrere Drucker anzubieten, in der Hoffnung, einen Drucker zu finden, der verfügbar ist, obwohl nicht genügend Token in der Geldtasche vorhan den sind, um die Gebote abzudecken. In diesem Fall, wenn ein Drucker das Gebot annimmt und mit dem Drucken beginnt, zieht die Benutzerrechenvorrichtung schnell das (die) Ge bot(e) zurück, die an jegliche andere Drucker gemacht wur den.

Nachdem der Benutzer ein annehmbares Gebot eingibt und den Druckprozeß startet, sendet die Benutzerrechenvorrichtung 102 den Druckauftrag und das Gebot an den gekennzeichneten Drucker 106 über das Netzwerk 104 (Block 410).

Der Drucker 106 empfängt den Druckauftrag und speichert den Druckauftrag in dessen Warteschlange oder einer anderen, temporären Speicherposition. Bei Block 412 bewertet der ge botsbasierte Priorisierer 130 das Gebot durch Vergleichen desselben mit den Geboten der anderen Aufträge in der War teschlange. Der gebotsbasierte Priorisierer 130 priorisiert dann die Druckaufträge in der Warteschlange von dem höchs ten Gebot zum niedrigsten Gebot (Block 414).

Wenn zwei Druckaufträge den gleichen Tokenwert anbieten, was zu einem Gleichstand führt (d. h. der Zweig "JA" aus Block 416), dann bestimmt der Priorisierer 130, ob eines (oder beide) der Gebote in einem aktuellen Gebotsfeld 316 an ihrer Maximalgrenze sind, die in dem Grenzfeld 320 ange merkt ist (Block 418). Wenn ein Gebot seine Grenze noch nicht erreicht hat, erhöht der Priorisierer 130 automatisch das Gebot für diesen Druckauftrag (Block 420) und bewertet die Warteschlange noch einmal neu.

Wenn die gleichen Druckaufträge nicht durch Erhöhen der An zahl von Token unterschieden werden können, priorisiert der Priorisierer 130 die Druckaufträge mit dem gleichen Gebot gemäß dem zweiten Kriterium, wie z. B. zuerst empfangen, Dienstalter des Benutzers, Nähe zum Drucker, etc. (Block 422). Bei Block 424 verarbeitet der Drucker den Druckauf trag mit der höchsten Priorität.

Sobald dieser Druckauftrag verarbeitet ist, kann der Dru cker 106 optional die Anzahl von Token, die durch den Be nutzer ausgegeben wurde, berichten (Block 426). Der Benut zercomputer reduziert den Restbetrag in der Token- Geldtasche 122 um die Anzahl, die durch den Drucker 106 zu rück geliefert wird (Block 428).

Claims

1. Verfahren, das folgende Schritte aufweist:
Empfangen mehrerer Druckaufträge (312(1)-312(4)) zum Drucken in einer ersten Reihenfolge, wobei die Druck aufträge zugeordnete Gebote (316) aufweisen; und
Priorisieren der Druckaufträge gemäß ihrer zugeordne ten Gebote, so daß die Druckaufträge in einer zweiten Reihenfolge gedruckt werden, die sich von der ersten Reihenfolge unterscheidet.

2. Verfahren gemäß Anspruch 1, bei dem das Priorisieren das Gewähren einer höheren Priorität für die Druckauf träge mit höheren, zugeordneten Geboten aufweist.

3. Verfahren gemäß Anspruch 1 oder 2, bei dem die Gebote ein aktuelles Gebot und ein maximales Gebot spezifi zieren und ferner das Erhöhen eines Gebots von mindes tens einem Druckauftrag ohne Überschreiten des Maxi malgebots aufweisen, falls mehrere Druckaufträge iden tische Gebote aufweisen.

4. Verfahren gemäß einem der Ansprüche 1 bis 3, das fer ner das Priorisieren des Satzes von mehreren Druckauf trägen gemäß einem zweiten Kriterium aufweist, falls ein Satz von mehreren Druckaufträgen identische Gebote aufweist.

5. Verfahren bei einem Netzwerkdrucksystem (100), bei dem mehrere Benutzercomputer (102) mit einem üblichen Dru cker (106) vernetzt sind, mit folgenden Schritten:
Zuordnen von Druck-Token zu den Benutzercomputern (102);
Vorlegen einer Benutzerschnittstelle an einen Benut zercomputer (102), um das Eingeben eines Gebots für einen Druckauftrag zu ermöglichen, wobei das Gebot ei ne Anzahl von Druck-Token spezifiziert;
Senden des Druckauftrags zusammen mit dem Gebot an den Drucker (106);
Priorisieren der Druckaufträge an dem Drucker (106) gemäß ihrer zugeordneten Gebote; und
Verarbeiten der Druckaufträge.

6. Verfahren gemäß Anspruch 5, bei dem das Zuordnen fol gende Schritte aufweist:
Erzeugen der Druck-Token an einem Server (108); und
Liefern der Druck-Token an die Benutzercomputer (102).

7. Verfahren gemäß Anspruch 5 oder 6, bei dem die Druck- Token eine vorbestimmte Ablaufzeit aufweisen.

8. Verfahren gemäß einem der Ansprüche 5 bis 7, bei dem die Benutzerschnittstelle (124) ferner das Eingeben einer Maximalanzahl von Druck-Token ermöglicht, die der Benutzer bereit ist zu bieten, und ferner ein Er höhen des Gebots ohne Überschreiten der maximalen An zahl von Druck-Token in einem Fall aufweist, daß ein anderer Druckauftrag ein höheres Gebot aufweist.

9. Verfahren gemäß einem der Ansprüche 5 bis 8, das fer ner das Verwenden von um eins oder mehr Druck-Token weniger aufweist, als in dem Gebot für einen bestimm ten Druckauftrag spezifiziert sind, in einem Fall, daß die Priorität des bestimmten Druckauftrags nicht be einträchtigt wird.

10. Verfahren gemäß einem der Ansprüche 5 bis 9, bei dem das Priorisieren das Gewähren einer höheren Priorität für die Druckaufträge mit höheren, zugeordneten Gebo ten aufweist.

11. Verfahren gemäß einem der Ansprüche 5 bis 10, das in einem Fall, daß ein Satz mehrerer Druckaufträge iden tische Gebote aufweist, das Priorisieren des Satzes mehrerer Druckaufträge gemäß einem zweiten Kriterium aufweist.

12. Verfahren gemäß einem der Ansprüche 5 bis 11, das fer ner das Berichten einer tatsächlichen Anzahl von Druck-Token an den Benutzercomputer aufweist, die aus gegeben wurden, um den Druckauftrag zu verarbeiten.

13. Verfahren gemäß einem der Ansprüche 5 bis 12, das fer ner das Reduzieren der Anzahl von Druck-Token, die zum Bieten verfügbar sind, an dem Benutzercomputer auf weist, um die Anzahl von Druck-Token, die in dem Gebot verwendet werden.

14. Verfahren bei einer Netzwerkumgebung (104), in der Be nutzerrechenvorrichtungen (102) Auftragsanfragen an eine andere Vorrichtung für eine Verarbeitung vorle gen, mit folgenden Schritten:
Ermöglichen, daß Benutzer Gebote mit ihren Auftragsan fragen vorlegen; und
Priorisieren der Auftragsanfragen gemäß ihren zugeord neten Geboten.

15. Verfahren gemäß Anspruch 14, bei dem das Ermöglichen das Vorlegen einer Benutzerschnittstelle (124) auf weist, die einen Eintrag der Gebote durch den Benutzer ermöglicht.

16. Verfahren gemäß Anspruch 14 oder 15, bei dem das Er möglichen ein Erlauben aufweist, daß ein Benutzer ein maximales Gebot spezifiziert, so daß sein ursprüngli ches Gebot auf ein erhöhtes Gebot erhöht werden kann, das das maximale Gebot nicht überschreitet, um eine Priorität gegenüber einer Auftragsanfrage mit einem Gebot zu erlangen, das höher ist, als das ursprüngli che Gebot.

17. Verfahren gemäß einem der Ansprüche 14 bis 16, bei dem das Priorisieren das Gewähren einer höheren Priorität für die Auftragsanforderungen mit höheren, zugeordne ten Geboten aufweist.

18. Verfahren gemäß einem der Ansprüche 14 bis 17, das in einem Fall, daß ein Satz von mehreren Druckaufträgen mit identischen Geboten existiert, ferner das Priori sieren des Satzes mehrerer Auftragsanforderungen gemäß einem zweiten Kriterium aufweist.

19. Netzwerkdrucksystem (100), das folgende Merkmale auf weist:
mindestens einen Drucker (106);
mehrere Benutzerrechenvorrichtungen (102), die konfi guriert sind, um Druckaufträge über ein Netzwerk (104) an den Drucker (106) zu übertragen;
wobei die mehreren Benutzerrechenvorrichtungen (102) ferner konfiguriert sind, um zu ermöglichen, daß zuge hörige Benutzer Gebote mit ihren Druckaufträgen vorle gen; und
wobei der Drucker (106) konfiguriert ist, um die Druckaufträge gemäß ihren zugeordneten Geboten zu pri orisieren.

20. Netzwerkdrucksystem (100) gemäß Anspruch 19, bei dem individuelle Benutzerrechenvorrichtungen (102) eine Benutzerschnittstelle (124) aufweisen, die eine Benut zereingabe eines Gebots ermöglicht.

21. Netzwerkdrucksystem (100) gemäß Anspruch 19 oder 20, bei dem individuelle Benutzerrechenvorrichtungen (102) eine Benutzerschnittstelle (124) aufweisen, die eine Benutzereingabe eines anfänglichen Gebots und eines maximalen Gebots ermöglicht, das ein Benutzer bereit ist in einem Fall anzubieten, daß ein anderer Druck auftrag ein Gebot aufweist, das höher ist als das an fängliche Gebot.

22. Netzwerkdrucksystem (100) gemäß einem der Ansprüche 19 bis 21, bei dem der Drucker (106) ferner konfiguriert ist, um die mehreren Druckaufträge gemäß einem zweiten Kriterium zu priorisieren, in einem Fall, daß mehrere Druckaufträge identische Gebote aufweisen.

23. Netzwerkdrucksystem gemäß einem der Ansprüche 19 bis 22, bei dem die Gebote in Token bemessen sind, und bei dem der Drucker ferner konfiguriert ist, um Token für die Benutzerrechenvorrichtungen (102) zur Verwendung bei den Geboten zuzuordnen.

24. Netzwerkdrucksystem (100) gemäß einem der Ansprüche 19 bis 23, bei dem die Gebote in Token bemessen sind, wo bei das System (100) ferner einen Token-Server (108) aufweist, der konfiguriert ist, um Token den Benutzer rechenvorrichtungen (102) zur Verwendung bei den Gebo ten zuzuordnen.

25. Netzwerkdrucksystem (100) gemäß einem der Ansprüche 19 bis 24, bei dem die Gebote in Token bemessen sind, und bei dem der Drucker ferner konfiguriert ist, um die Anzahl von Token, die verwendet wurden, um die Druck aufträge zu verarbeiten, zurück an die Benutzerrechen vorrichtungen (102) zu berichten.

26. Drucker (106), der folgende Merkmale aufweist:
eine Warteschlange (310), um Druckaufträge (312(1)- 312(4)) zu speichern; und
einen gebotsbasierten Priorisierer (130), um die Druckaufträge in der Warteschlange gemäß Geboten zu priorisieren, die in Zuordnung zu den Druckaufträgen vorgelegt wurden.

27. Drucker (106) gemäß Anspruch 26, bei dem der gebotsba sierte Priorisierer (130) ferner konfiguriert ist, um die mehreren Druckaufträge gemäß einem zweiten Krite rium zu priorisieren, in einem Fall, daß mehrere Druckaufträge identische Gebote aufweisen.

28. Drucker (106) gemäß Anspruch 26 oder 27, bei dem die Gebote einen anfänglichen Gebotswert und einen maxima len Gebotswert umfassen, und bei dem der gebotsbasier te Priorisierer (130) ferner konfiguriert ist, um das Gebot eines Druckauftrags von dessen anfänglichem Ge botswert bis zu dem maximalen Gebotswert zu erhöhen, bei einem Versuch, Priorität gegenüber einem anderen Druckauftrag mit einem Gebot zu erhalten, das anfäng lich höher ist als der anfängliche Gebotswert.

29. Drucker (106) gemäß einem der Ansprüche 26 bis 28, bei dem die Gebote in Token bemessen sind, und bei dem der gebotsbasierte Priorisierer (130) ferner konfiguriert ist, um einen oder mehrere Token weniger zu verwenden, als bei einem Gebot für einen bestimmten Druckauftrag spezifiziert ist, solange die Priorität des bestimmten Druckauftrags nicht beeinträchtigt wird.

30. Architektur, die folgende Merkmale aufweist:
ein Druckermodul, das auf einem Benutzercomputer (102) vorhanden ist, das eine Benutzerschnittstelle (124) präsentiert, um es zu ermöglichen, daß ein Benutzer eine Anzahl von Druck-Token für einen Druckauftrag (312(1)-312(4)) bietet; und
ein Priorisierungsmodul, das an einem Drucker vor liegt, das Druckaufträge priorisiert, die aktuell an dem Drucker aufgereiht sind, basierend auf der Anzahl von Druck-Token, die für Druckaufträge geboten werden.

31. Architektur gemäß Anspruch 30, bei der die Druck-Token dem Benutzercomputer (102) zugeordnet sind, und das Druckermodul eine Token-Geldtasche (122) aufweist, um die Druck-Token zu speichern.

32. Architektur gemäß Anspruch 30 oder 31, bei der das Priorisierungsmodul konfiguriert ist, um die mehreren Druckaufträge gemäß einem zweiten Kriterium zu priori sieren, in einem Fall, daß mehrere Druckaufträge iden tische Gebote aufweisen.

33. Architektur gemäß einem der Ansprüche 30 bis 32, bei der die Benutzerschnittstelle (200) ermöglicht, daß ein Benutzer ein maximales Gebot zusammen mit einem ursprünglichen Gebot spezifiziert, und bei der das Priorisierungsmodul die Anzahl von Druck-Token von dem ursprünglichen Gebot bis auf das maximale Gebot in ei nem Fall erhöht, daß ein anderer Druckauftrag ein Ge bot aufweist, das anfänglich höher ist als das ur sprüngliche Gebot.

34. Architektur gemäß Anspruch 30, bei der die Gebote in Token bemessen sind, und der gebotsbasierte Priorisie rer (130) ferner konfiguriert ist, um einen oder meh rere Token weniger zu verwenden, als in dem Gebot spe zifiziert sind, solange die Priorität des Druckauf trags nicht beeinträchtigt wird.

35. Architektur gemäß einem der Ansprüche 30 bis 34, die ferner einen Token-Server (108) aufweist, der auf ei nem Servercomputer vorliegt, der dem Druckermodul an dem Benutzercomputer Token zuordnet.

36. Ein oder mehrere computerlesbare Medien, die computer ausführbare Befehle aufweisen, die, wenn sie ausge führt werden, einen Drucker (106) anweisen, um:
Druckaufträge aufzureihen; und
die Druckaufträge gemäß Geboten zu priorisieren, die in Zuordnung zu den Druckaufträgen vorgelegt wurden.

37. Ein oder mehrere computerlesbare Medien gemäß Anspruch 36, die ferner computerausführbare Befehle aufweisen, die, wenn sie ausgeführt werden, einen Drucker anwei sen, Druckaufträge mit identischen Geboten gemäß einem zweiten Kriterium zu priorisieren.

38. Ein oder mehrere computerlesbare Medien gemäß Anspruch 36 oder 37, bei dem die Gebote ein anfängliches Gebot und ein Maximalgebot spezifizieren, und die ferner computerausführbare Befehle aufweisen, die, wenn sie ausgeführt werden, einen Drucker anweisen, das anfäng liche Gebot eines Druckauftrages zu erhöhen, ohne das Maximalgebot zu überschreiten, um eine höhere Priori tät für den Druckauftrag zu erhalten.

39. Ein oder mehrere computerlesbare Medien gemäß einem der Ansprüche 36 bis 38, bei dem die Gebote in Token bemessen sind, und die ferner computerausführbare Be fehle aufweisen, die, wenn sie ausgeführt werden, ei nen Drucker anweisen, einen oder mehrere Token weniger zu verwenden, als bei einem Gebot für einen speziellen Druckauftrag spezifiziert wurde, wenn weniger Token ausreichend sind, um den speziellen Druckauftrag zu verarbeiten, ohne die Priorität zu beeinträchtigen.

40. Graphikdruckmenü-Benutzerschnittstelle, die folgende Merkmale aufweist:
ein Gebotseingabefeld, das es einem Benutzer ermög licht, eine Anzahl von Token für einen Druckauftrag anzubieten, wobei den Druckaufträgen eine Priorität an einem Drucker basierend auf den Geboten gegeben wird; und
ein Token-Restfeld, das eine Anzahl von Token vorlegt, die für ein Gebot verfügbar sind.

41. Graphikdruckmenü-Benutzerschnittstelle gemäß Anspruch 40, die ferner ein Grenzeingabefeld aufweist, das eine Benutzereingabe einer maximalen Anzahl von Token er möglicht, auf die das Gebot für den Druckauftrag er höht werden kann.