DE60012447T2

DE60012447T2 - Datendekompression

Info

Publication number: DE60012447T2
Application number: DE60012447T
Authority: DE
Inventors: Daniel R. Pearson; David A. Kumpf
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 1999-09-24
Filing date: 2000-09-22
Publication date: 2005-07-28
Anticipated expiration: 2020-09-23
Also published as: EP1089518A3; EP1089518B1; EP1089518A2; JP2001159996A; DE60012447D1; US6438610B1

Description

Die vorliegende Erfindung bezieht sich allgemein auf ein Verfahren und eine Vorrichtung zum Dekomprimieren von Daten in einer Client/Server-Umgebung, und insbesondere zum Dekomprimieren von Scannerbilddaten von einem gemeinsam verwendeten Peripheriegerät und zum Übertragen derselben, damit diese auf einem Webbrowser eines Clients dargestellt werden können. Insbesondere betrifft die vorliegende Erfindung eine Software/Firmware, die die Speicherressourcen, die beim Dekomprimieren von Daten, die während des Betriebs von einem Netzwerkperipheriegerät empfangen werden, und beim Übertragen derselben an einen Client-Webbrowser benötigt werden, verringert.
Scan-Peripheriegeräte werden zu einem größeren Segment der Peripheriegeräte-Branche. Benutzer finden derartige Peripheriegeräte als Mittel zur Eingabe von Text, Graphiken und Bildern nützlich. Viele Softwareanwendungen ermöglichen mittlerweile eine Manipulation und Nutzung derartiger Daten.
Die EP-A-0,932,291 offenbart ein Netzwerkscansystem, das eine Mehrzahl von Anschlüssen umfasst, die über ein Netzwerk verbunden sind; eine Speichereinrichtung, die über das Netzwerk verbunden ist, zum Speichern von Attributinformationen für jeden der Mehrzahl von Anschlüssen; eine Bildleseeingabeeinrichtung, die über das Netzwerk verbunden ist, zum Lesen eines Bildes, Umwandeln des Bildes in elektronisch verarbeitete Bildinformationen und Eingeben der Bildinformationen; eine Temporärspeichereinrichtung zum vorübergehenden Speichern der elektronisch verarbeiteten Bildinformationen, die von der Bildleseeingabeeinrichtung eingegeben werden; eine Empfangseinrichtung zum Empfangen einer Transferanforderung von der Mehrzahl von Anschlüssen, für einen Transfer der durch die Bildleseeingabeeinrichtung gelesenen Bildinformationen; eine Umwandlungseinrichtung zum Lesen, wenn die Empfangseinrichtung die Transferanforderung bezüglich des Transfers der Bildinformationen von der Mehrzahl von Anschlüssen empfangen hat, der Attributinformationen des Anschlusses, der der Transferanforderung zugeordnet ist, aus der Speichereinrichtung, und zum Umwandeln der in der Temporärspeichereinrichtung gespeicherten Bildinformationen auf der Basis der ausgelesenen Attributinformationen; und eine Transfereinrichtung zum Transferieren, über das Netzwerk, der durch die Umwandlungseinrichtung umgewandelten Bildinformationen an den Anschluss eines Ursprungs der Transferanforderung.
In der US-5,727,159 ist ein Rechensystem offenbart, das einen Feldcomputer aufweist, der eine Anzeige mit einer spezifischen Größe und Auflösung; und einen Proxy-Server, der durch eine Datenverbindung mit dem Feldcomputer verbunden ist, wobei der Proxy-Server ein Internet-Tor aufweist, umfasst.
Der Proxy-Server lädt Daten, die Webseiten umfassen, herunter und transponiert die Daten so, dass sie mit der spezifischen Größe und Auflösung der Anzeige des Feldcomputers zusammenpassen.
Manche Peripheriegeräte kombinieren das Scannen mit anderen Funktionen. Diese Multifunktions-Peripheriegeräte sind teilweise auf Grund ihrer Fähigkeit, mehrere nützliche Funktionen in einer einzigen Vorrichtung zu kombinieren, beliebt. Wenn sie mit dem Netzwerk verbunden sind, sind die Peripheriegeräte über einen zweckgebundenen Peripheriegeräte-Server, der Software und Firmware umfasst, wirksam mit den Clientvorrichtungen verbunden, um den Clients zu ermöglichen, unter Verwendung eines Webbrowsers mit den Peripheriegeräten zu interagieren. Eine derartige Software und Firmware ist in der gemeinschaftlich übertragenen US-Patentanmeldung Seriennummer 091163,791, die am 30. September 1998 von Kumpf et al. eingereicht wurde und die durch Bezugnahme in das vorliegende Dokument aufgenommen ist, offenbart.
Allgemein liefert die in der Anmeldung von Kumpf et al. offenbarte Erfindung ein interaktives, vernetztes Client/Server-Scanverfahren, das durch eine Webbrowser-Schnittstelle auf einem Client gestartet und aktiv verwaltet wird. Ein Server spricht auf eine URL-Adresse (URL = universal resource locator, Einheitsressourcenlokator) an, die den Server mit einem Mehrzweckformat-Softwareprogramm identifiziert, das eine Schnittstelle in dem Client-Webbrowser erzeugt und den Client befähigt, beim Einleiten, Verändern und Überwachen von Scanaufträgen und verwandten Daten mit dem Server zu interagieren.
Die vorliegende Erfindung ist auf Verbesserungen der oben erwähnten Offenbarung gerichtet, die eine Verringerung der Menge an Ressourcen ermöglichen, die benötigt werden, um die durch das Peripheriegerät erzeugten Daten zu dekomprimieren. Insbesondere Peripheriegeräte wie z.B. eine Scanvorrichtung erzeugen große Datenmengen, die üblicherweise in einem komprimierten Format übertragen werden. Jedoch erwartet ein Mehrzweck-Webbrowser wie NETSCAPE NAVIGATOR^® oder MICROSOFT INTERNET EXPLORER^® in der Regel, eine vordefinierte Menge dekomprimierter Daten zu empfangen. Auf Grund einer Vielzahl von Faktoren ist es schwierig, die durch einen Scanvorgang erzeugte Datenmenge vorherzusagen, auch wenn die Größe des gescannten Bildes bekannt ist. Ferner ist es schwierig, die Menge an dekomprimierten Daten, die sich aus einem Dekomprimieren einer gegebenen Menge an komprimierten Daten ergeben, präzise vorherzusagen.
Dementsprechend besteht eine Aufgabe der vorliegenden Erfindung darin, ein verbessertes Verfahren zum Dekomprimieren von Daten, die an einem Software-Darstellungsprogramm in einer Client/Server-Umgebung angezeigt werden sollen, bereitzustellen, in der eine Scanservervorrichtung Kommunikationen über ein Netzwerk zwischen zumindest einem gemein sam verwendeten Peripheriegerät, das Daten in einem komprimierten Format bereitstellt, und einem Webbrowser weiterleitet, der sich auf einer Clientvorrichtung befindet und eine vorbestimmte Menge (Darstellungsgröße) dekomprimierter Daten erwartet.
Eine weitere Aufgabe der vorliegenden Erfindung besteht darin, ein derartiges Verfahren in Software oder Firmware bereitzustellen, die sich entweder auf dem Scanserver oder der Clientvorrichtung befindet.
Die vorliegende Erfindung liefert ein Verfahren und eine Vorrichtung zum Dekomprimieren und Kommunizieren einer vorbestimmten Datenmenge in einer Client/Server-Umgebung, in der der Server Kommunikationen zwischen einem Client-Webbrowser und zumindest einem Peripheriegerät weiterleitet. Komprimierte Daten von dem Peripheriegerät werden während des Betriebs dekomprimiert, gepackt und an den Client-Webbrowser übertragen. Eine entsprechende Logik ist vorgesehen, um zu gewährleisten, dass der Webbrowser eine erwartete Menge dekomprimierter Daten empfängt, ungeachtet der durch das Peripheriegerät bereitgestellten Menge komprimierter Daten. Überdies ist eine Logik vorgesehen, um die Menge an Ressourcen, die beim Dekomprimieren der Daten erforderlich sind, zu verringern.
Gemäß einem Aspekt der Erfindung wird ein Eingangspuffer, der komprimierte Daten speichert, jedes Mal, wenn der Eingangspuffer leer wird, wieder aufgefüllt.
Gemäß einem weiteren Aspekt der Erfindung wird ein Ausgangspuffer, der dekomprimierte Daten speichert, an den Webbrowser übertragen, wenn die Menge an in dem Ausgangspuffer enthaltenen dekomprimierten Daten (amt-gespeichert) zumindest einen gegebenen vorbestimmten Wert aufweist.
Gemäß einem weiteren Aspekt der Erfindung wird der Eingangspuffer, der komprimierte Daten speichert, gleichzeitig mit einer Datendekomprimierung wieder aufgefüllt, so dass in dem Eingangspuffer komprimierte Daten gespeichert werden, während komprimierte Daten dekomprimiert und in dem Ausgangspuffer gespeichert werden.
Bei einem bevorzugten Ausführungsbeispiel der Erfindung ist die Datendekomprimierungslogik in einer Software/Firmware auf dem Scanserver verkörpert. Der Scanserver fordert Blöcke dekomprimierter Daten von dem gemeinsam verwendeten Peripheriegerät an, dekomprimiert die Daten und überträgt die dekomprimierten Daten während des Betriebs an den Client-Webbrowser. Der Server verfolgt die Menge an übertragenen Daten nach und leitet, falls notwendig, eine Füll/Abschneidoperation ein, um zu gewährleisten, dass der Client-Webbrowser die erwartete Datenmenge empfängt.
Weitere Ziele, Merkmale und Vorteile ergeben sich aus einer Lektüre der folgenden ausführlichen Beschreibung in Verbindung mit den beigefügten Zeichnungen, bei denen:
1 eine Übersicht über ein Netzwerksystem ist, bei dem vorzugsweise das vorliegende Verfahren angewendet wird; und
2 ein Flussdiagramm des Datendekomprimierungsverfahrens der vorliegenden Erfindung ist.
Allgemein gesagt ist die vorliegende Erfindung auf ein Verfahren zum Verringern der beim Dekomprimieren von Daten erforderlichen Speichermenge, während gewährleistet wird, dass eine vorbestimmte Datenmenge dekomprimiert wird, gerichtet. Die vorliegende Erfindung wird durch Software, Firmware und Hardware verwirklicht, die eine während des Betriebs erfolgende Dekomprimierung von Daten in einer Client/Server-Umgebung liefert, in der ein Webbrowser, der sich auf einer Clientvorrichtung befindet, eine erwartete Menge an zu empfangenden dekomprimierten Daten spezifiziert und ein Peripheriegerät eine gegebene Datenmenge, die gleich der erwarteten Menge dekomprimierter Daten sein kann, aber nicht muss, überträgt.
Unter Bezugnahme auf die Zeichnungen und insbesondere auf 1 ist die vorliegende Erfindung in einem Netzwerksystem implementiert, das einen Netzwerk-Peripheriegeräte-Server 10 wie z.B. eine JETDIRECT-Box von Hewlett-Packard umfasst. Die JETDIRECT-Box ist in einem Benutzerhandbuch von Hewlett-Packard, Teil Nr. 5967-2290, gezeigt und beschrieben und ist durch Bezugnahme in das vorliegende Dokument aufgenommen. Man sollte jedoch verstehen, dass die Funktionen des Servers 10 beispielsweise als Teil einer Karte ausgeführt werden können, die über eine Busschnittstelle mit dem Peripheriegerät verbunden ist, oder als Teil einer internen Zentralverarbeitungseinheit (CPU) eines angeschlossenen Netzwerkperipheriegeräts ausgeführt werden können. Der Server 10 ist über ein Netzwerk 14 mit einer Mehrzahl von Clients 12 verbunden, die typischerweise und vorzugsweise Personal-Computer (PCs) sind. Der Server 10 verbindet ferner die Clients 12 wirksam mit einem Peripheriegerät 16 wie z.B. einem Scanner, das bzw. der ein allein stehendes Scanperipheriegerät oder ein Multifunktions-Peripheriegerät (MPF) sein kann, das verschiedene Funktionen wie z.B. Drucken und Scannen ausführt. Der Server 10 ist durch eine Netzwerkschnittstelleneinheit (nicht gezeigt) auf bekannte Weise mit einem Netzwerktor verbunden und ermöglicht es den Clients 12, auf den Scanner 16 zuzugreifen.
Unter Verwendung eines Mehrzweck-Webbrowsers wie des NETSCAPE NAVIGATOR^® oder MICROSOFT INTERNET EXPLORER^® ist es möglich, Bilddaten, die durch das Peripheriegerät 16 erzeugt werden, auf dem Client 12 darzustellen. Jedoch besteht eine Schwierigkeit, auf die man beim Verwenden von Mehrzweck-Webbrowsern stößt, in dem Erfordernis, den Webbrowser mit einer erwarteten Menge von Bilddaten zu versorgen. Insbesondere gibt der Webbrowser das Peripheriegerät 16 erst frei, wenn er die erwartete Datenmenge empfängt.
Folglich ist es notwendig zu gewährleisten, dass der Webbrowser die erwartete Datenmenge auch dann empfängt, wenn das Peripheriegerät 16 eine unzureichende Datenmenge liefert. Ferner ist es eine Verschwendung von Systemressourcen, mehr Daten zu dekomprimieren als durch den Webbrowser erwartet wird.
Unter Bezugnahme auf das in 2 veranschaulichte Flussdiagramm werden nun das Verfahren und die Vorrichtung der vorliegenden Erfindung erläutert.
Im Betrieb leitet der Client 12 eine Anforderung ein, Daten wie z.B. Bilddaten, die durch das Peripheriegerät 16 erzeugt werden, darzustellen (Schritt 100). Die Anforderung wird durch den Server 10 empfangen, der wiederum das Peripheriegerät 12 veranlasst, einen Scanvorgang einzuleiten.
Man sollte erkennen, dass der Server Daten von dem Peripheriegerät 16 allgemein in Echtzeit empfängt und dass sich zu dem Zeitpunkt, zu dem der Scanvorgang eingeleitet wird, weder der Server 10, der Webbrowser noch das Peripheriegerät 16 der wahren Gesamtgröße der Bilddaten bewusst sind. Vielmehr ist eigentlich lediglich die Menge an dekomprimierten Daten (Darstellungsgröße), die durch den Client-Webbrowser erwartet wird, bekannt. Wichtig ist, dass die durch den Scanvorgang erzeugte tatsächliche Datenmenge nicht unbedingt mit der durch den Client-Webbrowser erwarteten Darstellungsgröße korreliert.
Gemäß einem ersten Ausführungsbeispiel der Erfindung wird eine Datendekomprimierung durch den Server 10 gehandhabt. Wie oben erwähnt wurde, kennt der Server 10 nicht die Gesamtgröße der Bilddaten, die durch das Peripheriegerät 16 erzeugt werden. Um einen Datenüberfließzustand, bei dem die durch ein Peripheriegerät übertragene Datenmenge die Speicherkapazität des Servers 10 übersteigt, zu vermeiden, dekomprimiert und überträgt der Server 10 folglich vorbestimmte Blöcke von Bilddaten während des Betriebs an den Webbrowser. Mit anderen Worten versucht der Server 10 nicht, die gesamten Bilddaten zu dekomprimieren, bevor er einen Transfer von Daten an den Webbrowser einleitet. Vielmehr verarbeitet der Server 10 einzelne Blöcke einer vorbestimmten Menge komprimierter Daten bis zum Abschluss (wobei er die Daten dekomprimiert und an den Client-Webbrowser überträgt). Je nach der Auflösung und der Größe des gescannten Bildes können die Bilddaten insgesamt ohne weiteres mehrere Megabytes (MB) umfassen. Angenommen, dass eine nicht-triviale Datenmenge dekomprimiert wird, ist die in Bytes ausgedrückte Größe komprimierter Daten, die während des Betriebs verarbeitet werden, beträchtlich geringer als die Gesamtbildgröße. Insbesondere ist der Eingangspuffer gemäß einem bevorzugten Ausführungsbeispiel in der Lage, 512 Bytes zu speichern. Jedoch werden Fachleute erkennen, dass nach Bedarf ohne weiteres auch andere Pufferkapazitäten eingesetzt werden können. Die optimale Größe des Eingangspuffers kann von dem verwendeten Peripheriegerät abhängen.
Die Größe des Blocks, d.h. die angeforderte Menge komprimierter Daten, wird entsprechend dem Umfang der Bandbreite (Kommunikationsgeschwindigkeit) des Netzwerks, der Verarbeitungsgeschwindigkeit des Servers 10 und der verfügbaren Speicherressourcen des Servers optimiert. Selbstverständlich wird die Obergrenze der Blockgröße durch die Speicherkapazität des Servers 10 begrenzt. In jedem Fall ist die Blockgröße von Daten, die durch den Server 10 verarbeitet werden, nicht auf die Gesamtgröße des komprimierten Bildes bezogen, das eine unbekannte Größe aufweist. Ferner sollte man erkennen, dass sowohl ein Datentransportdurchsatz als auch eine Verringerung der Speicherressourcen durch die während des Betriebs erfolgende Datendekomprimierungsverarbeitung der vorliegenden Erfindung ermöglicht werden.
Der Server 10 speichert komprimierte Daten in einem Eingangspuffer und dekomprimiert die Daten in einen Ausgangspuffer. Zu diesem Zweck weist der Server 10 einen Eingangs puffer zum Speichern eines gegebenen Blocks komprimierter Daten zu, und weist einen Ausgangspuffer (Schritt 102) zum Speichern dekomprimierter Daten zu (Schritt 102). Man sollte beachten, dass die Größe des Eingangspuffers nicht gleich der Größe des Ausgangspuffers sein muss. Vielmehr ist der Eingangspuffer im Idealfall in der Lage, zumindest eine vorbestimmte Datenmenge zu speichern, die einer optimalen Datenübertragungsgröße entspricht. Die optimale Übertragungsgröße eines Datenpakets geht über den Schutzumfang der vorliegenden Erfindung hinaus. Überdies werden Fachleute erkennen, dass die optimale Übertragungsgröße eines Datenpakets eine Konstante ist, die beispielsweise bestimmt wird, wenn die anfängliche Netzwerkverbindung zwischen dem Webbrowser und dem Server hergestellt wird.
Nach dem Zuweisen des Ausgangspuffers fordert der Server 10 das Peripheriegerät 16 auf, eine vorbestimmte Menge komprimierter Daten zu übertragen (Schritt 104). Der Server 10 überprüft, dass ansprechend auf die Anforderung dieselben Daten empfangen wurden (Schritt 106). Angenommen, dass Daten empfangen wurden, speichert der Server 10 die Daten in dem Eingangspuffer (Schritt 108). Wie oben erwähnt wurde, entspricht die angeforderte Datenmenge einer optimalen Transfergröße. Jedoch kann die tatsächlich empfangene Datenmenge je nach der Bildgröße geringer sein als die angeforderte Menge. Die Situation, in der keine Daten empfangen werden, wird nachstehend erläutert.
Nachdem die komprimierten Daten in dem Eingangspuffer gespeichert wurden, beginnt der Server eine Dekomprimierung der Daten in den Ausgangspuffer (Schritt 110). Der Server 10 verfolgt die in dem Ausgangspuffer enthaltene Datenmenge nach und fährt fort, Daten in den Ausgangspuffer zu dekomprimieren, bis die Datenmenge entweder (a) zumindest eine verbleibende Datenmenge, die durch den Clientbrowser erwartet wird (Schritt 112) oder (b) zumindest eine vordefinierte optimale Transportgröße (Schritt 114) erreicht.
Nach einem Speichern der vordefinierten optimalen Transportgröße („Ja"-Zweig bei Schritt 114) wird der Ausgangspuffer an das Netzwerk geleitet, das die Daten an den Webbrowser überträgt (Schritt 116), woraufhin eine Zuweisung eines neuen Ausgangspuffers angefordert wird (Schritt 118).
Nach einem Sichern einer Zuweisung eines neuen Ausgangspuffers überprüft der Server, ob in dem Eingangspuffer zusätzliche komprimierte Daten gespeichert sind (Schritt 120), und fährt fort, Daten zu dekomprimieren (Schritt 110) usw.
Der Server 10 fordert periodisch den Transfer zusätzlicher Daten von dem Peripheriegerät 16 an („Nein"-Zweig bei Schritt 120). Gemäß einem Aspekt der Erfindung wird der Transfer zusätzlicher komprimierter Daten jedes Mal angefordert, wenn die in dem Eingangspuffer enthaltene Menge komprimierter Daten unter einen vorbestimmten Betrag abfällt. Gemäß einem zweiten Aspekt der Erfindung erfolgt der Transfer zusätzlicher Daten überdies gleichzeitig mit einer Dekomprimierung, d.h. einer Beseitigung, von Daten.
Der Server 10 überwacht ständig die an den Client 12 übertragene Datenmenge (amt-gesendet) sowie die verbleibende Datenmenge, die immer noch durch den Client 12 erwartet wird (amt-benötigt), wobei dieser Wert der Differenz zwischen der durch den Client erwarteten Datenmenge (Darstellungsgröße) und der übertragenen Datenmenge (amt-gesendet) entspricht. Wenn die immer noch durch den Client 12 erwartete verbleibende Datenmenge (amt-benötigt) geringer als die oder gleich der Menge dekomprimierter Daten in dem Ausgangspuffer ist, leitet der Server 10 einen Füll/Abschneidschritt ein (Schritt 122).
Bei dem Füll-/Abschneidschritt werden die in dem Ausgangspuffer enthaltenen Daten derart gefüllt/abgeschnitten, dass die in dem Puffer gespeicherte Menge gleich der verbleibenden Datenmenge ist, die noch durch den Client 12 erwartet wird (amt-benötigt). Anschließend wird der Ausgangspuffer an das Netzwerk weitergeleitet (Schritt 124), und der Eingangspuffer wird einer Zuweisung entzogen, wobei jegliche in dem Eingangspuffer verbleibende Daten verworfen werden.
Als Nächstes wird die Situation untersucht, bei der das Peripheriegerät 16 keine zusätzlichen Daten transferiert („Nein"-Zweig bei Schritt 106). Insbesondere kann die durch die Clientvorrichtung erwartete Darstellungsgröße gelegentlich die durch das Peripheriegerät 16 erzeugte Datenmenge überschreiten. Wie oben erwähnt wurde, ist diese Situation wichtig, da der Client das Peripheriegerät 16 erst freigibt, wenn die erwartete Datenmenge (Darstellungsgröße) empfangen wird. Um also mit dieser Situation umzugehen, bei der keine zusätzlichen komprimierten Daten verfügbar sind und die in dem Ausgangspuffer enthaltene Datenmenge geringer ist als die verbleibende Datenmenge, die durch den Client erwartet wird (amt-benötigt), leitet der Server wieder den Füll-/Abschneidschritt ein (Schritt 122). Diesmal werden vordefinierte Nulldaten zu dem Ausgangspuffer hinzugefügt, d.h. der Puffer wird gefüllt, derart, dass die in dem Puffer gespeicherte Menge gleich der verbleibenden Datenmenge ist, die noch durch den Client erwartet wird (amt-benötigt). Anschließend wird der Ausgangspuffer an das Netzwerk weitergeleitet (Schritt 124), und der Eingangspuffer wird einer Zuweisung entzogen, wobei jegliche in dem Eingangspuffer verbleibende Daten verworfen werden.
Gemäß einem zweiten Ausführungsbeispiel der vorliegenden Erfindung wird eine Datendekomprimierung durch eine Software/Firmware auf der Clientvorrichtung 12 gehandhabt. Insbesondere befinden sich der Eingangs- und der Ausgangspuffer sowie die Logik zum Dekomprimieren der Daten allesamt auf der Clientvorrichtung, und allgemein wird derselbe Prozess durchgeführt, der in 2 dargestellt ist. Jedoch können Kommunikationen zwischen der Clientvorrichtung 12 und dem Peripheriegerät 16 durch den Server 16 weitergeleitet werden. Im Einzelnen wandelt der Server 16 einen generischen Datenanforderungsbefehl, der durch die Clientvor richtung ausgegeben wurde, in eine vorrichtungsspezifische Form um, die durch das Peripheriegerät 16 interpretiert werden kann. Alle anderen Aspekte der Erfindung sind ähnlich den oben beschriebenen Aspekten.
Insbesondere verarbeitet der Client 12 einzelne Blöcke einer vorbestimmten Menge komprimierter Daten bis zum Abschluss, bevor er den Transfer zusätzlicher komprimierter Daten anfordert. Der Client 12 speichert komprimierte Daten in einem Eingangspuffer und dekomprimiert die Daten in einen Ausgangspuffer. Ähnlich dem ersten Ausführungsbeispiel leitet der Client 12, nachdem er den Ausgangspuffer zugewiesen hat, über den Server 10 einen Befehl an das Peripheriegerät 16 weiter, in dem er eine Übertragung einer vorbestimmten Menge komprimierter Daten anfordert (Schritt 104). Der Server überprüft, dass Daten tatsächlich innerhalb eines gegebenen Zeitraums transferiert werden (Schritt 106). Angenommen, dass Daten empfangen wurden, leitet der Server die Daten an den Client weiter, der die Daten in dem Eingangspuffer speichert (Schritt 108). Wie oben angegeben wurde, entspricht die angeforderte Datenmenge einer optimalen Transfergröße. In Abhängigkeit von der Bildgröße kann die tatsächlich empfangene Datenmenge jedoch geringer sein als die angeforderte Menge. Die Situation, in der keine Daten empfangen werden, wird auf ähnliche Weise gehandhabt, wie sie unter Bezugnahme auf das erste Ausführungsbeispiel beschrieben wurde.
Wie oben beschrieben wurde, beginnt der Client 12 eine Dekomprimierung der Daten in den Ausgangspuffer, nachdem die komprimierten Daten in dem Eingangspuffer gespeichert wurden (Schritt 110). Der Client 12 verfolgt die in dem Ausgangspuffer enthaltene Datenmenge nach und fährt fort, Daten in den Ausgangspuffer zu dekomprimieren, bis die Datenmenge entweder (a) zumindest eine verbleibende Datenmenge, die durch den Browser erwartet wird, (Schritt 112) oder (b) zumindest eine vordefinierte optimale Browsertransfergröße (Schritt 114) erreicht.
Auf ein Speichern der vordefinierten optimalen Transportgröße hin („Ja"-Zweig bei Schritt 114), wird der Ausgangspuffer an den Browser weitergeleitet (Schritt 116), woraufhin eine Zuweisung eines neuen Ausgangspuffers angefordert wird (Schritt 118).
Nach einem Sichern der Zuweisung eines neuen Ausgangspuffers überprüft der Client 12, ob in dem Eingangspuffer zusätzliche komprimierte Daten gespeichert sind (Schritt 120), und fährt fort, Daten zu dekomprimieren (Schritt 110) usw.
Periodisch leitet der Client 12 einen Befehl an den Server 10 weiter, in dem er den Transfer zusätzlicher Daten von dem Peripheriegerät 16 anfordert („Nein"-Zweig bei Schritt 120). Gemäß einem Aspekt der Erfindung wird ein Transfer zusätzlicher komprimierter Daten jedes Mal dann angefordert, wenn die in dem Eingangspuffer enthaltene Menge komprimierter Daten unter einen vorbestimmten Betrag abfällt. Überdies erfolgt der Transfer zusätzlicher Daten gemäß einem zweiten Aspekt der Erfindung gleichzeitig mit einer Dekomprimierung, d.h. einem Entfernen, von Daten.
Der Client 12 überwacht kontinuierlich die Datenmenge, die an den Browser übertragen wird (amt-gesendet) sowie die verbleibende Datenmenge, die noch durch den Browser erwartet wird (amt-benötigt), wobei dieser Wert der Differenz zwischen der durch den Client erwarteten Datenmenge (Darstellungsgröße) und der übertragenen Datenmenge (amt-gesendet) entspricht. Wenn die verbleibende Datenmenge, die noch durch den Browser erwartet wird (amt-benötigt), geringer als die oder gleich der Menge dekomprimierter Daten in dem Ausgangspuffer ist, leitet der Client 12 einen Füll/Abschneidschritt ein (Schritt 122).
Bei dem Füll-/Abschneidschritt werden die in dem Ausgangspuffer enthaltenen Daten derart gefüllt/abgeschnitten, dass die in dem Ausgangspuffer gespeicherte Menge gleich der verbleibenden Datenmenge ist, die noch durch den Browser erwartet wird (amt-benötigt). Anschließend wird der Ausgangspuffer an den Browser transferiert (Schritt 124), und der Eingangspuffer wird einer Zuweisung entzogen, wobei jegliche in dem Eingangspuffer verbleibende Daten verworfen werden.
Die Situation, bei der das Peripheriegerät 16 keine zusätzlichen Daten transferiert („Nein"-Zweig bei Schritt 106) wird auf dieselbe Weise wie bei dem vorherigen Ausführungsbeispiel gehandhabt. Insbesondere leitet der Client 12 in dem Fall, dass keine zusätzlichen komprimierten Daten verfügbar sind und die in dem Ausgangspuffer enthaltene Datenmenge geringer ist als die verbleibende Datenmenge, die durch den Browser erwartet wird (amt-benötigt), wiederum den Füll-/Abschneidschritt ein (Schritt 122). Diesmal werden vordefinierte Nulldaten zu dem Ausgangspuffer hinzugefügt, d.h. der Puffer wird gefüllt, derart, dass die in dem Ausgangspuffer gespeicherte Menge gleich der verbleibenden Datenmenge ist, die noch durch den Browser erwartet wird (amt-benötigt). Anschließend wird der Ausgangspuffer an den Browser weitergeleitet (Schritt 124), und der Eingangspuffer wird einer Zuweisung entzogen, wobei jegliche in dem Eingangspuffer verbleibende Daten verworfen werden.
Aus der vorstehenden Beschreibung sollte man verstehen, dass ein verbessertes Verfahren zum Dekomprimieren von Daten in einer Client/Server-Umgebung gezeigt und beschrieben wurde, das viele wünschenswerte Attribute und Vorteile aufweist. Die vorliegende Erfindung liefert eine schnelle, zuverlässige Herangehensweise bezüglich eines Dekomprimierens von durch ein Peripheriegerät erzeugten Daten und eines Versorgens eines Client-Webbrowsers mit einer erwarteten Menge dekomprimierter Daten. Wichtig ist, dass die vorliegende Erfindung gewährleistet, dass komprimierte Daten nicht schneller empfangen werden, als sie dekomprimiert und an den Client-Webbrowser übertragen werden können. Überdies minimiert die vorliegende Erfindung die Menge an Speicherressourcen, die erforderlich sind, um die Daten zu dekomprimieren, wobei gleichzeitig gewährleistet wird, dass die durch das Peripheriegerät bereitgestellten Daten nicht die verfügbare Speichermenge überschreiten.
Obwohl verschiedene Ausführungsbeispiele der vorliegenden Erfindung gezeigt und beschrieben wurden, sollte man verstehen, dass andere Modifikationen, Substitutionen und Alternativen für Fachleute offensichtlich sind. Derartige Modifikationen, Substitutionen und Alternativen können durchgeführt werden, ohne von dem Schutzumfang der Erfindung abzuweichen, der durch die beigefügten Patentansprüche festgelegt werden sollte.
Verschiedene Merkmale der Erfindung sind in den beigefügten Patentansprüchen dargelegt.

Claims

Ein Verfahren zum De komprimieren von Daten, die an einem Software-Darstellungsprogramm in einer Client/Server-Umgebung angezeigt werden sollen, in der eine Servervorrichtung (10) Kommunikationen zwischen zumindest einem Peripheriegerät (16) und zumindest einer Clientvorrichtung (12) weiterleitet, wobei das Software-Darstellungsprogramm eine vorbestimmte Menge, Darstellungsgröße, von dekomprimierten Daten erwartet, wobei das Verfahren zumindest entweder in Software und/oder Firmware verkörpert ist, die zumindest entweder auf der Clientvorrichtung (12) und/oder dem Server (10) ausgeführt wird, wobei das Verfahren folgende Schritte umfasst: (a) Anfordern einer ersten vorbestimmten Menge komprimierter Daten von dem zumindest einen Peripheriegerät (16); (b) Speichern der ersten vorbestimmten Menge komprimierter Daten in einem Eingangspuffer; (c) Dekomprimieren der komprimierten Daten und Speichern der dekomprimierten Daten in einem Ausgangspuffer; (d) Nachverfolgen der in dem Ausgangspuffer enthaltenen Datenmenge, amt-gespeichert; (e) Übertragen der in dem Ausgangspuffer gespeicherten Daten an das Software-Darstellungsprogramm; (f) Nachverfolgen der an das Software-Darstellungsprogramm übertragenen Datenmenge, amt-gesendet; (g) Bestimmen einer durch das Software-Darstellungsprogramm erwarteten verbleibenden Datenmenge, amt-benötigt, als amt-benötigt = (Darstellungsgröße) – (amt-gesendet)(h) Wiederholen der Schritte (a) bis (g), bis: (1) die in dem Ausgangspuffer gespeicherte Datenmenge, amt-gespeichert, zumindest gleich einer durch das Software-Darstellungsprogramm erwarteten verbleibenden Datenmenge, amt-benötigt, ist, oder (2) ansprechend auf die Anforderung bei Schritt (a) keine weiteren komprimierten Daten verfügbar sind; und (i) Einleiten einer Abschneid-/Fülloperation, so dass eine Menge dekomprimierter Daten, die gleich amt-benötigt ist, in eine Mehrzahl von Datenpaketen gepackt und an das Software-Darstellungsprogramm übertragen wird, wobei Nulldaten selektiv verwendet werden, um die dekomprimierten Daten zu ergänzen, um zu gewährleisten, dass das Software-Darstellungsprogramm eine Datenmenge empfängt, die gleich der Darstellungsgröße ist.
Ein Verfahren zum Dekomprimieren von Daten, die auf einem Software-Darstellungsprogramm angezeigt werden sollen, gemäß Anspruch 1, bei dem der Schritt des Anforderns komprimierter Daten ausgeführt wird, wenn eine in dem Eingangspuffer gespeicherte Menge kompri mierter Daten geringer ist als ein zweiter vorbestimmter Wert.
Ein Verfahren zum Dekomprimieren von Daten, die auf einem Software-Darstellungsprogramm angezeigt werden sollen, gemäß Anspruch 1, bei dem der Schritt des Übertragens des Ausgangspuffers zumindest durchgeführt wird, wenn die Menge dekomprimierter Daten in dem Ausgangspuffer, amt-gespeichert, zumindest ein dritter vorbestimmter Wert ist.
Ein Verfahren zum Dekomprimieren von Daten gemäß Anspruch 1, bei dem der Schritt des Anforderns komprimierter Daten gleichzeitig mit dem Datendekomprimierungsschritt ausgeführt wird.
Ein Server, der angepasst ist, um Kommunikationen zwischen zumindest einer Clientvorrichtung (12) und zumindest einem Peripheriegerät (16) weiterzuleiten, wobei der Server (10) angepasst ist, um komprimierte Daten von dem Peripheriegerät (16) zu empfangen, und angepasst ist, um dekomprimierte Daten an die Clientvorrichtung (12) zu übertragen, wobei der Server (10) angepasst ist, um ansprechend auf eine Daten-Darstellen-Anforderung von der Clientvorrichtung (12) eine Mehrzahl von Datenpaketen dekomprimierter Daten zu übertragen, die zusammen gleich einer vorbestimmten Menge dekomprimierter Daten, Darstellungsgröße, sind, die durch die Clientvorrichtung (12) spezifiziert ist, wobei der Server (10) folgende Merkmale aufweist: zumindest einen Eingangspuffer zum Speichern komprimierter Daten; zumindest einen Ausgangspuffer zum Speichern dekomprimierter Daten; einen Prozessor, der angepasst ist, um folgendes zu liefern: eine Datenanforderungsfunktion zum Anfordern einer Übertragung einer ersten vorbestimmten Menge komprimierter Daten von dem gemeinsam verwendeten Peripheriegerät (16); eine Datendekomprimierungsfunktion zum Dekomprimieren von Daten, die in dem zumindest einen Eingangspuffer gespeichert sind, und zum Speichern der dekomprimierten Daten in dem zumindest einen Ausgangspuffer; eine Datennachverfolgungsfunktion zum Nachverfolgen einer Menge dekomprimierter Daten, die an die Clientvorrichtung (12) übertragen werden, amt-gesendet, und Bestimmen einer verbleibenden Datenmenge, amt-benötigt, als Differenz zwischen der Darstellungsgröße und amt-gesendet; eine Datenübertragungsfunktion zum Übertragen des Ausgangspuffers an die Clientvorrichtung (12); und eine Datenfüll-1-abschneidoperation zum Füllen/Abschneiden von in dem Ausgangspuffer gespeicherten Daten.
Ein Server (10) gemäß Anspruch 5, bei dem die Datenanforderungsfunktion eingeleitet wird, wenn eine in dem Eingangspuffer gespeicherte Menge komprimierter Daten geringer ist als ein zweiter vorbestimmter Wert.
Ein Server (10) gemäß Anspruch 5, bei dem die Datenübertragungsfunktion eingeleitet wird, wenn eine in dem Ausgangspuffer enthaltene Menge dekomprimierter Daten zumindest ein dritter vorbestimmter Wert ist und wenn amt-gespeichert gleich amt-benötigt ist.
Ein Server (10) gemäß Anspruch 5, bei dem die Datenanforderungsfunktion gleichzeitig mit der Datendekomprimierungsfunktion ausgeführt wird.
Ein Server (10) gemäß Anspruch 5, bei dem die Datenfüll-/-abschneidfunktion eingeleitet wird, wenn zumindest eines der folgenden gilt: ansprechend auf eine Anforderung durch die Datenanforderungsfunktion sind keine zusätzlichen Daten verfügbar, und amt-benötigt ist geringer als amt-gespeichert; und wenn amt-gespeichert zumindest amt-benötigt ist.
Software zum, wenn sie sich an einer Clientvorrichtung (12) befindet und auf derselben ausgeführt wird, Durchführen der Schritte des selektiven Anforderns und Dekomprimierens von durch ein vernetztes Peripheriegerät (16) erzeugten Daten, wobei das Peripheriegerät (16) durch einen Server (10), der zumindest einen Eingangspuffer zum Speichern komprimierter Daten und zumindest einen Ausgangspuffer zum Speichern dekomprimierter Daten aufweist, wirksam mit der Clientvorrichtung (12) verbunden ist, wobei die Clientvorrichtung (12) einen Webbrowser zum Einleiten einer Operation des Peripheriegeräts (16) und zum Spezifizieren einer vorbestimmten Menge dekomprimierter Daten, Darstellungsgröße, umfasst, wobei die Software folgende Merkmale aufweist: eine Datenanforderungsfunktion zum Anfordern einer Übertragung einer ersten vorbestimmten Menge komprimierter Daten von dem vernetzten Peripheriegerät (16); eine Datendekomprimierungsfunktion zum Dekomprimieren von Daten, die in dem zumindest einen Eingangspuffer gespeichert sind, und zum Speichern der dekomprimierten Daten in dem zumindest einen Ausgangspuffer; eine Datennachverfolgungsfunktion zum Nachverfolgen einer Menge dekomprimierter Daten, die an die Clientvorrichtung (12) übertragen werden, amt-gesendet, und Bestimmen einer verbleibenden Datenmenge, amt-benötigt, als Differenz zwischen der Darstellungsgröße und amt-gesendet; eine Datenübertragungsfunktion zum Weiterleiten der Daten in dem Ausgangspuffer an den Webbrowser; und eine Datenfüll-/-abschneidfunktion zum Füllen/Abschneiden von in dem Ausgangspuffer gespeicherten Daten.
Software gemäß Anspruch 10, bei der die Datenanforderungsfunktion eingeleitet wird, wenn eine in dem Eingangspuffer gespeicherte Menge komprimierter Daten geringer ist als ein zweiter vorbestimmter Wert.
Software gemäß Anspruch 10, bei der die Datenübertragungsfunktion eingeleitet wird, wenn eine in dem Ausgangspuffer enthaltene Menge dekomprimierter Daten zumindest ein dritter vorbestimmter Wert ist und wenn amt-gespeichert gleich amt-benötigt ist.
Software gemäß Anspruch 10, bei der die Datenanforderungsfunktion gleichzeitig mit der Datendekomprimierungsfunktion ausgeführt wird.
Software gemäß Anspruch 10, bei der die Datenfüll/-abschneidfunktion eingeleitet wird, wenn zumindest eines der folgenden gilt: ansprechend auf eine Anforderung durch die Datenanforderungsfunktion sind keine zusätzlichen Daten verfüg bar, und amt-benötigt ist geringer als amt-gespeichert; und wenn amt-gespeichert zumindest amt-benötigt ist.