DE69904761T2

DE69904761T2 - Chipkarte mit komprimierten daten ladbar

Info

Publication number: DE69904761T2
Application number: DE69904761T
Authority: DE
Inventors: Benoit Brieussel
Original assignee: Gemplus SA
Current assignee: Gemplus SA
Priority date: 1998-12-01
Filing date: 1999-11-04
Publication date: 2003-11-13
Anticipated expiration: 2019-11-05
Also published as: CN1334948A; FR2786635A1; FR2786635B1; AU1051700A; WO2000033266A1; DE69904761D1; JP2002531974A; EP1153377B1; ES2190667T3; US7103780B1; EP1153377A1

Description

Die vorliegende Erfindung betrifft ganz allgemein die Verarbeitung von in einer Chipkarte, ebenfalls als Karte mit Mikrorechner oder Mikroprozessor (Smart Card) bezeichnet, empfangenen Daten.
Die Chipkarten verwaltenden Dienstleister verlangen eine immer größere Anzahl von Daten im in der Chipkarte enthaltenen nicht flüchtigen Speicher vom Typ EEPROM oder EEPROM Flash. Der Bedarf an Speicherkapazität in den Chipkarten tendiert ebenfalls aufgrund der Nutzung einer in die Programmiersprachen eingeschriebener Programme zum Anstieg, wie zum Beispiel die Sprache JAVA, für die Teile von Programmen, wie zum Beispiel Mikroprogramme, in die Karten zu laden sind.
Um sich eine Vorstellung zu machen, benötigt man bei einer Übertragung von 5 Kilobytes in jede der 1 Millionen Karten mit einem einzigen Terminal, das 7 Tage die Woche rund um die Uhr arbeitet und dessen Durchsatz 9600 Bit/Sekunde beträgt, über zwei Monate zum Laden dieser Daten in die Karten.
In der Funktelefontechnik wird die Chipkarte als SIM-Karte (Subscriber Identfiy Module) in die tragbaren Funktelefon-Terminals integriert. Der aktive Zustand des Funktelefon-Terminals und damit sein Stromverbrauch und seine Autonomie hängen insbesondere von der Übertragungszeit der von der SIM-Karte zu verarbeitenden Daten ab.
Ganz allgemein ist die Verkürzung der Übertragungszeit der in die Chipkarten zu ladenden Daten ein unbestrittener Gewinn sowohl gegenüber dem die Daten in die Chipkarte ladenden Terminal als auch gegenüber der Karte selbst und dem oder den die zu ladenden Daten übertragenden Übertragungsträger oder -kanal/-kanälen.
Im Übrigen schlägt der am 24. Februar 1995 unter der Nr. 7-60087 eingereichte und unter der Nr. 8-235329 veröffentlichte japanische Patentantrag vor, komprimierte Daten in eine Speicherkarte zu laden, das heißt, in eine "statische" Karte, die die Daten, die sie erhält, nicht verarbeitet, und die im Verhältnis zu einer Bildverarbeitungseinheit, die die komprimierten Daten produziert hat, als deportierter Speicher fungiert. Die Bildverarbeitungseinheit schreibt an zwei erste in der Speicherkarte vorbestimmte Adressen jeweils die Länge der Daten vor dem Komprimieren und schreibt dann die komprimierten Daten in die Speicherkarte. Umgekehrt liest die Bildverarbeitungseinheit bei Laden der komprimierten Daten von der Speicherkarte in die Bildverarbeitungseinheit die Länge der Daten vor dem Komprimieren und die Länge der Daten nach dem Komprimieren an die jeweiligen zwei vorbestimmten Adressen, und liest dann die komprimierten Daten, so dass sie gemäß eines vorbestimmten, in der Bildverarbeitungseinheit installierten Dekomprimierungs- Algorithmus dekomprimiert werden.
Andere Dokumente, wie zum Beispiel die französischen Patentanträge 2 730 330 oder 2 759 795 betreffen die Datenkomprimierung in einer Chipkarte, jedoch ohne deshalb die Art und Weise zu offenbaren, auf die das Komprimieren oder das Dekomprimieren der Daten in der Karte erfolgt.
Aufgabe der Erfindung ist die Verkürzung der Zeit der Datenübertragung in Chipkarten, das heißt, Karten mit Mikrorechner oder Mikroprozessor, durch das Laden von komprimierten Daten darin bei gleichzeitiger Aufrechterhaltung der Funktionen der Chipkarten hinsichtlich der Verarbeitung von nicht komprimierten Daten.
Zu diesem Zweck wird eine zur Aufnahme von komprimierten Datenfeldern geeignete Chipkarte, von denen jedem eine erwartete Längenangabe dekomprimierter Daten und eine Länge komprimierter Daten voransteht, dadurch gekennzeichnet, dass sie in Abhängigkeit der jeweiligen Längen der komprimierten Daten ein erstes Mittel zur Speicherung der von komprimierten Daten empfangenen Zonen enthält, ein zweites Mittel zur Speicherung eines Dekomprimierungs-Algorithmus, ein Mittel zum Dekomprimieren der komprimierten Daten in jeder Zone in dekomprimierte Daten gemäß des besagten Dekomprimierungs- Algorithmus auf eine von der erwarteten Längenangabe dekomprimierter. Daten abhängigen Länge, und ein drittes Mittel zum Speichern der dekomprimierten Daten.
Dank des Empfangs von Daten im komprimierten Zustand in den erfindungsgemäßen Chipkarten wird die Ladedauer der 5 Kilobytes in eine Million dieser Karten gemäß des vorgenannten Beispiels um 10% bis 40%, im typischen Fall um 20%, verringert, was einen Gewinn von ungefähr zwei Wochen bedeutet.
Das zweite Mittel zum Speichern beinhaltet bevorzugt mehrere Dekomprimierungs-Algorithmen, und das Mittel zum Dekomprimieren stellt eine Dekomprimierungs- Algorithmus-Nummer, das jeder Zone empfangener komprimierter Daten voransteht, damit diese gemäß eines Dekomprimierungs-Algorithmus dekomprimiert werden, dessen Nummer festgestellt wurde. Als Variante kann das zweite Mittel zum Speichern mehrere, jeweils den Dekomprimierungs-Algorithmen zugeordnete Dekomprimierungs- Modelle umfassen, und das Mittel zum Dekomprimieren stellt eine jeder empfangenen Zone komprimierter Daten voranstehende Dekomprimierungs-Modell-Nummer fest, damit diese Daten gemäß eines Dekomprimierungs-Algorithmus und des entsprechenden Dekomprimierungs-modelle dekomprimiert werden, deren Nummern festgestellt wurden. Die verschiedenen, im Speicher der Karte installierten Dekomprimierungs-Algorithmen und Dekomprimierungs-Modelle erlauben den Einsatz der Karte bei jedem beliebigen Dienstleister, der Daten gemäß eines der Algorithmen und eines der Modelle komprimierenden Terminals oder Server verwaltet.
Gemäß eines anderen erfindungsgemäßen Merkmals umfasst die Chipkarte ein viertes Mittel zum Speichern eines vor einer empfangenen Zone komprimierter Daten empfangenen Dekomprimierungs-Modells, und das Modell zum Dekomprimieren stellt eine der besagten Zone empfangener komprimierter Daten voranstehende Algorithmus- Dekomprimierungs-Nummer fest, damit diese Daten gemäß eines Dekomprimierungs-Algorithmus, dessen Nummer festgestellt wurde, und dem im vierten Mittel zum Speichern gelesenen Dekomprimierungs-Modell dekomprimiert werden.
Gemäß einer anderen Möglichkeit wird das Dekomprimierungs-Modell im RAM-Speicher der Karte rekonstruiert; in diesem Fall speichert das vierte Modell zum Speichern ein implizit von einer Zone komprimierter Daten im Verlauf des Einschreibens in die ersten Mittel zum Speichern abgeleitetes Dekomprimierungs-Modell, und das Mittel zum Dekomprimieren stellt eine der besagten gespeicherten Zone komprimierter Daten voranstehende Dekomprimierungs-Algorithmus-Nummer fest, damit diese Daten gemäß eines Dekomprimierungs-Algorithmus, dessen Nummer festgestellt wurde, und des im vierten Mittel zum Speichern abgeleiteten gelesenen Dekomprimierungs- Modells dekomprimiert werden.
Das Mittel zum Dekomprimieren kann eine Angabe über den komprimierten oder nicht komprimierten Zustand jeder empfangenen Zone komprimierter Daten feststellen, damit das Mittel zum Dekomprimieren die Daten nur in den Datenzonen komprimiert, denen eine Angabe zu einem komprimierten Zustand voransteht
Die Erfindung betrifft ebenfalls eine Protokolldateneinheit zur Aufnahme insbesondere durch die erfindungsgemäße Chipkarte. Die Einheit umfasst eine Kopfzeile und eine Datenzone, wobei die Kopfzeile die Länge der Datenzone beinhaltet, und ist dadurch gekennzeichnet, dass die Kopfzeile eine Angabe über die erwartete Länge dekomprimierter Daten nach dem Dekomprimieren der Datenzone umfasst. Dieses Merkmal trägt zum präzisen Dekomprimieren bei, unabhängig vom ausgewählten Dekomprimierungs-Algorithmus.
Die Angabe über die erwartete Länge dekomprimierter Daten ist ein Wort mit n Bits gleich der erwarteten Länge der dekomprimierten Daten Modulo 2n, wobei die erwartete Länge in Worten dekomprimierter Daten mit m Bits ausgedrückt wird. Die ganze Zahl n ist wenigstens gleich 0, zum Beispiel gleich 2, 3 oder 4 Bits, je nach der Aufteilung der Dekomprimierungs-Parameter in einer Zone der Protokolleinheit. Die ganze Zahl m ist wenigstens gleich 1, zum Beispiel gleich 8, bei Worten, die gleich einem Byte sind.
Wenn die Karte für mehrere Dienstleister gilt, umfasst die Kopfzeile die Nummer eines Dekomprimierungs-Algorithmus, mit dessen Hilfe die komprimierten Daten in der Datenzone zu dekomprimieren sind, und kann die Nummer eines Dekomprimierungs-Modells umfassen, die dem Dekomprimierungs-Algorithmus entspricht, dessen Nummer in der Kopfzeile inbegriffen ist und mit dessen Hilfe die komprimierten Daten in der Datenzone zu dekomprimieren sind.
Die Karte kann komprimierte Daten und nicht komprimierte Daten aufnehmen.
Zu diesem Zweck umfasst die Kopfzeile eine Angabe über den Datenzustand mit einem ersten Zustand, wenn die Daten in der Datenzone nicht komprimiert sind, und mit einem zweiten Zustand, wenn die Daten in der Datenzone komprimiert sind. Die Angabe über den Datenzustand kann einen dritten Zustand haben, wenn die Daten in der Datenzone gemäß eines vorbestimmten Dekomprimierungs- Algorithmus und eines vorbestimmten Dekomprimierungs- Modells zu dekomprimieren sind, die voreingestellt in der Karte ausgewählt sein können; die Angabe über die erwartete Länge dekomprimierter Daten ist dann nicht immer zum Dekomprimieren notwendig und braucht nicht in der Protokolldateneinheit vorhanden zu sein. Im gegenteiligen Fall umfasst die Kopfzeile die Nummer eines Dekomprimierungs-Algorithmus, die Nummer eines Dekomprimierungs-Modells und die Angabe über die erwartete Länge dekomprimierter Daten, wenn die Angabe über den Datenzustand im zweiten Zustand ist.
Schließlich betrifft die Erfindung ebenfalls ein Verfahren zum Dekomprimieren von Zonen komprimierter Daten, das insbesondere in der erfindungsgemäßen Chipkarte umgesetzt wird. Jeder Zone komprimierter Daten steht eine Angabe über die Länge nicht komprimierter Daten voran, die in der Zone enthaltenen komprimierten Daten entspricht, und einer Länge der in der Zone enthaltenen komprimierten Daten. Das Verfahren wird durch die folgenden Schritte gekennzeichnet:
- Feststellen der Länge der komprimierten Daten und Speichern der Zone komprimierter Daten über die festgestellte Länge, und
- Feststellen der Angabe über die erwartete Länge dekomprimierter Daten und Dekomprimieren der Daten, so dass das Dekomprimieren in Abhängigkeit von der festgestellten Angabe beendet wird.
Das Verfahren kann in Abhängigkeit einer der Zone komprimierter Daten voranstehenden Algorithmus-Nummer bei einer Anwendung für mehrere Dienstleister zum Dekomprimieren der Daten der Zone gemäß des ausgewählten Dekomprimierungs-Algorithmus einen Schritt zur Auswahl eines Dekomprimierungs-Algorithmus aus mehreren Dekomprimierungs-Algorithmens umfassen, und gegebenenfalls einen Schritt zur Auswahl eines Dekomprimierungs- Modells aus verschiedenen, dem ausgewählten Dekomprimierungs-Algorithmus in Abhängigkeit einer der Zone komprimierter Daten voranstehenden Modell-Nummer zugeordneten Dekomprimierungs- Modellen, um die Daten der Zone gemäß des ausgewählten Dekomprimierungs-Algorithmus und des ausgewählten Dekomprimierungs-Modells zu dekomprimieren.
Anstelle des Schrittes zur Auswahl eines Dekomprimierungs-Modells kann das Verfahren einen Schritt zum Speichern eines zuvor in der Zone komprimierter Daten empfangenen Dekomprimierungs-Modells umfassen, um die Daten der Zone gemäß des ausgewählten Dekomprimierungs-Algorithmus und des gespeicherten Dekomprimierungs-Modells zu dekomprimieren, oder einen Schritt zum Speichern eines implizit von der empfangenen Zone komprimierter Daten abgeleiteten Dekomprimierungs-Modells, um die Daten der Zone gemäß des ausgewählten Dekomprimierungs-Algorithmus und des abgeleiteten und gespeicherten Dekomprimierungs-Modells zu dekomprimieren.
Das Verfahren kann weiterhin einen Schritt zum Feststellen einer Angabe über den jeder Zone komprimierter Daten voranstehenden Datenzustand umfassen, um die Daten der Zone nur zu dekomprimieren, wenn die Angabe über den Datenzustand nicht ein erster vorbestimmter Schritt ist.
Der Schritt zum Feststellen einer Angabe über die erwartete Länge dekomprimierter Daten wird bevorzugt nicht ausgeführt, wenn die Angabe über den Datenzustand sich in einem vorbestimmten Zustand befindet, der angibt, dass die komprimierten Daten gemäß vorbestimmten, in der Karte voreingestellt ausgewählten Algorithmen und Modellen zu dekomprimieren sind.
Weitere Merkmale und Vorteile der vorliegenden Erfindung werden beim Lesen der nachfolgenden Beschreibung mehrerer bevorzugter Ausführungsarten der Erfindung unter Bezugnahme der entsprechenden beigefügten Zeichnungen deutlicher, in denen:
- Fig. 1 ein Blockdiagramm eines Übertragungssystems zwischen einer erfindungsgemäßen Chipkarte und einem Terminal zum Komprimieren von Daten gemäß einer ersten Ausführungsart ist;
- Fig. 2 ein Blockdiagramm eines Funktelefonsystems zwischen einer erfindungsgemäßen Chipkarte und einem Server zum Komprimieren von Daten gemäß einer zweiten Ausführungsart ist;
- Fig. 3 ein ein erfindungsgemäßes Raster komprimierter Daten darstellendes Diagramm ist;
- Fig. 4 ein Diagramm einer im Raster der Fig. 3 inbegriffenen Zone von Dekomprimierungs-Parametern ist;
- Fig. 5 ein Algorithmus eines erfindungsgemäßen Verfahrens zum Komprimieren von Daten ist; und
- Fig. 6 ein Algorithmus eines erfindungsgemäßen Verfahrens zum Dekompromieren von Daten ist,
Gemäß einer ersten in Fig. 1 gezeigten Ausführungsart umfasst ein Terminal mit Kartenlesegerät TE einen Datenkomprimierer COM zum Komprimieren der Daten, die er intern verarbeitet hat, unabhängig davon, ob das Terminal autonom ist oder nicht, oder die er von einer Übertragungsleitung empfangen hat, zum Beispiel einer von einer Kleinzentrale mit automatischer Vermittelung CO des geschalteten Telefonnetzes RTC oder einem digitalen Netz mit Leistungsintegration RNIS versorgten Teilnehmertelefonleitung LT. Die komprimierten Daten werden vom Terminal auf eine Chipkarte CA über einen Übertragungsträger ST vom Typ Drahtübertragungsleitung oder funkelektrischer Übertragungsleitung oder Übertragung vom Typ elektrischer, magnetischer oder zum Beispiel induktiver Kontakte in erfindungsgemäße Raster TR übertragen. Die Chipkarte dekomprimiert die in den empfangenen Rastern TR enthaltenen komprimierten Daten.
Schematisch dargestellt umfasst die Chipkarte einen Speicher RAM MC zum Speichern der empfangenen Raster mit komprimierten oder nicht komprimierten Daten, ein Speicher RAM MD zum Speichern der dekomprimierten Daten, einen Betriebssystem OS (Operating System) der Karte und die spezifischen, insbesondere erfindungsgemäßen Anwendungen enthaltenden Speicher ROM MS, einen Speicher EEPROM ME zum Speichern insbesondere der Übertragungs-/Empfangs-Protokolle von Daten, der vertraulichen Informationen und der dekomprimierten und nicht komprimierten Daten, und einen durch einen Bus B an die Speicher angeschlossenen Mikroprozessor PR.
Gemäß einer zweiten, in Fig. 2 dargestellten Ausführungsart ist das Kartenterminal ein mobiles Funktelefonterminal TM in einem Zellfunktelefonnetz RT, zum Beispiel vom Typ GSM 900 oder DCS 1800. Die Speicherkarte ist eine SIM-Karte, das heißt, ein Abonnenten- Identifikationsmodul (Subscriber Identify Module) mit einer zur in Fig. 2 dargestellten und erfindungsgemäß deutlich veränderten und vervollständigten Karte CA analogen Architektur. Um das mobile Terminal TM nicht mit Programmen zu überladen, komprimiert dieses die Daten nicht, die es empfängt, um sie an die SIM-Karte zu übertragen, sondern empfängt diese Daten bereits komprimiert über den ab der entsprechenden Basisstation BTS zugeordneten Verkehrskanal.
In dem in der Fig. 2 gezeigten Netz RT sind nur die Haupteinheiten dargestellt, über die die für die SIM-Karte bestimmten Daten wandern. Diese Einheiten sind ein Schalter des mobilen Service MSC, der an wenigstens einen Telefonschalter mit Leitwegautonomie CO des Telefonwählnetzes RTC angeschlossen ist und der die Kommunikation für die mobilen Besucherterminals verwaltet, zu denen auch das Terminal gehört, die sich zu einem bestimmten Zeitpunkt in einem jeweiligen Lokalisierungsbereich befinden; ein an den Schalter MSC angeschlossenes und Merkmale mobiler Terminals enthaltendes Registriergerät zur Lokalisierung von Besuchern VLR, das heißt SIM-Karten, in diesem Bereich zur Lokalisierung; ein insbesondere die Zuordnung von Kanälen zu mobilen Terminals, die Leistung der Basisstation(en) und die Transfers zwischen den Zellen von mobilen Stationen verwaltendes Kontrollgerät für die Basisstation; und die die funkelektrische Zelle abdeckende Basisstation BTS, in der sich das Terminal TM zu einem bestimmten Zeitpunkt befindet.
In dieser zweiten Ausführungsart ist der Datenkomprimierer COM in einen Komprimierungs-Server SC integriert, der über eine klassische Schnittstelle RNIS an den Schalter des mobilen Service MSC angeschlossen ist, zum Beispiel vom Typ T2 zu 2048 Kilobits/Sekunde mit 30 Informationskanälen B und 1 Kanal D zu 64 Kilobit/Sekunde. Alle eingehenden zu komprimierenden, für mobile Terminals bestimmte sich in dem besagten Bereich zur Lokalisation für beliebige Kommunikationen mit den festen Terminals des Netzes RTC oder den mobilen Terminals des Funktelefonnetzes RT, befindenden Daten oder die mobilen Terminals des Funktelefonnetzes RT werden im Server SC vor dem Übergang in das Kontrollgerät BSC, die Basisstation BTS und das entsprechende mobile Terminal TM komprimiert werden.
Als Variante wird der Server SC nicht an den mobilen Serviceschalter MSC angeschlossen, sondern wird von Servern mit direkt an die vom Schalter MSC bedienten Kontrollgeräte der Basisstation BSC angeschlossene Komprimierern ersetzt.
Unter Bezugnahme auf die Fig. 3 und 4 weist eine Datenprotokolleinheit in Form eines Rasters von ab dem Terminal TE, TM zur Karte CA, SIM durch den Übertragungsträger ST oder ab dem Komprimierungs-Server SC insbesondere über das Termin TM gemäß Fig. 2 zu übertragenden komprimierten Daten TR nunmehr eine Struktur mit einer Kopfzeile ET und einer Datenzone DATA auf. Das Raster TR wird deutlich im Verhältnis zu einem genormten Raster eingehender Daten gemäß des asynchronen Übertragungsprotokolls Zeichen für Zeichen "T = 0" verändert. Anstatt fünf Bytes umfasst die Kopfzeile ET des Rasters TR fünf Bytes CLA, INS, P1, P2 und LC, wie in einem Raster "T = 0" und ein erfindungsgemäße Dekomprimierungs-Parameter enthaltendes, in der Datenzone "entnommenes" sechstes Byte PD. Diese sechs Bytes befinden sich im Hexadezimalcode.
Wie im Raster "T = 0" bezeichnet das Byte CLA eine Klasse des im folgenden Byte enthaltenen Befehls, das Byte INS einen mit einem Befehl des Betriebssystems OS (Operating System) der Chipkarte CA, SIM verbundenen Befehl oder zum Beispiel mit der Sicherheit der Daten verbundenen Befehl, die Bytes P1 und P2 der Parameter des Befehls, und das Byte LC die Länge der Datenzone im Raster "T = 0", ausgedrückt in Bytes und bei den meisten erfindungsgemäßen Rastern mit komprimierten Daten, gleich der Länge der Zone DATA des Rasters TR zuzüglich 1 (aufgrund des Bytes PD).
Erfindungsgemäß enthält das Raster TR zwei Bits zur Anzeige des Datenzustandes B2 und B3, das zweite und dritte Byte CLA, die im Komprimierer COM des Terminals TE oder des Servers SC produziert werden, um hauptsächlich den komprimierten oder nicht komprimierten Zustand der Daten in der Zone DATA anzuzeigen. Die Bits zur Anzeige des Datenzustandes B2 und B3 sind jeweils die nachfolgenden binären Zustände:
- "00" wenn die Daten nicht komprimiert empfangen werden, wobei das Raster dann ein Raster "T = 0" mit dem Byte PD als Datenbyte ist;
- "10", wenn die Daten komprimiert empfangen werden und in der Karte gemäß dem vorbestimmten Algorithmus AL0 und dem vorbestimmten Dekomprimierungs-Modell M00 zu dekomprimieren sind, die die gebräuchlichsten, in der Chipkarte CA, SIM voreingestellt sind, wobei das Raster TR dann ein Raster "T = 0" ist, wenn die Länge der dekomprimierten Daten zum Dekomprimieren nicht notwendig ist; und
- "11", wenn die Daten komprimiert empfangen werden und in der Karte gemäß eines ausgewählten ALi mehrerer Dekomprimierungsalgorithmen und eines ausgewählten Mij mehrerer an den ausgewählten Algorithmus ALi, die Dekomprimierungs-Algorithmen und -Modelle ALi und Mij angepasste Dekomprimierungs-Modelle, die den im Terminal TE oder dem Server SC zum anfänglichen Komprimieren in den Daten verwendeten Kompressions-Algorithmen und - Modellen "ALi" und "Mij" entsprechen, zu dekomprimieren sind.
Somit enthält der Speicher ROM MS der Chipkarte, die hauptsächlich das Betriebssystem OS der Karte enthält, ebenfalls mehrere Anwendungen für Dekomprimierungs-Algorithmen AL0 bis ALI mit dem zwischen 0 und einer ganzen Zahl I inbegriffenen - im typischen Fall höchstens gleich 3 -Index 1, wobei jeder Algorithmus ALi mehreren Kompressions-Modellen, jeweils Mi0 bis MiJ mit dem zwischen 0 und einer ganzen Zahl J, typischerweise höchstens gleich 7 inbegriffenen Index J zugeordnet wird. Ein Dekomprimierungs-Modell gewährleistet dank des Dekomprimierungs-Algorithmus, der dies umsetzt, die Entsprechung zwischen den komprimierten Symbolen und den nicht komprimierten Symbolen; zum Beispiel basiert ein Modell auf einem Baum, einer Wahrscheinlichkeitstafel, einem Wörterbuch oder einer Liste. Die zum Dekomprimieren der Daten DATA dienende Identifizierung des Algorithmus ALi und zur Identifizierung des Modells Mij werden der Karte CA, SIM jeweils durch ein Wort mit 2 Bits und ein Wort mit 3 Bits zu Beginn des Dekomprimierungs-Parameterbytes PD angezeigt, wie in Fig. 4 dargestellt, wenn die Bits B2 und B3 in der Klassenzone CLA "11" sind. Die Karte CA, SIM der Erfindung wird somit an verschiedene Dekomprimierungs-Algorithmen angepasst, die jeweils durch verschiedene, für die Verwaltung der Terminalaufbaus TE oder die Terminalaufbaus TM mit Servern SC verantwortlichen Dienstleister ausgewählt werden.
Als Variante umfasst die Chipkarte CA (Fig. 1), SIM noch einen mit dem Bus B verbundenen Speicher RAM mm. In eintretende, den Rastern TR mit komprimierten Daten gemäß diesem Modell voranstehende Auftragsraster (nicht dargestellt) inbegriffene. Merkmale eines Dekomprimierungs-Modells werden durch das Terminal TE oder den Server SC über den Träger ST übertragen und werden in den Speicher mm durch den Prozessor PR eingeschrieben. Der dieses in den Speicher mm eingeschriebene Modell umsetzende Algorithmus wird dann im Speicher MS vom Prozessor zwecks Dekomprimieren der Daten gesucht.
Gemäß einer anderen Variante werden von den Algorithmen AL0 bis ALI einige Dekomprimierungs-Modellen zugeordnet, deren Merkmale nicht zuvor im Speicher ROM MS der Karte CA, SIM gespeichert werden. Ein derartiges Dekomprimierungs-Modell wird mittels des entsprechenden Dekomprimierungs-Algorithmus im Prozessor PR im Verlauf des Schreibens des Rasters der komprimierten Daten im Speicher MC wieder aufgebaut und wird in den Speicher RAM mm eingeschrieben, um ihn bei der Dekomprimierung der komprimierten Daten zu lesen. Das Dekomprimierungs- Modell ist gemäß dieser Variante implizit im Raster komprimierter Daten enthalten.
Der Parameter-Dekomprimierungsbereich PD in einem Raster dekomprimierter Daten enthält ein letztes Wort mit n Bits LDD, das der Karte CA, SIM die erwartete Länge der dekomprimierten Daten Modulo 2n anzeigt, wobei n eine ganze Zahl größer oder gleich 2 ist. Die anfänglich nicht komprimierten Daten im Terminal TE oder dem Server SC, denen die komprimierten Daten in der Karte CA, SIM entsprechen, werden in Daten-Wörtern mit m Bits verarbeitet, wobei m eine ganze Zahl größer als oder gleich 1 ist. Die erwartete Länge der Daten wird in Daten-Wörtern mit m Bits ausgedrückt, und das Wort LDD gibt die Anzahl der Daten-Wörter in der letzten Zone mit höchstens 2n Daten-Worten in dem Raster an, die komprimiert wurden. Gemäß der in Fig. 4 dargestellten Ausführungsart ist die ganze Zahl n gleich 3, im Allgemeinen größer als oder gleich 0, die Wörter mit m Bits sind Bytes dekomprimierter Daten mit m = 8, und das Wort der erwarteten Länge der dekomprimierten Daten LDD enthält 3 Bits und ist gleich dem Rest der Division der erwarteten Länge dekomprimierter Daten durch 2n = 8.
Dank des Längenparameters dekomprimierter Daten LDD beendet der Prozessor PR in der Chipkarte CA, SIM das Dekomprimieren der Daten genau am Ende der zu dekomprimierenden empfangenen Daten. Gemäß bestimmten Dekomprimierungs-Algorithmen, wie zum Beispiel ein Algorithmus vom Typ Huffman, können zum Beispiel mehrere Symbole auf einem Wort mit m Bits kodiert werden, im vorliegenden Fall ein Byte mit m = 8. Das Dekomprimieren der Symbole muss am Ende des dekomprimierten Rasters aufhören, das als erstes Symbol zu Beginn des letzten Bytes auftreten kann; die auf das Ende dieses Bytes folgenden Bits sind keine Daten, sondern Füllbits, die in die Karte eingeführt werden, nachdem die Anzahl der Bits der dekomprimierten Daten präzise gemäß der vom Parameter LDD parallel zur Länge der komprimierten Daten LC angegebenen Präzision gezählt worden sind.
Gemäß einer anderen Variante kann die Präzision der Länge der dekomprimierten Daten das Bit erreichen, wenn m = 1 ist; zum Beispiel zeigt der Parameter LDD bei n = 8 die Anzahl von im letzten, im Raster inbegriffenen Byte erwarteten Datenbits an.
Der Parameter LDD ist ebenfalls nützlich, wenn mehrere Raster "T = 0" sind oder genormte Raster gemäß des asynchronen Übertragungsprotokolls Block für Block "T = 1", als applikative Protokolldateneinheiten APDU bezeichnete, eintretende Daten verkettet werden müssen, um eine Datei zu bilden. Der Anfang eines Rasters muss präzise auf das Ende des vorherigen Rasters folgen, das heißt, auf das letzte Byte dekomprimierter Daten. Diese Datei-Segmentierung beim letzten Byte des vorherigen Rasters wird genau vom Parameter LDD signalisiert.
Anstatt die erwartete Länge vom Rest der Division durch 2n anzugeben, könnte sie vollständig in die Kopfzeile des erfindungsgemäßen Rasters TR eingeführt werden. Diese Einführung würde jedoch ein zusätzliches Wort in die Kopfzeile ET des Rasters TR hinzufügen, wobei die erwartete Länge dann größer als 2&sup8; = 256 Bytes sein könnte. Darüber hinaus wäre ein drittes Bit in der Klassenzone CLA zum Deklinieren aller Fälle notwendig.
Ein mit der Erfindung konformes Komprimierungsverfahren wird in Fig. 5 gezeigt. Es umfasst hauptsächlich 5 im Terminal TE oder dem Server SC realisierte Schritte C0 bis C4.
Wenn in Abhängigkeit von Protokollbefehlen im Schritt C0 die in das Terminal T oder den Server SC eintretenden Daten nicht komprimiert werden, werden die Bits B2 und B3 in einem auf einen Anfangsschritt C0 folgenden Schritt C30 in den Zustand "00" gesetzt.
Wenn die eintretenden Daten im Schritt C0 komprimiert werden müssen, komprimiert das Terminal TE oder der Server SC die im folgenden Schritt C1 eintretenden Daten gemäß eines im Terminal TE oder dem Server SC vorinstallierten Komprimierungs-Algorithmus "ALi" und eines entsprechenden Dekomprimierungs-Modells "MiJ". Wenn der Algorithmus "ALi" und das Modell "Mij" der vorbestimmte Komprimierungs-Algorithmus "A10" und das vorbestimmte Komprimierungs-Modell "M00" sind und wenn das Dekomprimieren im Schritt C21 nicht die Kenntnis der Angabe über die Länge dekomprimierter Daten LDD im Speicher erfordert, soweit das Komprimieren bei einer ganzen Zahl Datenwörter mit n Bits stehen geblieben ist, werden die Bits B2 und B3 jeweils in den Zustand "10" des Schritts C31 gesetzt. In den den Schritten C2 und C21 entgegengesetzten Fällen ist der Parameter LDD notwendig, und die Bits B2 und B3 werden im Schritt C32 in den Zustand "11" versetzt. Der Dekomprimierungs- Parameterbereich PD wird mit der Nummer ALi und Mij der Algorithmen und dem Modell gebildet, die zum Komprimieren der Daten gedient haben, und mit der erwarteten Länge der Daten vor dem Komprimieren, Modulo 2n.
Anschließend wird im nächsten Schritt C4, unabhängig davon, ob die Daten komprimiert oder nicht komprimiert sind, das zu übertragende Raster TR endgültig gebildet. Als Option wird das gesamte Raster oder nur die Datenzone DATA in einem Schritt C5 beziffert.
Wie in Fig. 6 dargestellt, umfasst das Dekomprimieren von Daten in der Karte PC, SIM neun Schritte D0 bis D10. Im Anfangsschritt D0 wird das gemäß einer asynchronen Übertragung empfangene Raster in den Pufferspeicher RAM MC in die Karte eingeschrieben. Wenn die Raster TR oder die in diesem Raster enthaltenen Daten DATA im Terminal TE oder im Server SC chiffriert sind, führt der Prozessor PR der Karte als Option ein Dechiffrieren jedes empfangenen und in den Pufferspeicher RAM im Schritt D1 eingeschriebenen Rasters durch. Anschließend bestätigt der Prozessor PR in Schritt D2 das empfangene Raster TR als genormtes Raster, wenn das Bit einer hochwertigen Stelle B1 in der Klassenzone CLS sich im Zustand "1" befindet; wenn das Raster mit B1 = "0" empfangen wird, geht das Verfahren sonst vom Schritt D2 zum Schritt D10 über. Die Länge der in der Zone LC im Schritt D3 gelesenen Datenzone DATA legt den Stopp des Schreibens der Daten im Speicher MC fest.
Im folgenden Schritt D4 werden die zweiten und dritten Bits B2 und B3 in der. Zone CLA des empfangenen Rasters TR gelesen. Wenn diese beiden Bits wie im Schritt D50 gezeigt gleich "00" sind, wird kein Dekomprimieren von Daten ausgeführt, und das Verfahren geht direkt zum letzten Schritt D10 über. Im gegenteiligen Fall müssen die Daten DATA dekomprimiert werden und das Verfahren geht in den Schritt D51 über, um die Raster mit und ohne Dekomprimierungs-Parameterzone PD zu unterscheiden.
Wenn die Bits B2 und B3 im Schritt D51 nicht jeweils gleich "11" sind, sind sie im Schritt D52 gleich "10". Das Betriebssystem OS wählt automatisch die vorbestimmten Dekomprimierungs-Algorithmen und -Modelle AL0 und M00 im Speicher MS im Schritt D60 aus, führt dann das Dekomprimieren der Daten DATA durch und schreibt im Schritt D9 die dekomprimierten Daten in den Speicher MD ein. Das Ende des Dekomprimierens wird in Abhängigkeit der Länge LC der Zone DATA geschätzt.
Wenn die Bits B2 und B3 im Schritt D51 jeweils "11" sind, wählt das Betriebssystem OS den Dekomprimierungs-Algorithmus und das Dekomprimierungs-Modell aus. Der von den zwei im empfangenen Raster TR enthaltenen ersten Bits der Parameter-Dekomprimierungszone PD angezeigte Dekomprimierungs-Algorithmus ALi wird im Speicher ROM MS der Karte im Schritt D6 ausgewählt. Das entsprechende Dekomprimierungs-Modell Mij wird im Speicher RAM mm in den Schritten D7 und D71 gelesen, wenn Merkmale des Modells Mij vor dem Empfang des Rasters TR oder empfangen oder implizit zu Beginn des Empfangs des Rasters TR abgeleitet werden. Im gegenteiligen Fall werden die drei Modellbits in der Zone PD des empfangenen Rasters gelesen, um das Modell Mij im Speicher ROM MS in den Schritten D7 und D72 auszuwählen. Nach dem Schritt D71 oder D72 wird dann das Wort LDD mit am Ende der Parameter-Dekomprimierungszone PD inbegriffenen n Bits im Schritt D8 durch das Betriebssystem OS gelesen, damit der Prozessor PR im Schritt D9 das Dekomprimieren der in der Zone DATA des empfangenen Rasters TR enthaltenen Daten ausführt und dieses Dekomprimieren in Abhängigkeit insbesondere vom zuvor gelesenen Wort LDD beendet. Die dekomprimierten Daten werden nach und nach in den Speicher RAM MD eingeschrieben.
In Abhängigkeit des in der Zone INS enthaltenen Befehls und der diesen Befehl im empfangenen Raster TR präzisierenden Parameter P2, P2 führt das Betriebssystem OS im Schritt D10 einen festgelegten Befehl aus, wie zum Beispiel das erneute Kopieren der im Speicher MD im Speicher EEPROM der Karte enthaltenen dekomprimierten Daten an eine vorgegebene Adressdatei. In diesem Stadium befindet sich das Betriebssystem in der Karte wieder genau in der Situation, die es in einer genormten Karte wiederfinden würde, wenn die empfangenen Daten nicht erfindungsgemäß komprimiert worden wären.
Beispielhaft ist die in einem Raster komprimierter Daten TR enthaltene Kopfzeile ET folgende:
CL = "E8"; INS = "D0"; P1 = "03"; P2 = "20"; LC = "23" und PD = "B6",
wobei alle diese Bytes ein hexadezimaler Code sind.
In diesem Beispiel ist die erste Hälfte der Zone CLA gleich "1110", das heißt B2 = "1" und B3 = "1"; was bedeutet, dass die Daten DATA mit einem anderen Algorithmus und einem anderen Modell als dem Algorithmus "AL0" und dem Modell "M00" komprimiert worden sind. Gemäß der Zone LC erstrecken sich die Daten DATA nach dem Komprimieren auf (16 · 2 + 3) = 35 Bytes. Das Dekomprimieren wird gemäß des Algorithmus AL2 und des entsprechenden Modells M26 durchgeführt, dessen Nummern in den fünf ersten Bits "10110" der Parameter- Dekomprimierungszone PD gelesen werden. Die erwartete Länge der dekomprimierten Daten LDD enthält eine ganze Anzahl von Gruppen von 8 Bytes + 3 Bytes gemäß den drei letzten Bits LDD = "011" der Zone PD des Rasters TR.
In der anderen Übertragungsrichtung, von der Karte CA, SIM zum Terminal TE, TM, werden die Daten anfänglich nicht komprimiert und werden durch die Karte in den genormten Rastern "T = 0" oder eventuell "T = 1" verkapselt.

Claims

1. Zur Aufnahme von Zonen komprimierter Daten geeignete Chipkarte (CA, SIM), von denen jeder eine erwartete Längenangabe dekomprimierter Daten (LDD) und eine Länge komprimierter Daten (LC) voransteht, dadurch gekennzeichnet, dass sie in Abhängigkeit der jeweiligen Längen der komprimierten Daten (LC) ein erstes Mittel (MC) zur Speicherung der von komprimierten Daten (DATA, IR) empfangenen Zonen enthält, ein zweites Mittel (MS) zur Speicherung eines Dekomprimierungs-Algorithmus, ein Mittel (PR) zum Dekomprimieren der komprimierten Daten in jeder Zone in dekomprimierte Daten gemäß des besagten Dekomprimierungs-Algorithmus auf eine von der erwarteten Längenangabe dekomprimierter Daten (LDD) abhängigen Länge, und ein drittes Mittel (MD) zum Speichern der dekomprimierten Daten.

2. Chipkarte gemäß Anspruch 1, in der das zweite Mittel zum Speichern (MS) mehrere Dekomprimierungs- Algorithmen (AL0 bis ALI) enthält, und das Mittel zum Dekomprimieren (PR) eine jeder empfangenen Zone komprimierter Daten voranstehende Dekomprimierungs- Algorithmus-Nummer (Ali) feststellt, damit diese Daten gemäß des Dekomprimierungs-Algorithmus, dessen Nummer festgestellt wurde, dekomprimiert werden.

3. Chipkarte gemäß Anspruch 2, in der das zweite Mittel zum Speichern (MS) mehrere, jeweils den Dekomprimierungs-Algorithmen (AL0 bis ALI) zugeordnete Dekomprimierungs-Modelle (Mi0 bis MiJ) enthält, und das Mittel zum Dekomprimieren (PR) eine jeder empfangenen Zone komprimierter Daten voranstehende Dekomprimierungs-Modell-Nummer (Mij) feststellt, damit diese Daten gemäß des Dekomprimierungs-Algorithmus und des entsprechenden Dekomprimierungs-Modells dekomprimiert werden, deren Nummern festgestellt wurden.

4. Chipkarte gemäß Anspruch 2, mit einem vierten Mittel (mm) zum Speichern einer zuvor von einem empfangenen Zone komprimierter Daten empfangenen Dekomprimierungs-Modells, und das Mittel zum Dekomprimieren (PR) stellt eine der besagten empfangenen Zone komprimierter Daten voranstehende Dekomprimierungs- Algorithmus-Nummer (Ali) fest, damit diese Daten gemäß eines Dekomprimierungs-Algorithmus, dessen Nummer festgestellt wurde, und des im vierten Mittel zum Speichern (mm) gelesenen Dekomprimierungs-modells dekomprimiert werden.

5. Chipkarte gemäß Anspruch 2, mit einem vierten Mittel (mm) zum Speichern eines Dekomprimierungs- Modells, das implizit von einer Zone komprimierter Daten im Schreibverlauf in den ersten Mitteln zum Speichern (MC) abgeleitet wird, und das Mittel zum Dekomprimieren (PR) stellt eine der besagten gespeicherten Zone komprimierter Daten voranstehende Dekomprimierungs-Algorithmus-Nummer (ALi) fest, damit diese Daten gemäß eines Dekomprimierungs-Algorithmus, dessen Nummer festgestellt wurde, und des im vierten Mittel zum Speichern (mm) gelesenen Dekomprimierungs-Modells dekomprimiert werden.

6. Chipkarte gemäß Anspruch 1 bis 5, in der das Mittel zum Dekomprimieren (PR) eine Angabe (CLA: B2, B3) auf dem komprimierten oder nicht komprimierten Zustand jeder empfangene Zone komprimierter Daten feststellt, damit das Mittel zum Dekomprimieren (PR) die Daten nur in den Zonen von Daten dekomprimiert, denen eine Angabe eines komprimierten Zustandes voransteht.

7. Protokolldateneinheit zur Aufnahme insbesondere durch die Chipkarte gemäß Anspruch 1 bis 6, mit einer Kopfzeile (ET) und einem Datenfeld (DATA), wobei die Kopfzeile die Länge (LC) der Datenzone beinhaltet, dadurch gekennzeichnet, dass die Kopfzeile (ET) eine Angabe (LDD) über die erwartete Länge komprimierter Daten nach dem Dekomprimieren der Datenzone (DATA) enthält.

8. Protokolldateneinheit gemäß Anspruch 7, in der die Angabe über die erwartete Länge dekomprimierter Daten (LDD) ein Wort von n Bits gleich der erwarteten Länge der dekomprimierten Daten Modulo 2n ist, wobei die erwartete Länge in Worten dekomprimierter Daten von m Bits ausgedrückt wird, wobei n eine ganze Zahl von wenigstens gleich 0 und m eine ganze Zahl von wenigstens gleich 1 ist.

9. Protokolldateneinheit gemäß Anspruch 7 oder 8, in der die Kopfzeile (ET) die Nummer (ALi) eines Dekomprimierungs-Algorithmus umfasst, durch den die komprimierten Daten in der Datenzone (DATA) zu dekomprimieren sind.

10. Protokolldateneinheit gemäß Anspruch 9, in der die Kopfzeile (ET) die Nummer (Mij) eines Dekomprimierungsmodells beinhaltet, das dem Dekomprimierungs- Algorithmus entspricht; dessen Nummer (ALi) in der Kopfzeile inbegriffen ist und durch den die komprimierten Daten in der Datenzone (DATA) zu dekomprimieren sind.

11. Protokolldateneinheit gemäß Anspruch 7 bis 10, in der die Kopfzeile (ET) eine Angabe des Datenzustandes (B1, B2) mit einem ersten Zustand umfasst, wenn die Daten in der Datenzone nicht komprimiert sind, und mit einem zweiten Zustand, wenn die Daten in der Datenzone (DATEN) komprimiert sind.

12. Protokolldateneinheit gemäß Anspruch 11, in der die Angabe des Datenzustandes (B1, B2) einen dritten Zustand hat, wenn die Daten in der Datenzone (DATA) gemäß eines vorbestimmten (AL0) Dekomprimierungs- Algorithmus und eines vorbestimmten (M00) Dekomprimierungs-Modells zu dekomprimieren sind.

13. Protokolldateneinheit gemäß Anspruch 11 oder 12, in der die Kopfzeile (ET) die Nummer eines Dekomprimierungs-Algorithmus (ALi), die Nummer eines Dekomprimierungs-Modells (Mij) und die Angabe über die erwartete Länge dekomprimierter Daten (LDD) beinhaltet, wenn die Angabe des Datenzustandes (B1, B2) im zweiten Zustand ist.

14. Insbesondere in der Chipkarte gemäß Anspruch 1 bis 6 umzusetzendes Verfahren zum Dekomprimieren der komprimierten Datenzonen (DATA), wobei jede Zone komprimierter Daten eine Angabe über die erwartete Länge (LDD) komprimierter Daten voransteht, die komprimierten, in der Zone enthaltenen Daten entspricht, sowie einer Länge (LC) der in der Zone enthaltenen komprimierten Daten, gekennzeichnet durch die folgenden Schritte:

- Feststellen (D3) der Länge (LC) der komprimierten Daten und Speichern (D0) der Zone komprimierter Daten (DATA) über die festgestellte Länge, und

- Feststellen (D8) der Angabe über die erwartete Länge dekomprimierter Daten (LDD) und Dekomprimieren (D9) der Daten, so dass das Dekomprimieren in Abhängigkeit von der festgestellten Angabe (LDD) beendet wird.

15. Verfahren gemäß Anspruch 14, umfassend einen Schritt zum Auswählen (D6) eines Dekomprimierungs- Algorithmus (ALi) unter mehreren Dekomprimierungs- Algorithmen (AL0 bis ALI) in Abhängigkeit einer der Zone komprimierter Daten voranstehender Algorithmus- Nummer, damit die Daten der Zone gemäß des ausgewählten Dekomprimierungs-Algorithmus dekomprimiert werden.

16. Verfahren gemäß Anspruch 15, umfassend einen Schritt zum Auswählen (D7, D72) eines Dekomprimierungs- Modells unter mehreren, dem ausgewählten Dekomprimierungs-Algorithmus in Abhängigkeit einer der Zone komprimierter Daten voranstehende Modell-Nummer zugeordneten Dekomprimierungs-Modellen (Mi0 bis MiJ), um die Daten der Zone gemäß des ausgewählten Dekomprimierungs- Algorithmus und des ausgewählten Dekomprimierungs- Modells zu dekomprimieren.

17. Verfahren gemäß Anspruch 15, umfassend einen Schritt zum Speichern (D71) eines zuvor in der Zone komprimierter Daten (DATA) empfangenen Dekomprimierungs- Modells (Mij) zum Dekomprimieren der Zone gemäß des ausgewählten Dekomprimierungs-Algorithmus und des gespeicherten Dekomprimierungs-Modells.

18. Verfahren gemäß Anspruch 15, umfassend einen Schritt zum Speichern (D71) eines implizit aus der empfangenen Zone komprimierter Daten (DATA) abgeleiteten Dekomprimierungs-Modells (Mij), um die Daten der Zone gemäß des ausgewählten Dekomprimierungs-Algorithmus und des abgeleiteten und gespeicherten Dekomprimierungs- Modells zu dekomprimieren.

19. Verfahren gemäß Anspruch 14 bis 18, umfassend einen Schritt (D4, D50, D51, D52) zum Feststellen einer jeder Zone dekomprimierter Daten voranstehenden Angabe zu Datenzuständen (B2, B3), um die Daten der Zone nur zu dekomprimieren, wenn die Angabe über den Datenzustand nicht in einem ersten vorbestimmten Zustand ist.

20. Verfahren gemäß Anspruch 19, nach dem der Schritt (D8) zum Feststellen einer Angabe über die erwartete Länge dekomprimierter Daten (LDD) nicht ausgeführt wird, wenn die Angabe über den Datenzustand (B2, B3) ein vorbestimmter Zustand ist, der angibt, dass die komprimierten Daten gemäß eines vorbestimmten Algorithmen und Modells (A10, M00) zu dekomprimieren sind.