[go: up one dir, main page]

DE19721949C2 - Chiffriervorrichtung - Google Patents

Chiffriervorrichtung

Info

Publication number
DE19721949C2
DE19721949C2 DE19721949A DE19721949A DE19721949C2 DE 19721949 C2 DE19721949 C2 DE 19721949C2 DE 19721949 A DE19721949 A DE 19721949A DE 19721949 A DE19721949 A DE 19721949A DE 19721949 C2 DE19721949 C2 DE 19721949C2
Authority
DE
Germany
Prior art keywords
server
frame
network
encryption
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE19721949A
Other languages
English (en)
Other versions
DE19721949A1 (de
Inventor
Chieko Funabe
Yoshimasa Baba
Shoichiro Seno
Yuuji Koui
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Publication of DE19721949A1 publication Critical patent/DE19721949A1/de
Application granted granted Critical
Publication of DE19721949C2 publication Critical patent/DE19721949C2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Small-Scale Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Description

Die vorliegende Erfindung bezieht sich auf eine Chif­ friervorrichtung, welche mehrere Server sowie Kunden mit einem Netzwerk hierdurch verbindet, um Daten zu chiffrieren für die Ausführung von gegenseitig beein­ flußbaren Kommunikationen zwischen diesen.
Bei einem bekannten Typ von Chiffriervorrichtung wer­ den alle zu übertragenden empfangenen Rahmen chif­ friert, und ein Steuerrahmen zum Betreiben eines Netzwerksystems wird auch chiffriert. Aus diesem Grund können Steuerrahmen zum Betreiben eines Netz­ werksystems nicht ausgetauscht werden zwischen der Netzwerkausrüstung oder einem Anschluß, die jeweils eine Chiffrierfunktion aufweisen, und solchen ohne eine Chiffrierfunktion, und in einem Fall, in welchem ein Rahmen durch die Netzwerkausrüstung übertragen wird, ist es auch erforderlich, daß die Netzwerkaus­ rüstung eine Chiffrierfunktion aufweist, so wie die Chiffriervorrichtung, die in der japanischen Patent- Offenlegungsschrift Nr. HEI 4-154233 offenbart ist. Fig. 29 zeigt die Systemkonfiguration. In Fig. 29 wird mit der Bezugszahl (1) ein zwischen Anschlüssen verwendetes Chiffriersystem bezeichnet, mit (2) ein innerhalb eines Netzwerks verwendetes Chiffriersy­ stem, mit NW11, NW12, NW13 ein Netzwerk, mit 21, 22 ein Kommunikationspfad, mit 31, 32, 33 eine Netzwerk­ ausrüstung wie eine Brücke oder dergleichen, und mit 111, 112, 121, 122, 131, 132 jeweils ein Anschluß.
Als nächstes folgt die Beschreibung der Arbeitsweise. Fig. 30 ist eine Rahmendarstellung, welche einen chiffrierten Bereich eines IP (Internet Protrokoll)- Rahmens als ein Beispiel zeigt. In dem übertragenden Anschluß 111 wird das zwischen Anschlüssen verwendete Chiffriersystem (1) angewendet nur für Informationen, welche für Kommunikationen mit einem Empfängeran­ schluß 121 erforderlich sind, und das innerhalb eines Netzwerks verwendete Chiffriersystem (2) wird ange­ wendet für Informationen, welche für eine Übertra­ gungsverarbeitung durch die Netzwerke NW11, NW12 oder die Netzwerkausrüstung 31, 32 oder dergleichen erfor­ derlich sind. Das heißt, der übertragende Anschluß 111 chiffriert die in Fig. 30 gezeigten Abschnitte N1, N2, N3 entsprechend dem Chiffriersystem (2) in­ nerhalb des Netzwerks für Informationen, welche nur innerhalb des Netzwerks verwendet werden, wie Netz­ werkadressen oder dergleichen der Netzwerkausrüstung 31, 32, die das Netzwerk NW11, zu welchem der über­ tragende Anschluß 111 gehört, und das Netzwerk NW12, zu welchem der Empfängeranschluß 121 gehört, mitein­ ander verbindet, und chiffriert die Abschnitte T1, T2, T3, die in Fig. 30 gezeigt sind, entsprechend dem Chiffriersystem (1) zwischen den Anschlüssen für In­ formationen, die nur zwischen den Anschlüssen 111, 121 verwendet werden, um die chiffrierten Abschnitte zu dem Netzwerk NW11, zu welchem der Anschluß 111 gehört, als eine Nachrichteneinheit zu senden.
Die mit dem Netzwerk NW11 verbundene Netzwerkausrü­ stung 31 empfängt die Nachricht, dechiffriert die in Fig. 30 gezeigten Abschnitte N1, N2, N3, welche je­ weils in dem Netzwerk NW11 verwendet werden, um die Nachricht zu der Netzwerkausrüstung 32 zu übertragen, die mit dem Netzwerk NW12 verbunden ist, zu dem der Empfangsanschluß 121 gehört. Die Netzwerkausrüstung 32 dechiffriert auch die Abschnitte N1, N2, N3 in Fig. 30, die jeweils in dem Netzwerk NW12 verwendet wer­ den, um die Nachricht zu dem Netzwerk zu übertragen. Der zu dem Netzwerk NW12 gehörende Empfängeranschluß 121 dechiffriert die Abschnitte N1, N2, N3 in Fig. 30, die jeweils in dem Netzwerk verwendet werden, in der von der Netzwerkausrüstung 32 empfangenen Nach­ richt entsprechend dem in dem Netzwerk verwendeten Chiffriersystem (2), und prüft, ob die Nachricht an den eigenen Anschluß 121 adressiert ist, um die Ab­ schnitte T1, T2, T3 in Fig. 30 zu dechiffrieren, von denen jeder Informationen für die Anschlüsse entspre­ chend dem Chiffriersystem (1) zwischen den Anschlüs­ sen darstellt.
Bei dem bekannten Typ von Chiffriervorrichtung ist ein Chiffriersystem getrennt in eines zwischen Netz­ werkvorrichtungen und eines zwischen Anschlüssen, und durch Dechiffrieren von für eine Übertragung benötig­ ten Abschnitten chiffriert jede der Netzwerkvorrich­ tungen Nachrichtenkommunikationen, die zwischen den Anschlüssen über ein Netzwerk ausgeführt werden, wel­ ches die Netzwerkausrüstung enthält, wodurch ein Kom­ munikationsverbergungssystem zum Ausführen normaler Kommuni­ kationen zwischen den Anschlüssen vorgesehen werden kann.
Wie vorbeschrieben ist, kann die Chiffriervorrichtung auf der Grundlage der bekannten Technologie nicht einen Steuer­ rahmen für ein Netzwerksystem gegen einen solchen für eine Netzwerkausrüstung sowie für einen Anschluß, welche jeweils keine Chiffrierfunktion haben, austauschen, da die Vorrich­ tung auch den Netzwerksystem-Steuerrahmen chiffriert zum Be­ treiben des Netzwerksystems, welcher nicht ein Datenrahmen eines Benutzers ist.
Die JP 63-155930 offenbart Netzwerkprozessoren, die zwischen einzelne Endgeräte und einem Netzwerk zwischengeschaltet sind. In den Netzwerkprozessoren wird den von den Endgeräten empfangenen Daten ein Schlüssel hinzugefügt und diese Daten werden anschließend in einem Codierer verschlüsselt. Mit den verschlüsselten Daten wird dann auch der zu ihrer Verschlüs­ selung bzw. gehörige Schlüssel mit übertragen.
Es ist die Aufgabe der vorliegenden Erfindung, eine Chif­ friervorrichtung anzugeben, in welcher Chiffrierkommunika­ tionen ausgeführt werden können unter Verwendung einer Netz­ werkausrüstung ohne Chiffrierfunktion, wie Server, Kunden oder Leiteinrichtungen oder dergleichen.
Weiterhin ist es Aufgabe der vorliegenden Erfindung, eine Chiffriervorrichtung anzugeben, bei welcher ein Kunde mit einer damit verbundenen Chiffriervorrichtung auf einen Ser­ ver zugreifen kann, ohne daß irgendeine Chiffriervorrichtung damit verbunden ist.
Diese Aufgabe wird durch die Chiffriervorrichtungen nach den Ansprüchen 1 bis 3 jeweils gelöst. Vorteilhafte Weiterbil­ dungen der erfindungsgemäßen Chiffriervorrichtung werden in den abhängigen Ansprüchen gegeben.
Eine Chiffriervorrichtung gemäß der vorliegenden Erfindung umfaßt eine Chiffrierdienstvorrichtung zum Empfang eines Rahmens, welcher Serverinformationen mitteilt, von einem An­ schluß, und zum Umwandeln eines Diensttyps in Cryptokommuni­ kation, wenn der Diensttyp eines Servers, der in den Ser­ verinformationen für diesen Rahmen enthalten ist, keine Cryptokommunikation ist, um den Rahmen zu einem Netzwerk zu senden; eine Nichtchiffrier-Dienstvorrichtung zum Empfang eines Rahmens, welcher Serverinformationen mitteilt, von dem Netzwerk, und zur Umwandlung des Diensttyps hier­ von, wenn der Diensttyp der in dem Rahmen enthaltenen Serverinformationen eine Cryptokommunikation ist, in eine Nicht-Cryptokommunikation, um den Rahmen zu dem Anschluß zu senden, und auch zum Abbrechen der Dienstinformationen oder Umwandeln der Anzahl von Sprüngen, die die Anzahl von übertragenen Leitein­ richtungen anzeigt, in einen nicht erzielbaren Wert, wenn der Diensttyp hiervon eine Nicht-Cryptokommuni­ kation ist, um den Rahmen zu dem Anschluß zu senden; eine Chiffriervorrichtung zum Empfang eines Datenrah­ mens von dem Anschluß und zum Chiffrieren eines in dem Datenrahmen enthaltenen bestimmten Datenab­ schnitts, um den Datenabschnitt zu dem Netzwerk zu senden; eine Dechiffriervorrichtung zum Empfang eines Datenrahmens von dem Netzwerk und zum Dechiffrieren eines in diesem Datenrahmen enthaltenen bestimmten Datenabschnitts, um ihn zu dem Anschluß zu senden; und eine Kommunikationsweg-Informationsübertragungs­ vorrichtung zum Empfang eines Rahmens, welcher Kom­ munikationsweginformationen mitteilt, von dem An­ schluß, zum Senden des Rahmens zu dem Netzwerk, und zum Empfang eines Rahmens, welcher Kommunikationsweg­ informationen mitteilt, von dem Netzwerk, um den Rah­ men zu dem Anschluß zu senden.
Eine Chiffriervorrichtung gemäß der vorliegenden Er­ findung umfaßt eine transparente Verarbeitungsadres­ sentabelle zum Speichern einer nicht zu chiffrieren­ den Adresse; Chiffriermittel zum Empfang eines Daten­ rahmens von einem Anschluß und zum Senden des Daten­ rahmens zu einem Netzwerk, wenn eine Serveradresse des Empfängers für diesen Datenrahmen in der trans­ parenten Verarbeitungsadressentabelle registriert ist, ohne den bestimmten Datenabschnitt des Datenrah­ mens zu chiffrieren, oder durch Chiffrieren des be­ stimmten Datenabschnitts des Datenrahmens, wenn die Serveradresse des Empfängers des Datenrahmens nicht in der transparenten Verarbeitungsadressentabelle registriert ist; Dechiffriermittel zum Empfang eines Datenrahmens von dem Netzwerk und zum Senden des Da­ tenrahmens zu dem Anschluß, wenn eine Adresse des Senders des Datenrahmens in der transparenten Verar­ beitungsadressentabelle registriert ist, ohne den bestimmten Datenabschnitt des Datenrahmens zu dechif­ frieren, oder durch Dechiffrieren des bestimmten Da­ tenabschnitts des Datenrahmens, wenn die Adresse des Senders des Datenrahmens nicht in der transparenten Verarbeitungsadressentabelle registriert ist; eine transparente Verarbeitungsservertabelle zum Speichern von Serverinformationen für einen Server, für welchen eine Chiffrierung nicht erforderlich ist; eine trans­ parente Verarbeitungsvorrichtung für einen Serverin­ formationen mitteilenden Rahmen zum Empfang eines Serverinformationen mitteilenden Rahmens von dem Netzwerk und zum Senden des Rahmens zu dem Anschluß in Abhängigkeit von einem Ergebnis des Vergleichs zwischen einem in den Serverinformationen für diesen Rahmen enthaltenen Servernamen und einem in der transparenten Verarbeitungsservertabelle gespeicher­ ten Servernamen; und eine Kommunikationsweg-Informa­ tionsübertragungsvorrichtung zum Empfang eines Kom­ munikationsweginformationen mitteilenden Rahmens von dem Anschluß, zum Senden dieses Rahmens zu dem Netz­ werk, und auch zum Empfang eines Kommunikationsweg­ informationen mitteilenden Rahmens von dem Netzwerk und zum Senden des Rahmens zu dem Anschluß.
Eine Chiffriervorrichtung gemäß der vorliegenden Er­ findung umfaßt eine Sprungzahl-Addiervorrichtung zum Empfang eines Serverinformationen mitteilenden Rah­ mens von einem Anschluß und zum Senden eines Rahmens, der durch Addieren einer bestimmten Zahl zu einer Sprungzahl, die in den Serverinformationen für diesen Rahmen enthalten ist, erhalten wurde, zu einem Netz­ werk; eine Initialisierungsanforderungs-Antwortvor­ richtung zum Empfang eines Rahmens, welcher Serverin­ formationen für eine Verbindungsbestimmung anfordert, wenn diese von dem Anschluß initialisiert ist, und zum Senden eines Serverinformationen mitteilenden Rahmens für eine bestimmte Verbindungsbestimmung zu dem Anschluß; eine Abbruchvorrichtung zum Empfangen eines Serverinformationen für eine Verbindungsbestim­ mung anfordernden Rahmen, wenn diese von dem Netzwerk initialisiert ist, und zum Abbrechen des Rahmens; Chiffriermittel zum Empfang eines Datenrahmens von dem Anschluß und zum Chiffrieren eines bestimmten Datenabschnitts des Datenrahmens, um ihn zu dem Netz­ werk zu senden; Dechiffriermittel zum Empfang eines Datenrahmens von dem Netzwerk, zum Dechiffrieren ei­ nes bestimmten Datenabschnitts des Datenrahmens, und zum Senden des dechiffrierten Datenabschnitts zu dem Anschluß; und eine Kommunikationsweginformationen- Übertragungsvorrichtung zum Empfang eines Kommunika­ tionsweginformationen mitteilenden Rahmens von dem Anschluß, zum Senden des Rahmens zu dem Netzwerk, und auch zum Empfang eines Kommunikationsweginformationen mitteilenden Rahmens von dem Netzwerk und zum Senden des Rahmens zu dem Anschluß.
Die Erfindung wird im folgenden anhand von in den Figuren dargestellten Ausführungsbeispielen näher erläutert. Es zeigen:
Fig. 1 die Konfiguration einer Chiffriervor­ richtung gemäß einem ersten Ausfüh­ rungsbeispiel nach der vorliegenden Erfindung,
Fig. 2 ein Format eines IPX-Rahmens,
Fig. 3 ein Rahmenformat eines RIP-Anforde­ rung,
Fig. 4 ein Rahmenformat einer SAP-Anforde­ rung,
Fig. 5 ein Rahmenformat einer SAP-Antwort,
Fig. 6 die Konfiguration eines Netzwerkes in einem Fall, in welchem ein Kunde und ein Server bei demselben Netzwerk eine Kommunikation miteinander durchführen ohne Chiffrieren von Daten,
Fig. 7 eine Folgediagramm, das einen Fall zeigt, in welchem ein Server peri­ odisch seine Serverinformationen aus­ sendet,
Fig. 8 ein Folgediagramm, wenn ein Kunde ini­ tialisiert wird,
Fig. 9 die Konfiguration eines Kunden und eines Servers, die über eine Leitein­ richtung miteinander verbunden sind,
Fig. 10 ein Folgediagramm, das einen Fall zeigt, in welchem ein Server peri­ odisch seine Serverinformationen aus­ sendet,
Fig. 11 ein Folgediagramm, wenn ein Kunde ini­ tialisiert ist,
Fig. 12 die Konfiguration eines Cryptokommuni­ kations-Systems gemäß dem ersten Aus­ führungsbeispiel,
Fig. 13 ein Folgediagramm, das einen Fall zeigt, in welchem ein Server peri­ odisch seine Serverinformationen in einem Cryptokommunikations-System ge­ mäß dem ersten Ausführungsbeispiel aussendet,
Fig. 14 ein Folgediagramm, wenn ein Kunde in einem Cryptokommunikations-System ge­ mäß dem ersten Ausführungsbeispiel initialisiert ist,
Fig. 15 ein Folgediagramm, das einen Fall zeigt, in welchem ein Server mit einem Nicht-Chiffriersystem eine SAP-Anfor­ derung von einem Kunden mit einem Chiffriersystem empfängt in dem Cryp­ tokommunikations-System gemäß dem er­ sten Ausführungsbeispiel,
Fig. 16 ein Folgediagramm, welches einen Fall zeigt, in welchem ein Server mit einem Chiffriersystem eine SAP-Anforderung von einem Kunden ohne ein Chiffriersy­ stem empfängt in dem Cryptokommunika­ tions-System gemäß dem ersten Ausfüh­ rungsbeispiel,
Fig. 17 die Konfiguration eines Cryptokommuni­ kations-Systems enthaltend eine Leit­ einrichtung gemäß dem ersten Ausfüh­ rungsbeispiel,
Fig. 18 ein Folgediagramm, wenn ein Kunde in einem Cryptokommunikations-System ent­ haltend die Leiteinrichtung gemäß dem ersten Ausführungsbeispiel initiali­ siert ist,
Fig. 19 die Konfiguration eines Cryptokommuni­ kations-Systems enthaltend eine Leit­ einrichtung in einem Fall, in welchem mehrere Typen von Chiffrierdienst vor­ gesehen sind,
Fig. 20 die Konfiguration einer Chiffriervor­ richtung gemäß dem zweiten Ausfüh­ rungsbeispiel nach der vorliegenden Erfindung,
Fig. 21 die Konfiguration eines Cryptokommuni­ kations-Systems enthaltend eine Leit­ einrichtung gemäß dem zweiten Ausfüh­ rungsbeispiel,
Fig. 22 ein Folgediagramm, das einen Fall zeigt, in welchem ein Server peri­ odisch seine Serverinformationen in dem Cryptokommunikations-System gemäß dem zweiten Ausführungsbeispiel aus­ sendet,
Fig. 23 einen Fall, in welchem ein Kunde mit einem Chiffriersystem mit einem neuen Server ohne ein Chiffriersystem in dem Cryptokommunikations-System gemäß dem zweiten Ausführungsbeispiel verbunden ist,
Fig. 24 die Konfiguration einer Chiffriervor­ richtung gemäß dem dritten Ausfüh­ rungsbeispiel nach der vorliegenden Erfindung,
Fig. 25 die Konfiguration eines Cryptokommuni­ kations-Netzwerks gemäß dem dritten Ausführungsbeispiel,
Fig. 26 ein Folgediagramm für einen Fall, in welchem ein Server periodisch seine Serverinformationen in dem Cryptokom­ munikations-System gemäß dem dritten Ausführungsbeispiel aussendet,
Fig. 27 ein Folgediagramm mit einem Kunden mit einem Chiffriersystem, der in dem Cryptokommunikations-System gemäß dem dritten Ausführungsbeispiel initiali­ siert ist,
Fig. 28 die Konfiguration eines Cryptokommuni­ kations-System ohne eine Leiteinrich­ tung gemäß dem dritten Ausführungsbei­ spiel,
Fig. 29 die Konfiguration eines Kommunika­ tionsnetzwerks nach dem Stand der Technik, und
Fig. 30 einen Bereich zum Chiffrieren eines Rahmens nach dem Stand der Technik.
Bei diesem Ausführungsbeispiel können sich gegensei­ tig beeinflussende Kommunikationen zwischen einem Kunden und einem Server in einem gewöhnlichen Text miteinander ausgeführt werden, indem wie mit einem Netzwerk verbunden werden, und Chiffrierkommunikatio­ nen zwischen Chiffriervorrichtungen können auch aus­ geführt werden durch Verbinden des Kunden über die Chiffriervorrichtung mit dem Netzwerk und Verbinden des Servers über die Chiffriervorrichtung mit dem Netzwerk.
Die Beschreibung erfolgt für ein Beispiel, bei wel­ chem das Ausführungsbeispiel auf ein Protokoll ange­ wendet wird, das in NetWare (Marke der Novell Co.) als ein Netzwerk OS für einen Personalcomputer ver­ wendet wird.
In dem NetWare wird das IPX (Internetzwerk-Paketaus­ tausch)-Protokoll als ein Netzwerk-Schichtprotokoll verwendet. Fig. 2 zeigt einen Rahmen des IPX. In Fig. 2 wird mit dem Bezugszeichen X1 eine Prüfsumme be­ zeichnet, mit X2 die Länge eines Rahmens, mit X3 eine Transportsteuerung zum Zählen einer Leiteinrichtung, durch welche der Rahmen hindurchgeht, mit X4 ein Rah­ mentyp, der einen Typ des Rahmens anzeigt, mit X5 eine Empfängernetzwerkzahl des Rahmens, mit X6 eine Empfängerknotenzahl zum Bestimmen eines Empfängeran­ schlusses, mit X7 eine Empfängerbuchsenzahl, die das Empfängerprotokoll anzeigt, mit X8 die Sendernetz­ werkzahl, mit X9 eine Senderknotenzahl zum Bestimmen eines Senderanschlusses, mit X10 eine Senderbuchsen­ nummer, die das Senderprotokoll anzeigt, und mit X11 ein Datenabschnitt. Der IPX-Rahmen identifiziert ei­ nen Datentyp des Datenabschnitts X11 gemäß der Emp­ fängerbuchsenzahl X7.
Die Übertragungseinrichtungen eines Netzwerks wie eine Leiteinrichtung speichern eine Leittabelle zum Übertragen des empfangenen Rahmens zu einem darin angezeigten Empfängernetzwerk. In einem Fall, in wel­ chem das Empfängernetzwerk des empfangenen Rahmens nicht identisch ist mit dem Netzwerk, das den Rahmen empfangen hat, sucht die Übertragungseinrichtung nach der darin gespeicherten Leittabelle, um den empfange­ nen Rahmen gemäß den Leitinformationen der Tabelle zu übertragen. Wenn sie keine Leitinformationen für das Empfängernetzwerk hat, überträgt die Übertragungsvor­ richtung den Rahmen nicht. Die Leitinformationen wer­ den miteinander ausgetauscht zwischen einer Leitein­ richtung und Servern, die das RIP(Leitinformations­ protokoll)-Protokoll periodisch verwenden, oder in einem Fall, wenn irgendeine Änderung darin auftritt. Das RIP-Protokoll wird auf einem höheren Pegel als das IPX-Protokoll positioniert und identifiziert, wenn geprüft ist, daß die Empfängerbuchsenzahl (X7 in Fig. 2) in dem IPX-Vorsatz eine Zahl von 0 × 453 (0 × zeigt nachfolgend eine Hexadezimalstelle an) ist.
Fig. 3 zeigt ein Rahmenformat des RIP. In Fig. 3 ist mit dem Bezugszeichen RP1 ein Vorgang zum Identifi­ zieren, ob der Rahmen eine Anforderung oder eine Ant­ wort ist, bezeichnet, mit RP2 eine Netzwerkzahl, mit RP3 die Anzahl von Sprüngen, welche die Anzahl von Netzwerken anzeigt, durch welche der Rahmen bis zum Zielnetzwerk hindurchgeht, und mit RP4 die Anzahl von Zeitmomenten, die eine Zeitspanne anzeigt, welche zum Erreichen des Zielnetzwerks erforderlich ist. Die Zahl von Sprüngen wird erhalten durch Zählen einer Zahl von 0 × 01 und Erhöhen um 1 jedesmal, wenn der Rahmen durch eine Leiteinrichtung hindurchgeht. In einem Fall, in welchem die Zahl von Sprüngen in dem RP3 gleich 0 × 10 ist, bedeutet das in RP2 angezeigte Netzwerk unerreichbar, welche die Information ungül­ tig macht. Die Informationen in RP2 bis RP4 bilden eine Einheit von Leitinformationen, so daß mehrere Leitinformationen in einem Rahmen gesetzt werden kön­ nen. Andere Abschnitte in Fig. 3 sind dieselben wie die in Fig. 2, so daß auf deren Beschreibung hier verzichtet wird.
Das NetWare ist ein Kunde/Server-System, und der Ser­ ver sendet hierdurch vorgesehene Dienste aus. Die Serverinformationen werden miteinander ausgetauscht zwischen einer Leiteinrichtung und Servern, die das SAP (Dienstanzeigeprotokoll)-Protokoll periodisch verwenden oder in einem Fall, in welchem irgendeine Änderung darin auftritt. Eine Leiteinrichtung oder ein Server speichert die empfangenen Serverinforma­ tionen in einer Servertabelle zum Zurückgeben der Antwort auf die empfangene Anfrage. Das SAP-Protokoll ist auf einem höheren Pegel als das IPX-Protokoll positioniert und wird identifiziert, wenn geprüft ist, daß die Empfängerbuchsenzahl (X7 in Fig. 2) in dem IPX-Vorsatz eine Zahl von 0 × 452 ist.
Es sind zwei Typen von Rahmenformat für das SAP vor­ gesehen; ein Anfragerahmen und ein Antwortrahmen. Fig. 4 zeigt einen Anfrage- oder Anforderungsrahmen­ format für das SAP, und Fig. 5 zeigt ein Antwortrah­ menformat für das SAP. In Fig. 4 ist mit dem Bezugs­ zeichen SP1 ein Anfragetyp bezeichnet, und mit SP2 ein Diensttyp zur Anfrage. Andere Abschnitte in Fig. 4 sind dieselben wie diejenigen in Fig. 2, so daß auf deren Beschreibung hier verzichtet wird.
Es sind zwei Typen von SAP-Anfragerahmen vorgesehen; allgemeine Anfrage und Anfrage des nächsten Dienstes, welche von einem Kunden ausgesandt wird, wenn sein Anlauf stattfindet, und der Typ wird identifiziert gemäß einem Wert des Anfragetyps SP1. In Fig. 5 ist mit dem Bezugszeichen SP3 ein Antworttyp bezeichnet, mit SP4 ein Diensttyp, mit SP5 ein Servername, mit SP6 eine Netzwerkzahl als eine Adresse eines Servers, mit SP7 eine Knotennummer, mit SP8 eine Buchsennummer und mit SP9 die Zahl von Sprüngen, die die Anzahl von durchlaufenen Netzwerken bis zum Server anzeigt. An­ dere Abschnitte in Fig. 5 sind dieselben wie diejeni­ gen in Fig. 2, so daß auf deren Beschreibung hier verzichtet wird.
Ein Fall, in welchem die Zahl von Sprüngen in SP9 gleich 0 × 10 ist, zeigt die Umstand an, daß der in dem Servernamen SP5 gezeigte Server nicht brauchbar ist. Es sind zwei Typen von Antwortrahmen vorgesehen; eine Antwort auf eine Anfrage und ein Rahmen zum pe­ riodischen Aussenden von Serverinformationen, und der Typ wird identifiziert entsprechend dem Antworttyp SP3. Die Informationen in SP4 bis SP9 bilden eine Einheit von Serverinformationen für einen Server, so daß mehrere Serverinformationen in einem Rahmen ge­ setzt werden können.
Bei diesem Ausführungsbeispiel identifiziert eine Chiffriervorrichtung ein Protokoll, sendet einen RIP- Rahmen sowie einen SAP-Rahmen in dem NetWare, ohne sie zu chiffrieren, ändert Werte eines Diensttyps eines Servers, der in dem SAP-Rahmen enthalten ist, in Werte für einen Chiffrierdienst, um ausgesandt zu werden, und eine Chiffriervorrichtung, welche den SAP-Rahmen enthaltend die Serverinformationen empfan­ gen hat, dechiffriert die Werte in die Werte für den anfänglichen Servicetyp des Nichtchiffrier-Dienstes. Bezüglich der Datenrahmen, die nicht die vorbeschrie­ benen Abschnitte sind, wird der in Fig. 2 gezeigte Datenabschnitt X11 chiffriert.
Fig. 1 zeigt die Konfiguration der Chiffriervorrich­ tung. In Fig. 1 ist mit der Bezugszahl 1 ein Anschluß bezeichnet, mit 2 eine Chiffriervorrichtung, und mit 3 ein Netzwerk. Die Bezugszahl 21 bezeichnet einen anschlußseitigen Sende/Empfangsabschnitt mit einem oder mehr Toren zum Durchführen einer Datenaktion zwischen dem mit dem Tor verbundenen Anschluß und der Vorrichtung. Die Bezugszahl 23 bezeichnet einen netz­ werkseitigen Sende/Empfangsabschnitt zum Durchführen einer Datentransaktion zwischen einem Netzwerk und der Vorrichtung. In der Figur ist auch mit der Be­ zugszahl 22 ein Rahmenspeicher zum Speichern eines empfangenen Rahmens bezeichnet, mit 24 ein ROM/RAM für das Programm sowie für die Bearbeitung, mit 25 ein Zentralverarbeitungsabschnitt zum Verarbeiten verschiedener Typen der Berechnung. In der Figur ist auch mit der Bezugszahl 26 ein Protokollidentifizie­ rungsabschnitt bezeichnet zum Identifizieren eines Protokolls der empfangenen Daten, mit 27 ein Daten­ chiffrier-/Dechriffierabschnitt zum Chiffrieren/De­ chiffrieren der empfangenen Daten, mit 28 ein SAP- Verarbeitungsabschnitt zum Ändern eines Diensttyps von einem Nicht-Chiffrierdienst zu einem Chiffrier­ dienst, wenn der Typ ein SAP-Rahmen von einem An­ schluß ist, und zum Ändern des Diensttyps von einem Chiffrierdienst zu einem Nicht-Chiffrierdienst, wenn der Typ ein SAP-Rahmen von einem Netzwerk ist.
Als nächstes erfolgt die Beschreibung der Arbeitswei­ se. Gemäß Fig. 1 speichert der anschlußseitige Sen­ de/Empfangsabschnitt 21 in der Chiffriervorrichtung den empfangenen Rahmen in dem Rahmenspeicher 22. Der netzwerkseitige Sende/Empfangsabschnitt 23 speichert den empfangenen Rahmen in dem Rahmenspeicher 22. Der Protokollidentifizierungsabschnitt 26 identifiziert ein Protokoll eines Rahmens, sendet den Rahmen, wenn es ein RIP-Rahmen ist, und überträgt den Rahmen zu dem SAP-Verarbeitungsabschnitt 28 zur Steuerung, wenn es ein SAP-Rahmen ist.
Der SAP-Verarbeitungsabschnitt 28 wandelt einen Diensttyp 0 × 04 (Nicht-Chiffrierdienst), wenn er zum Beispiel einen SAP-Rahmen von dem Anschluß 1 emp­ fängt, um in einen Diensttyp 0 × abc (Chiffrier­ dienst), um über den netzwerkseitigen Sende/Empfangs­ abschnitt 23 zu dem Netzwerk 3 gesandt zu werden, wandelt den Diensttyp 0 × abc, wenn er einen SAP-Rah­ men von dem Netzwerk 3 empfängt, um in einen Dienst­ typ 0 × 04, setzt die Anzahl von Sprüngen auf 0 × 10, wenn es ein Diensttyp 0 × 04 ist, um über den an­ schlusseitigen Sende/Empfangsabschnitt 21 zu der An­ schlußseite 1 gesandt zu werden.
Ein Datenabschnitt (X11 in Fig. 2) von anderen Daten­ rahmen wird chiffriert/dechriffiert in dem Datenchif­ frier-/Dechiffrierabschnitt 27. Der netzwerkseitige Sende/Empfangsabschnitt 23 sendet die verarbeiteten Rahmen jeweils zu dem Netzwerk 3. Der Abschnitt 21 sendet auch den von dem anschlußseitigen Sende/Emp­ fangsabschnitt 21 empfangenen Rahmen zu einem An­ schluß, der nicht der Anschluß ist, zu welchem der Rahmen wie er ist übertragen wurde. Der Abschnitt 23 verarbeitet auch den von dem netzwerkseitigen Sende/­ Empfangsabschnitt 23 empfangenen Rahmen in derselben Weise wie vorstehend beschrieben, um den Rahmen von dem anschlußseitigen Sende/Empfangsabschnitt 21 zu der Anschlußseite 1 zu senden.
Dann zeigt Fig. 6 ein Beispiel der Netzwerkkonfigura­ tion in einem Fall, in welchem ein Kunde/Server bei demselben Netzwerk eine Kommunikation oder Chiffrie­ ren durchführt. In Fig. 6 ist mit dem Bezugszeichen 3a ein Netzwerk bezeichnet, mit 11s, 12s ein Server und mit 11c ein Kunde.
Mit der Bezugzahl 51 ist eine Servertabelle bezeich­ net, welche in dem Server 11s gespeichert ist, mit 52 eine Servertabelle, welche in dem Server 12s gespei­ chert ist, und jede der Servertabellen speichert Ser­ verinformationen wie einen Servernamen und einen Ser­ vertyp oder dergleichen.
Fig. 7 zeigt eine Folge, in welcher der Server peri­ odisch seine eigenen Serverinformationen aussendet. In der Figur sendet der Dateiserver 11s periodisch die eigenen Serverinformationen (den Servernamen 11s, Diensttyp 0 × 04) in dem Netzwerk 3a unter Verwendung des SAP-Rahmens aus (Schritt S11). Der Dateiserver 12s, der den SAP-Rahmen von dem Netzwerk 3a empfangen hat, setzt den Servernamen 11s und den Diensttyp 0 × 04, die jeweils in dem SAP-Rahmen enthalten sind, in der Servertabelle 52 (Schritt S12).
Der Dateiserver 12s sendet periodisch die eigenen Serverinformationen (den Servernamen 12s, Diensttyp 0 × 04) in dem Netzwerk 3a unter Verwendung des SAP- Rahmens aus (Schritt S13). Der Dateiserver 11s, der den SAP-Rahmen von dem Netzwerk 3a empfangen hat, setzt den Servernamen 12s und den Diensttyp 0 × 04, die jeweils in dem SAP-Rahmen enthalten sind, in der Servertabelle 51 (Schritt S14).
Dann zeigt Fig. 8 eine Folge, wenn der Kunde 11c sei­ nen Betrieb startet. In der Figur sendet der Kunde 11c einen SAP-Anfragerahmen der nächsten Dienstanfra­ ge, welche ein Diensttyp 0 × 04 ist, wenn sein Be­ trieb gestartet wird, an das Netzwerk 3a (Schritt S21).
Der Server 11s sendet, wenn er die SAP-Anfrage des Diensttyps 0 × 04 von dem Netzwerk 3a empfangen hat (Schritt S22), und da der empfangene Diensttyp iden­ tisch ist mit dem in dem Server 11s, einen SAP-Ant­ wortrahmen in den eigenen Serverinformationen (Ser­ vername 11s, Diensttyp 0 × 04) zu dem Kunden 11c (Schritt S23). Der Kunde 11c sendet zuerst, wenn er den Antwortrahmen von dem Dateiserver 11s empfangen hat (Schritt S24), einen RIP-Anfragerahmen dazu, um die Leitinformationen für den Server 11s zu erhalten, die in dem Antwortrahmen gesetzt sind (Schritt S31).
Wenn er den RIP-Anfragerahmen empfangen hat (Schritt S32), sendet der Server 11s eine Antwort zu dem Kun­ den (Schritt S33). Wenn der Kunde 11c den RIP-Ant­ wortrahmen empfängt (Schritt S34), werden danach Da­ tenrahmen zwischen dem Kunden 11c und dem Server 11s gesendet/empfangen (Schritte S41, S42).
Es ist festzustellen, daß der Dateiserver 12s den Anfragerahmen von dem Netzwerk 3a empfängt (Schritt S25), der Server 12s, der einen dem empfangenen iden­ tischen Dienst bereitstellt, sendet einen SAP-Ant­ wortrahmen in den eigenen Serverinformationen (Ser­ vername 12s, Diensttyp 0 × 04) (Schritt S26), und dann ignoriert der Kunde 11c den nach diesem Vorgang empfangenen Antwortrahmen (Schritt S27).
Wie vorbeschrieben ist, empfängt der Server 12s auch den im Schritt S21 in Fig. 8 zum Senden übertragenen SAP-Anfragerahmen und sendet die Antwort. Der Kunde startet eine Datenkommunikation entsprechend dem zu­ erst empfangenen Antwortrahmen in einem Fall, in wel­ chem er mehrere SAP-Antworten empfängt.
Zum Beispiel sendet der Kunde 11c in einem Fall, in welchem der mit dem Server 11s verbundene Kunde 11c eine Datenkommunikation auch mit dem Server 12s durchzuführen wünscht, eine RIP-Anfrage, um Adressen­ informationen für den Server 12s von dem damit ver­ bundenen Server 11s zu erhalten, und erhält die Adresseninformationen von der Antwort in der RIP-Ant­ wort auf die Anfrage, und beginnt dann die Kommunika­ tion mit dem Server 12s.
Es ist festzustellen, daß in einem Fall, in welchem die Adresseninformationen für den Server 12s nicht von dem Server 11s erhalten werden können, der Kunde 11c keine Kommunikation hiermit durchführen kann.
Fig. 9 zeigt ein Beispiel einer Netzwerkkonfiguration in einem Fall, in welchem ein Kunde und ein Server, jeweils in einem verschiedenen Netzwerk über eine Leiteinrichtung miteinander kommunizieren, ohne ir­ gendeine Information zu chiffrieren. In der Figur sind mit den Bezugszeichen 3a, 3b ein Netzwerk be­ zeichnet, mit 4a eine Leiteinrichtung, mit 11s ein Server, mit 11c ein Kunde, mit 51 eine durch die Leiteinrichtung 4a gespeicherte Servertabelle, und mit 52 ein durch den Server 11s gespeicherte Server­ tabelle.
Fig. 10 zeigt eine Folge, in welcher der Server 11s periodisch einen Antwortrahmen, enthaltend darin die eigenen Serverinformationen, zu dem Netzwerk 3b sen­ det. In Fig. 10 sendet der Dateiserver 11s periodisch die eigenen Serverinformationen in dem Netzwerk 3b unter Verwendung des SAP-Rahmens (Schritt S11) aus. Wenn die Leiteinrichtung 4a die Serverinformationen empfangen hat (Schritt S12), registriert diese in der eigenen Servertabelle 51 und sendet periodisch die Informationen zu dem anderen Netzwerk 3a (Schritt S13).
Fig. 11 zeigt eine Folge, wenn der Kunde 11c seinen Betrieb startet. In der Figur sendet der Kunde 11c einen SAP-Anfragerahmen der nächsten Dienstanfrage, welche ein Diensttyp 0 × 04 ist, zu dem Netzwerk 3a (Schritt S21). Die Leiteinrichtung 4a, wenn sie die SAP-Anfrage der nächsten Dienstanfrage von dem Netz­ werk 3a empfangen hat (Schritt S22), bezieht sich auf die Servertabelle 51 und sendet den Antwortrahmen, in welchem die Dateiserverinformationen für den Server­ namen 11s mit der kleinsten Anzahl von Sprüngen in dem Anfragediensttyp (0 × 04) gesetzt sind, zu dem Kunden 11c (Schritt S23). Der Kunde 11c sendet einen RIP-Anfragerahmen dazu (Schritt S31), um die in dem empfangenen Antwortrahmen gesetzten Leitinformationen für den Server 11s zu erhalten (Sehritt S24). Die Leiteinrichtung, die den RIP-Anfragerahmen empfangen hat (Schritt S32), sendet die Antwort zu dem Kunden (Schritt S33). Der Kunde 11c beginnt Kommunikationen (Schritte 541, 542, 543) entsprechend dem empfangenen RIP-Antwortrahmen (Schritt S34).
Fig. 12 zeigt ein Blockschaltbild eines Netzwerk­ systems, in welchem ein Server/ein Kunde jeweils ein Chiffriersystem haben und ein Server/ein Kunde je­ weils ein Nicht-Chiffriersystem haben, und die in demselben Netzwerk vorhanden sind. In Fig. 12 sind mit den Bezugszeichen 2a, 2b, 2c jeweils eine Chif­ friervorrichtung bezeichnet, mit 3a ein Netzwerk, mit 11c ein Kunde mit einem Nicht-Chiffriersystem, wel­ ches nicht mit irgendeiner der Chiffriervorrichtungen verbunden ist, mit 12c ein Kunde mit einem Chiffrier­ system, welches mit einer der Chiffriervorrichtungen verbunden ist, mit 11s ein Server mit einem Nicht- Chiffriersystem, welches nicht mit irgendeiner der Chiffriervorrichtungen verbunden ist, mit 12s, 13s ein Server, mit einem Chiffriersystem, welches je­ weils mit einer der Chiffriervorrichtungen verbunden ist. In der Figur sind auch mit der Bezugszahl 52 eine durch den Server 11s gespeicherte Servertabelle bezeichnet, mit 53 eine durch den Server 12s gespei­ cherte Servertabelle, mit 54 eine durch den Server 13s gespeicherte Servertabelle, und Serverinformatio­ nen wie ein Servername, ein Diensttyp und die Anzahl von Sprüngen oder dergleichen sind in jeder der Ser­ vertabellen gespeichert.
Fig. 13 zeigt eine Folge, in welcher in der Netzwerk­ konfiguration nach Fig. 12 der Server 11s mit einem Nicht-Chiffriersystem und die Server 12s, 13s jeweils mit einem Chiffriersystem periodisch jede der Serve­ rinformationen auf dem Netzwerk 3a aussenden, und jeder der Server empfängt die Serverinformationen von anderen Servern, um die eigene Servertabelle zu ak­ tualisieren.
In Fig. 13 sendet der Server 11s mit einem Nicht- Chiffriersystem Serverinformationen mit dem Serverna­ men 11s in dem Servertyp 0 × 04 zu den Servern auf dem Netzwerk 3a aus (Schritt S11).
Die Chiffriervorrichtung 2b setzt, wenn sie Serverin­ formationen für den Server 11s von dem Netzwerk 3a empfangen hat, die Anzahl von Sprüngen auf 0 × 10 (ein Wert, der den Umstand anzeigt, daß der Server 11s nicht brauchbar ist), um die Informationen zu dem Server 12s zu senden (Schritt S12). Der Server 12s bricht, wenn er die Serverinformationen für den Ser­ ver 11s von der Chiffriervorrichtung 2b empfangen hat, und da gefunden wird, daß die Anzahl von Sprün­ gen der Serverinformationen gleich 0 × 10 ist, die Serverinformationen ab, und er schreibt nicht die Serverinformationen für den Server 11s in die Server­ tabelle 53 in dem Server 12s (Schritt S13).
In gleicher Weise setzt die Chiffriervorrichtung 2c, wenn sie die Serverinformationen für den Server 11s von dem Netzwerk 3a empfangen hat, und da gefunden wird, daß der Diensttyp gleich 0 × 04 ist, die Zahl von Sprüngen auf 0 × 10 zum Senden der Informationen zu dem Server 13s (Schritt S14). Der Server 13s setzt, wenn er die Serverinformationen für den Server 11s von der Chiffriervorrichtung 2c empfangen hat, und da gefunden wird, daß die Anzahl von Sprüngen der Serverinformationen gleich 0 × 10 ist, die Serverin­ formationen ab und schreibt die Serverinformationen für den Server 11s nicht in die Servertabelle 54 in dem Server 13s (Schritt S15).
Dann sendet der Server 12s mit einem Chiffriersystem Serverinformationen wie den Servernamen 12s und den Diensttyp 0 × 04 aus (Schritt S21). Die Chiffriervor­ richtung 2b ändert den Diensttyp in den Diensttyp 0 × abc, welcher den Server mit einem Chiffriersystem anzeigt, um diesen zu dem Netzwerk 3a zu senden (Schritt S22). Der Server 11s, der die Serverinforma­ tionen für den Server 1s von dem Netzwerk 3a empfan­ gen hat, registriert den Servernamen 12s sowie den Diensttyp 0 × abc in der hierdurch gespeicherten Ser­ vertabelle 52 (Schritt S23).
Auch ändert die Chiffriervorrichtung 2c, wenn sie Serverinformationen für den Server 12s von dem Netz­ werk 3a empfangen hat, den Diensttyp 0 × abc der emp­ fangenen Serverinformationen in den Typ 0 × 04 zu dessen Ausgabe zu dem Server 13s (Schritt S24). Der Server 13s registriert, wenn er die Serverinformatio­ nen für den Server 12s von der Chiffriervorrichtung 2c empfangen hat, den Servernamen 12s sowie den Diensttyp 0 × 04 in der hierdurch gespeicherten Ser­ vertabelle 54 (Schritt S25).
Dann sendet der Server 13s mit einem Chiffriersystem Serverinformationen wie den Servernamen 13s und den Diensttyp 0 × 04 zu der Chiffriervorrichtung 2c (Schritt S31). Die Chiffriervorrichtung 2c wandelt den Diensttyp in den Diensttyp 0 × abc um, welcher den Server mit einem Chiffriersystem anzeigt, um ihn zu dem Netzwerk 3a zu senden (Schritt S32). Der Ser­ ver 12s mit einem Nicht-Chiffriersystem, der Serve­ rinformationen für den Server 13s von dem Netzwerk 3a empfangen hat, registriert den Servernamen 13s sowie die Diensttyp 0 × abc in der hierdurch gespeicherten Servertabelle 51 (Schritt S33). Die Chiffriervorrich­ tung 2b wandelt, wenn sie die Serverinformationen für den Server 13s von dem Netzwerk 3a empfangen hat, den Diensttyp 0 × abc der empfangenen Serverinformationen um in den Typ 0 × 04, um diesen zu dem Server 12s zu senden (Schritt S34). Der Server 12s registriert, wenn er die Serverinformationen für den Server 13s von der Chiffriervorrichtung 2b empfangen hat, den Servernamen sowie den Diensttyp 0 × 04 in der hier­ durch gespeicherten Servertabelle 53 (Schritt S35).
Wie vorbeschrieben ist, aktualisiert jeder der Server periodisch Informationen für andere Server.
Es folgt die Beschreibung mit Bezug auf Fig. 14 für eine Verarbeitungsfolge für den Kunden 12c mit einem Chiffriersystem von seiner Initialisierung bis zum Start von Kommunikationen mit dem Server 12s mit ei­ nem Chiffriersystem in dem in Fig. 12 gezeigten Sy­ stem.
Der Kunde 12c mit einem Chiffriersystem sendet einen SAP-Anfragerahmen für die Anfrage des nächsten Dien­ stes, welcher ein Diensttyp 0 × 04 ist, zu der Chif­ friervorrichtung 2a (Schritt S21). Die Chiffriervor­ richtung 2a ändert, wenn sie den SAP-Anfragerahmen für die Anfrage des nächsten Dienstes empfangen hat, welcher ein Diensttyp 0 × 04 hiervon ist, den Dienst­ typ 0 × 04 in den Diensttyp 0 × abc, um ihn zu dem Netzwerk 3a zu senden (Schritt S22). Der Server 11s mit einem Nicht-Chiffriersystem bricht die Anfrage ab, da der Diensttyp hiervon unterschiedlich gegen­ über dem Diensttyp des Servers 11s ist (hierin nicht gezeigt). Die Chiffriervorrichtung 2b ändert, wenn sie den SAP-Anfragerahmen für die Anfrage des näch­ sten Dienstes, welcher ein Diensttyp 0 × abc ist, von dem Netzwerk 3a empfangen hat, den Diensttyp hiervon in den Diensttyp 0 × 04, um diesen zu dem Server 12s mit einem Chiffriersystem zu senden (Schritt S23).
Wenn er die SAP-Anfrage über den nächsten Dienst, welcher ein Diensttyp 0 × 04 ist, empfangen hat (Schritt S24), sendet der Server 12s mit einem Chif­ friersystem die eigenen Serverinformationen des Diensttyps 0 × 04 mit dem Servernamen 12s als eine Antwort, da der empfangene Diensttyp derselbe ist wie der eigene Diensttyp (Schritt S25). Die Chiffriervor­ richtung 2b ändert, wenn sie die Antwort des Dienst­ typs 0 × 04 mit dem Servernamen 12s hat, den Dienst­ typ hiervon in den Diensttyp 0 × abc, um diesen zu dem Netzwerk 3a zu senden (Schritt S26). Die Chif­ friervorrichtung 2a ändert, wenn sie die Antwort des Diensttyps 0 × abc von dem Netzwerk 3a empfangen hat, den Diensttyp hiervon in den Diensttyp 0 × 04, um diesen zu dem Kunden 12c mit einem Chiffriersystem zu senden (Schritt S27). Der Kunde 12c mit einem Chif­ friersystem senden einen RIP-Anfragerahmen zu der Chiffriervorrichtung 2c (Schritt S31), um die Adresse des empfangenen Servers zu erhalten (Schritt S28). Die Chiffriervorrichtung 2a sendet die empfangene RIP-Anfrage so wie sie ist zu dem Netzwerk 3a (Schritt S32).
Die Chiffriervorrichtung 2b sendet die von dem Netz­ werk 3a empfangene RIP-Anfrage so wie sie ist zu dem Server 12s mit einem Chiffriersystem (Schritt S33). Der Server 12s mit einem Chiffriersystem sendet, wenn er die RIP-Anfrage empfangen hat (Schritt S34), die RIP-Antwort zu der Chiffriervorrichtung 2b (Schritt S35). Die Chiffriervorrichtung 2b sendet die empfan­ gene RIP-Antwort so wie sie ist zu dem Netzwerk 3a (Schritt S36). Die Chiffriervorrichtung 2a sendet die empfangene RIP-Antwort von dem Netzwerk 3a so wie sie ist zu dem Kunden 12c mit einem Chiffriersystem (Schritt S37). Der Kunde 12c mit einem Chiffriersy­ stem startet die Transaktion von Datenrahmen mit dem Server 12s mit einem Chiffriersystem gemäß der emp­ fangenen RIP-Antwort (Schritt S38). Das heißt, der Kunde 12c mit einem Chiffriersystem sendet einen Da­ tenrahmen zu dem Server 12s (Schritt S41). Die Chif­ friervorrichtung 2a chiffriert den Datenabschnitt X11 in dem empfangenen Datenrahmen, um ihn zu dem Netz­ werk 3a zu senden (Schritt S42). Die Chiffriervor­ richtung 2b codiert den Datenabschnitt X11 in dem empfangenen Datenrahmen, um ihn zu dem Server 12s mit einem Chiffriersystem zu senden (Schritt S43), und der Server 12s mit einem Chiffriersystem empfängt den Datenrahmen (Schritt S44).
Daten werden von dem Server 12s mit einem Chiffrier­ system zu dem Kunden 12c mit einem Chiffriersystem gesandt durch Verarbeiten der Daten unter Ausführung einer Folge vom Schritt S41 zum Schritt S44 in der umgekehrten Reihenfolge.
Fig. 15 zeigt eine Folge in einem Fall, in welchem der Server 11s mit einem Nicht-Chiffriersystem die von dem Kunden 12c mit einem Chiffriersystem gesandte SAP-Anfrage empfängt, wenn er in dem in Fig. 12 ge­ zeigten System initialisiert ist. Wenn der Kunde 12c mit einem Chiffriersystem einen SAP-Anfragerahmen für die Anfrage des nächsten Dienstes, welcher ein Diensttyp 0 × 04 ist, sendet, wenn er initialisiert ist (Schritt S21), ändert gemäß Fig. 15 die Chif­ friervorrichtung 2a den empfangenen Diensttyp in den Diensttyp 0 × abc, um ihn zu dem Netzwerk 3a zu sen­ den (Schritt S22). Der Server 11s mit einem Nicht- Chiffriersystem bricht die Anfrage ab, wenn er den SAP-Anfragerahmen für die Anfrage des nächsten Dien­ stes, welcher ein Diensttyp 0 × abc ist, von dem Netzwerk 3a empfängt, da der empfangene Diensttyp unterschiedlich gegenüber dem eigenen Diensttyp 0 × 04 ist (Schritt S23).
Umgekehrt zeigt Fig. 16 eine Folge in einem Fall, in welchem die Chiffriervorrichtung 2b, die den Server 12s mit einem Chiffriersystem aufnimmt, die von dem Kunden 11c mit einem Nicht-Chiffriersystem gesandte SAP-Anfrage, wenn er initialisiert wird, empfängt. Wenn der Kunde 11c mit einem Nicht-Chiffriersystem einen SAP-Anfragerahmen für die Anfrage des nächsten Dienstes, welcher ein Diensttyp 0 × 04 ist, sendet, wenn er initialisiert wird (Schritt S21), dann bricht gemäß Fig. 16 die Chiffriervorrichtung 2b, die diesen SAP-Anfragerahmen empfangen hat, die Anfrage ab, da der Diensttyp des empfangenen Rahmens unterschiedlich gegenüber dem eigenen Typ ist (Schritt S22).
Demgemäß kann irgendeiner der Kunden mit jeweils ei­ nem Nicht-Chiffriersystem nicht mit irgendeinem der Server mit jeweils einem Chiffriersystem verbunden werden, und es kann auch irgendeiner der Kunden mit jeweils einem Chiffriersystem nicht mit irgendeinem der Server mit jeweils einem Nicht-Chiffriersystem verbunden werden.
Fig. 17 zeigt ein Blockschaltbild eines Netzwerk­ systems, in welchem ein Server mit einem Chiffriersy­ stem sowie ein Server mit einem Nicht-Chiffriersystem bei dem identischen Netzwerk vorhanden sind, und ein Kunde mit einem Chiffriersystem sowie ein Kunde mit einem Nicht-Chiffriersystem sind bei unterschiedli­ chen Netzwerken vorhanden, die über ein Leiteinrich­ tung miteinander verbunden sind.
In Fig. 17 ist mit den Bezugszeichen 3a, 3b ein Netz­ werk bezeichnet, mit 4a eine Leiteinrichtung, mit 2a, 2b, 2c jeweils eine Chiffriervorrichtung, mit 11s ein Server mit einem Nicht-Chiffriersystem, mit 12s, 13s ein Server mit einem Chiffriersystem, mit 12c ein Kunde mit einem Chiffriersystem, mit 11c ein Kunde mit einem Chiffriersystem, mit 51 eine durch die Leiteinrichtung 4a gespeicherte Servertabelle, mit 52 eine durch den Server 11s gespeicherte Servertabelle und mit 53 eine durch den Server 12s gespeicherte Servertabelle. Es ist festzustellen, daß die Be­ schreibung der durch den Server 13s gespeicherten Servertabelle hier weggelassen ist.
In gleicher Weise wie bei dem Beispiel nach Fig. 12 senden der Server 11s mit einem Nicht-Chiffriersystem und Server 12s, 13s jeweils mit einem Chiffriersystem periodisch die eigenen Serverinformationen zu den Servern an dem Netzwerk unter Verwendung jeweils von SAP-Rahmen aus, und der Server 11s mit einem Nicht- Chiffriersystem sowie die Server 12s, 13s jeweils mit einem Chiffriersystem erhalten Serverinformationen jeweils von den empfangenen SAP-Rahmen (was durch die Bezugszahlen 52 und 53 in Fig. 17 angezeigt ist).
Die Leiteinrichtung 4a registriert die Serverinforma­ tionen in der Servertabelle 51 gemäß den SAP-Rahmen des Servers 11s mit einem Nicht-Chiffriersystem und der Server 12s, 13s jeweils mit einem Chiffriersy­ stem, die jeweils von dem Netzwerk 3b empfangen wur­ den. Das heißt, der Servername 11s und der Diensttyp 0 × 04 werden darin registriert entsprechend dem SAP- Rahmen des Servers 11s, der Servername 12s und der Diensttyp 0 × abc werden darin registriert entspre­ chend dem SAP-Rahmen des Servers 12s, und der Server­ name 13s und der Diensttyp 0 × abc werden darin regi­ striert entsprechend dem SAP-Rahmen des Servers 13s.
Fig. 18 zeigt eine Verarbeitungsfolge für den Kunden 12c mit einem Chiffriersystem von seiner Initialisie­ rung aus bis zum Start von Kommunikationen mit dem Server 12s mit einem Chiffriersystem.
In der Figur sendet der Kunde 12c mit einem Chif­ friersystem einen SAP-Anfragerahmen für die Anfrage des nächsten Dienstes, welcher ein Diensttyp 0 × 04 ist, wenn er initialisiert ist (Schritt S 21). Die Chiffriervorrichtung 2a ändert, wenn sie die SAP-An­ frage des Diensttypes 0 × 04 von der Kundenseite emp­ fangen hat, den empfangenen Diensttyp in den Dienst­ typ 0 × abc, um ihn zu dem Netzwerk 3a zu senden (Schritt S22).
Wenn die Leiteinrichtung 4a die SAP-Anfrage des Diensttypes 0 × abc empfangen hat (Schritt S23), be­ zieht sie sich auf die Servertabelle 51, erhält der Servernamen 12s mit der kleinsten Anzahl von Sprüngen und denselben Diensttyp 0 × abc wie den der SAP-An­ frage, um die Informationen für den Server 12s mit einem Chiffriersystem als die SAP-Antwort zu dem Netzwerk zu senden (Schritt S24). Die Chiffriervor­ richtung 2a ändert, wenn sie die Serverinformationen des Diensttyps 0 × abc von der Netzwerkseite empfan­ gen hat, den empfangenen Diensttyp in den Diensttyp 0 × 04, um ihn zu dem Kunden 12c mit einem Chiffrier­ system zu senden (Schritt S25), und der Kunde 12c mit einem Chiffriersystem empfängt die Informationen (Schritt S26). Der Kunde 12c mit einem Chiffriersy­ stem sendet einen RIP-Anfragerahmen zu der Chiffrier­ vorrichtung 2a (Schritt S31), um die Adresse des emp­ fangenen Servers 12s zu erhalten. Die Chiffriervor­ richtung 2a sendet den empfangenen RIP-Rahmen zu dem Netzwerk 3a so wie er ist (Schritt S32).
Die Leiteinrichtung 4a empfängt die RIP-Anfrage von der Chiffriervorrichtung 2a durch das Netzwerk 3a (Schritt S33) und sendet die Antwort zu dem Netzwerk 3a (Schritt S34). Die Chiffriervorrichtung 2a sendet die RIP-Antwort von dem Netzwerk 3a zu dem Kunden 12c mit einem Chiffriersystem so wie sie ist (Schritt S35), und der Kunde 12c mit einem Chiffriersystem empfängt die RIP-Antwort (Schritt S36). Der Kunde 12c mit einem Chiffriersystem beginnt eine Kommunikation mit dem Server mit einem Chiffriersystem (Schritt S41). Das heißt, die Chiffriervorrichtung 2a sendet den Datenabschnitt X11 in dem Datenrahmen durch Chif­ frieren von diesem (Schritt S42) zu der Leiteinrich­ tung 4a. Die Leiteinrichtung 4a sendet den Rahmen zu der Empfängeradresse gemäß der Leittabelle (Schritt S43). Die Chiffriervorrichtung 2b dechiffriert den Datenabschnitt X11 in dem empfangenen Datenrahmen, der zu dem Server mit einem Chiffriersystem zu senden ist (Schritt S44), und der Server mit einem Chif­ friersystem empfängt den dechiffrierten Datenrahmen (Schritt S45).
Daten werden von dem Server 12s mit einem Chiffrier­ system zu dem Kunden 12c mit einem Chiffriersystem gesandt durch Verarbeiten der Daten vom Schritt S41 zum Schritt S45 in der umgekehrten Reihenfolge.
Der Kunde 12c mit einem Chiffriersystem kann nicht zum Server 11s mit einem Nicht-Chiffriersystem zu­ greifen, da der Server 12s mit einem Chiffriersystem nicht die Informationen für den Server 11s mit einem Nicht-Chiffriersystem in der eigenen Servertabelle 53 speichert.
Wie vorbeschrieben ist, ist es möglich, indem nicht die RIP/SAP-Rahmen chiffriert werden, der Diensttyp eines Servers in ein Chiffriersystem und ein Nicht- Chiffriersystem geteilt wird, und andere Datenrahmen chiffriert werden, eine Cryptokommunikation über ein Netzwerk durchzuführen, in welchem Kunden/Server je­ weils mit einem Chiffriersystem und Kunden/Server jeweils mit einem Nicht-Chiffriersystem gemischt sind.
Weiterhin ist es möglich, eine geschlossene Gruppe mit einer Chiffrierung zu konstruieren, indem mehrere Werte verwendet werden, die dieser zugewiesen sind als ein Diensttyp des Servers mit einem Chiffriersy­ stem bei dem identischen Netzwerk. Fig. 19 zeigt die Systemkonfiguration. In Fig. 19 ist mit dem Bezugs­ zeichen 11c ein Kunde mit einem Nicht-Chiffriersystem bezeichnet, mit 12c, 13c ein Kunde jeweils mit einem Chiffriersystem, mit 11s ein Dateiserver mit einem Nicht-Chiffriersystem, und mit 12s, 13s ein Dateiser­ ver jeweils mit einem Chiffriersystem. Ein Diensttyp 0 × abc wird in jeder der Chiffriervorrichtungen 2a, 2b gesetzt als ein Diensttyp für eine Umwandlung, und 0 × def wird in jeder der Chiffriervorrichtungen 2c, 2d gesetzt, wodurch der Kunde und der Server, die jeweils denselben Diensttyp haben, miteinander kom­ munizieren können. Wenn demgemäß die Diensttypen je­ weils mit einem Chiffriersystem Chiffrierschlüsseln entsprechen, können mehrere chiffrierte Gruppe kon­ struiert werdend.
Bei dem Ausführungsbeispiel wird ein Beispiel zur Anwendung der vorliegenden Erfindung auf das NetWare beschrieben, aber dieselbe Wirkung kann erhalten wer­ den in einem anderen Protokoll, bei welchem Leitin­ formationen zwischen einem Server und einem Kunden zur Übertragung von Rahmen ausgetauscht werden, der Kunde mit dem Server durch Austausch von Serverinfor­ mationen zwischen diesen verbunden ist, und die Ver­ bindung des Kunden hiermit periodisch zwischen dem Server und dem Kunden geprüft wird.
Obgleich ein Chiffriersystem und ein Nicht-Chiffrier­ system gemäß dem ersten Ausführungsbeispiel durch den Diensttyp voneinander unterschieden werden, können ein mit der Chiffriervorrichtung verbundener Kunde und ein Server mit einem Nicht-Chiffriersystem mit­ einander verbunden werden, indem eine transparente Verarbeitungsadressentabelle vorgesehen wird zum Be­ stimmen, ob ein Chiffrieren oder Codieren auszuführen ist oder nicht in Übereinstimmung mit einem Empfän­ gerserver in der Chiffriervorrichtung, welche Kunden darin aufnimmt zusätzlich zu den darin vorgesehenen Diensttypen, und indem eine transparente Verarbei­ tungsservertabelle vorgesehen wird zum Speichern von Servern jeweils mit einem Nicht-Chiffriersystem in der Chiffriervorrichtung, in welcher Server aufgenom­ men sind.
In dem NetWare ist ein Kunde mit einem Server verbun­ den, wenn er initialisiert wird, und er stellt eine Verbindung her mit mehreren Servern, wobei der vor­ beschriebenen Server als ein Basisserver verwendet wird, und er kann Kommunikationen mit diesen durch­ führen. In einem Fall, in welchem der Kunde eine Ver­ bindung mit einem anderen Server herzustellen hat, bestimmt der Kunde einen Servernamen, um Adressenin­ formationen (eine Netzwerkzahl SP6 und eine Knoten­ zahl SP7 in Fig. 5) für einen Server zu erhalten an einer Bestimmung für die Verbindung von dem Basisser­ ver. Der Kunde sende eine RIP-Anfrage für die Netz­ werkzahl SP6 zu dem Basisserver nach dem Empfang der Adresseninformationen. Der Kunde stellt eine Verbin­ dung her mit dem Server nach dem Empfang der RIP-Ant­ wort. Wenn der Basisserver nicht die Adresseninforma­ tionen für den Server an einer Bestimmung für die Verbindung speichert, kann der Kunde keine Verbindung hiermit herstellen. Bei diesem Ausführungsbeispiel können Nicht-Cryptokommunikationen ausgeführt werden zwischen einem Kunden mit einer hiermit verbundenen Chiffriervorrichtung und einem Server ohne einer hiermit verbundenen Chiffriervorrichtung durch Setzen von Informationen, ob eine Chiffrierung oder Dechif­ frierung durchzuführen ist oder nicht in der Chif­ friervorrichtung gemäß einer Empfängeradresse.
Fig. 20 zeigt eine Konfiguration der Chiffriervor­ richtung gemäß dem Ausführungsbeispiel nach der vor­ liegenden Erfindung. In Fig. 20 zeigt die Bezugszahl 30 eine transparente Verarbeitungsadressentabelle an und die Bezugszahl 31 zeigt eine transparente Verar­ beitungsservertabelle an. Die Bezugszahl 27 zeigt einen Datenchiffrier-/Dechiffrierabschnitt an, und der Abschnitt chiffriert/dechiffriert nicht Daten, wenn die in dem Datenrahmen enthaltene Adresse eines Empfangsservers in der transparenten Verarbeitungs­ adressentabelle 30 registriert ist, und chiffriert und dechiffriert die Daten, wenn die Daten nicht dar­ in registriert sind.
Die Bezugszahl 28 zeigt einen SAP-Verarbeitungsab­ schnitt an, welcher den SAP-Rahmen so wie er ist sen­ det, wenn der Server mit in dem von einer Netzwerk­ seite empfangenen SAP-Rahmen enthaltenen Serverinfor­ mationen in der transparenten Verarbeitungsserverta­ belle 31 registriert ist, und den SAP-Rahmen ab­ bricht, wenn er nicht darin registriert ist.
Die Bezugszahlen 1 bis 3 und 21 bis 26 in Fig. 20 sind dieselben wie diejenigen beim ersten Ausfüh­ rungsbeispiel (Fig. 1), so daß hier auf ihre Be­ schreibung verzichtet wird.
Fig. 21 zeigt die Konfiguration eines Kommunikations­ systems. In dieser Figur zeigt das Bezugszeichen 30a eine transparente Verarbeitungsadressentabelle an (die Bezugszahl 30 in Fig. 20), welche Adressen für Empfängerserver speichert, und die Tabelle wird von der Chiffriervorrichtung 2a gespeichert, welche Kun­ den aufnimmt. In diesem Beispiel wird die Adresse für den Empfängerserver 11s in der transparenten Verar­ beitungsadressentabelle 30a gespeichert, was bedeu­ tet, daß die Chiffriervorrichtung 2a den zu dem Ser­ ver 11s adressierten Rahmen nicht chiffriert oder codiert.
Das Bezugszeichen 31b zeigt eine transparente Verar­ beitungssservertabelle an (die Bezugszahl 31 in Fig. 20), welche die Namen von Servern speichert, und die Tabelle wird in der Chiffriervorrichtung 2b gespei­ chert, welche Server aufnimmt. In diesem Beispiel speichert die Chiffriervorrichtung 2b den Servernamen 11s in der transparenten Verarbeitungsservertabelle 31b hiervon. Die Tatsache, daß der Servername 11s in der transparenten Verarbeitungssservertabelle 31b registriert ist, bedeutet, daß die Chiffriervorrich­ tung 2a eine transparente Verarbeitung an den Daten durchführt ohne Änderung des Diensttyps des SAP-Ant­ wortrahmens von dem Server 11s in irgendeinen anderen Typ, und auch ohne Änderung der Anzahl von Sprüngen (Hops). Da die Chiffriervorrichtung 2c keinen Server hat, um eine transparente Verarbeitung auszuführen, werden Namen von Servern nicht in einer transparenten Verarbeitungsservertabelle 31c gespeichert. Es ist festzustellen, daß das Bezugszeichen 11s einen Server für Nicht-Chiffrierung anzeigt, das Bezugszeichen 12s einen Server für eine Chiffrierung mit dem Diensttyp 0 × abc anzeigt, und das Bezugszeichen 13s einen Ser­ ver für eine Chiffrierung mit dem Diensttyp 0 × def anzeigt.
Die Bezugszeichen 11c, 12c, 13c, 11s, 12s, 13s, 3a, 3b, 4a, 51 bis 54 sind dieselben wie diejenigen in Fig. 19, so daß ihre Beschreibung hier weggelassen wird.
Fig. 22 zeigt eine Folge, in welcher jeder der Server 11s, 12s, 13s periodisch eigene Serverinformationen zu dem Netzwerk in dem in Fig. 21 gezeigten System sendet.
In der Figur sendet der Server 11s periodisch eigene Informationen aus (Schritt S11). Die Chiffriervor­ richtung 2b empfängt Informationen für den Server 11s von dem netzwerkseitigen Sende/Empfangsabschnitt, speichert die Informationen in dem Rahmenspeicher (die Bezugzahl 22 in Fig. 20), um sie zu dem Proto­ kollidentifizierungsabschnitt (die Bezugszahl 26 in Fig. 20) zu übertragen. Die Informationen werden durch den Protokollidentifizierungsabschnitt als ein SAP-Rahmen identifiziert für eine Übertragung zu ei­ nem SAP-Verarbeitungsabschnitt (die Bezugszahl 28 in Fig. 20). Der SAP-Verarbeitungsabschnitt sucht in der transparenten Verarbeitungsservertabelle 31b (die Bezugszahl 31 in Fig. 20), und es wird gefunden, daß der Server 11s darin registriert ist, so daß der Rah­ men zu dem anschlußseitigen Sende/Empfangsabschnitt (die Bezugszahl 21 in Fig. 20) so wie er ist gesandt wird. Der Server 12s empfängt Informationen für der Server 11s und registriert den Servernamen 11s und den Diensttyp 0 × 04 in der Servertabelle 53 (Schritt S13).
Die Chiffriervorrichtung 2c empfängt die Informatio­ nen für den Server 11s von dem netzwerkseitigen Sen­ de/Empfangsabschnitt (die Bezugszahl 23 in Fig. 20) und speichert die Informationen in dem Rahmenspeicher (die Bezugszahl 22 in Fig. 20), um sie 2u dem Proto­ kollidentifizierungsabschnitt (die Bezugszahl 26 in Fig. 20) zu übertragen. Die Informationen werden von dem Protokollidentifizierungsabschnitt als ein SAP- Rahmen identifiziert für eine Übertragung zu dem SAP- Verarbeitungsabschnitt (die Bezugszahl 28 in Fig. 20). Der SAP-Verarbeitungsabschnitt sucht in der transparenten Verarbeitungsservertabelle 31c (die Bezugszahl 31 in Fig. 20), und es wird nicht gefun­ den, daß der Server 11s darin registriert ist, so daß die Anzahl von Sprüngen (Hops) auf 0 × 10 geändert wird (Außerbetrieb-Serverinformationen), und die ge­ änderten Informationen werden von dem anschlußseiti­ gen Sende/Empfangsabschnitt (die Bezugszahl 21 in Fig. 20) zu dem Anschluß gesandt (Schritt S14). Der Server 13s bricht die Informationen für den Server 11s ab, da die Zahl von Sprüngen gleich 0 × 10 ist, welches ein ungültiger Wert ist (Schritt S15).
Der Server 12s sendet periodisch eigene Informationen aus (Schritt S16). Die Chiffriervorrichtung 2b emp­ fängt Informationen für den Server 12s von dem an­ schlußseitigen Sende/Empfangsabschnitt und speichert die Informationen in dem Rahmenspeicher (die Bezugs­ zahl 22 in Fig. 20), um sie zu dem Protokollidentifi­ zierungsabschnitt (die Bezugszahl 26 in Fig. 20) zu übertragen. Die Informationen werden von dem Proto­ kollidentifizierungsabschnitt als ein SAP-Rahmen identifiziert zur Übertragung zu dem SAP-Verarbei­ tungsabschnitt (die Bezugszahl 28 in Fig. 20). Der SAP-Verarbeitungsabschnitt ändert den empfangenen Diensttyp in den Diensttyp 0 × abc, um ihn zu dem anschlußseitigen Sende/Empfangsabschnitt (die Bezugs­ zahl 21 in Fig. 20) zu senden (Schritt S17). Der Ser­ ver 11s empfängt Informationen für den Server 12s und registriert sie als der Servername 12s und den Diensttyp 0 × abc in der Servertabelle 52 (Schritt S18).
Die Chiffriervorrichtung 2c empfängt die Informatio­ nen für den Server 12s von dem netzwerkseitigen Sen­ de/Empfangsabschnitt (die Bezugszahl 23 in Fig. 20) und speichert die Informationen in dem Rahmenspeicher (die Bezugszahl 22 in Fig. 20), um sie zu dem Proto­ kollidentifizierungsabschnitt (die Bezugszahl 26 in Fig. 20) zu übertragen. Die Informationen werden von dem Protokollidentifizierungsabschnitt als ein SAP- Rahmen identifiziert zur Übertragung zu dem SAP-Ver­ arbeitungsabschnitt (die Bezugszahl 28 in Fig. 20). Der SAP-Verarbeitungsabschnitt bestimmt, daß die In­ formationen so wie sie sind zu senden sind, und die Informationen werden von dem anschlußseitigen Sende/­ Empfangsabschnitt (die Bezugszahl 21 in Fig. 20) so wie sie sind zu dem Anschluß gesandt (Schritt S19). Der Server 13s empfängt die Informationen für den Server 12s und registriert den Servernamen 12s und den Diensttyp 0 × abc in der Servertabelle 54 (Schritt S20).
Der Server 13s sendet periodisch den Servernamen 13s und den Diensttyp 0 × def als eigene Serverinforma­ tionen aus entsprechend derselben Folge des Servers 13s wie der des Servers 12s, und der Server 11s regi­ striert die Informationen für den Server 13s in der Servertabelle 52, während der Server 12s diese in der Servertabelle 53 registriert.
Fig. 23 zeigt eine Folge, in welcher ein Kunde mit einem Chiffriersystem Kommunikationen mit einem Ser­ ver mit einem Nicht-Chiffriersystem ausführt mit ei­ nem Server mit einem Chiffriersystem als ein Basis­ server. In der Figur führt der Kunde 12c mit einem Chiffriersystem eine Verarbeitung aus entsprechend der in Fig. 18 gezeigten Folge (Schritt S21), wenn er initialisiert ist zur Verbindung mit dem Server 12s mit einem Chiffriersystem.
Der Kunde 12c setzt eine Anfrage für Adresseninforma­ tionend für den Server 11s, der eine Verbindung mit dem Basisserver 12s hergestellt hat in dem Datenab­ schnitt X11 des Datenrahmens, um ihn zu dem Server 12s zu senden (Schritt S51).
Die Chiffriervorrichtung 2a speichert den von dem anschlußseitigen Sende/Empfangsabschnitt (die Bezugs­ zahl 21 in Fig. 20) empfangenen Rahmen in dem Rahmen­ speicher (die Bezugszahl 22 in Fig. 20), und der Rah­ men wird von dem Protokollidentifizierungsabschnitt (die Bezugszahl 26 in Fig. 20) identifiziert als ein Datenrahmen zur Übertragung zu dem Datenchiffrier-/ Dechiffrierabschnitt (die Bezugszahl 27 in Fig. 20). Der Datenchiffrier-/Dechiffrierabschnitt (die Bezugs­ zahl 27 in Fig. 20). Der Datenchiffrier-/Dechiffrier­ abschnitt sucht in der transparenten Verarbeitungs­ adresssentabelle 30a (die Bezugszahl 30 in Fig. 20), und es wird nicht gefunden, daß der Basisserver 12s darin registriert ist, so daß der Datenabschnitt X11 chiffriert wird, um von dem netzwerkseitigen Sende/­ Empfangsabschnitt (die Bezugszahl 23 in Fig. 20) ge­ sandt zu werden (Schritt S52). Die Leiteinrichtung 4a überträgt den Datenrahmen (Schritt S53).
Die Chiffriervorrichtung 2b speichert den von dem netzwerkseitigen Sende/Empfangsabschnitt (die Bezugs­ zahl 23 in Fig. 20) empfangenen Rahmen in dem Rahmen­ speicher (die Bezugszahl 22 in Fig. 20), und der Rah­ men wird von dem Protokollidentifizierungsabschnitt (die Bezugszahl 26 in Fig. 20) identifiziert als ein Datenrahmen zur Übertragung zu dem Datenchiffrier- /Dechiffrierabschnitt (die Bezugszahl 27 in Fig. 20). Der Datenchiffrier-/Dechiffrierabschnitt dechiffriert den Datenabschnitt mit X11 (da die Server aufnehmende Chiffriervorrichtung nicht die transparente Verarbei­ tungsadressentabelle 30 hat) um ihn von dem anschluß­ seitigen Sende/Empfangsabschnitt (die Bezugszahl 21 in Fig. 20) zu dem Anschluß zu senden (Schritt S54). Der Basisserver 12s sucht, wenn er die Anfrage für die Adresse des Servers 11s empfangen hat (Schritt S55), in seiner eigenen Servertabelle 53 und erhält die gespeicherten Serverinformationen für den Server 11s, um die Antwort für die Adresse des Servers 11s zu der Vorrichtung 2b zu senden (Schritt S56).
Die Chiffriervorrichtung 2b speichert den von dem anschlußseitigen Sende/Empfangsabschnitt (die Bezugs­ zahl 21 in Fig. 20) empfangenen Rahmen in dem Rahmen­ speicher (die Bezugszahl 22 in Fig. 20), und der Rah­ men wird von dem Protokollidentifizierungsabschnitt die Bezugszahl 26 in Fig. 20) identifiziert als ein Datenrahmen zur Übertragung zu dem Datenchiffrier- /Dechiffrierabschnitt (die Bezugszahl 27 in Fig. 20). Der Datenchiffrier-/Dechiffrierabschnitt chiffriert den Datenabschnitt X11 (da die Server aufnehmende Chiffriervorrichtung nicht die transparente Verarbei­ tungsadressentabelle 30 hat), um ihn von dem an­ schlußseitigen Sende/Empfangsabschnitt (die Bezugs­ zahl 21 in Fig. 20) zu dem Anschluß zu senden (Schritt S57).
Die Leiteinrichtung 4a überträgt den empfangenen Da­ tenrahmen (Schritt S58). Die Chiffriervorrichtung 2a speichert den von dem netzwerkseitigen Sende/Emp­ fangsabschnitt (die Bezugszahl 23 in Fig. 20 empfan­ genen Rahmen in dem Rahmenspeicher (die Bezugszahl 22 in Fig. 20), und der Rahmen wird von dem Protokoll­ lidentifizierungsabschnitt (die Bezugszahl 26 in Fig. 20) als ein Datenrahmen identifiziert für die Über­ tragung zu dem Datenchiffrier-/Dechiffrierabschnitt (die Bezugszahl 27 in Fig. 20). Der Datenchiffrier- /Dechiffrierabschnitt sucht in der transparenten Ver­ arbeitungsadressentabelle 30a (die Bezugszahl 30 in Fig. 20), und es wird nicht darin gefunden, daß der Server 12s registriert ist, so daß der Datenabschnitt X11 dechiffriert wird, um von dem anschlußseitigen Sende/Empfangsabschnitt (die Bezugszahl 21 in Fig. 20) zu dem Anschluß gesandt zu werden (Schritt S59). Der Kunde 12c empfängt die Informationen für den Ser­ ver 11s und sendet eine RIP-Anfrage für die Adresse des Servers 11s an die Vorrichtung 2a (Schritt S31).
Die Chiffriervorrichtung 2a speichert den von dem anschlußseitigen Sende/Empfangsabschnitt (die Bezugs­ zahl 21 in Fig. 20) empfangenen Rahmen in dem Rahmen­ speicher (die Bezugszahl 22 in Fig. 20), und der Rah­ men wird von dem Protokollidentifizierungsabschnitt (die Bezugszahl 26 in Fig. 20) als ein RIP-Rahmen identifiziert zum Senden von dem netzwerkseitigen Sende/Empfangsabschnitt (die Bezugszahl 23 in Fig. 20) zu dem Anschluß (Schritt S32). Die Leiteinrich­ tung 4a sucht, wenn sie die RIP-Anfrage erhalten hat (Schritt S33), in der Leittabelle und sendet die Ant­ wort zu der Chiffriervorrichtung 2a (Schritt S34).
Die Chiffriervorrichtung 2a speichert den von dem netzwerkseitigen Sende/Empfangsabschnitt (die Bezugs­ zahl 23 in Fig. 20) empfangenen Rahmen in dem Rahmen­ speicher (die Bezugszahl 22 in Fig. 20), und der Rah­ men wird von dem Protokollidentifizierungsabschnitt (die Bezugszahl 26 in Fig. 20) als ein RIP-Rahmen identifiziert zur Übertragung von dem anschlußseiti­ gen Sende/Empfangsabschnitt (die Bezugszahl 21 in Fig. 20) zu dem Anschluß (Schritt S35). Der Kunde 12c empfängt die RIP-Antwort (Schritt S36). Der Kunde 12c mit einem Chiffriersystem beginnt die Kommunikation mit dem Server 11s mit einem Nicht-Chiffriersystem (Schritt S46).
Die Chiffriervorrichtung 2a speichert den Rahmen für den Server 11s mit einem Nicht-Chiffriersystem, der von dem anschlußseitigen Sende/Empfangsabschnitt emp­ fangen wurde, in dem Rahmenspeicher (die Bezugszahl 22 in Fig. 20). Der darin gespeicherte Rahmen wird von dem Protokollidentifizierungsabschnitt (die Be­ zugszahl 26 in Fig. 20) identifiziert als ein Daten­ rahmen zur Übertragung zu dem Datenchiffrier-/Dechif­ frierabschnitt (die Bezugszahl 27 in Fig. 20). Der Datenchiffrier-/Dechiffrierabschnitt sucht in der transparenten Verarbeitungsadressentabelle 30a (die Bezugszahl 30 in Fig. 20), und es wird darin gefun­ den, daß die Adresse des Servers 11s registriert ist, so daß der Datenabschnitt X11 von dem netzwerkseiti­ gen Sende/Empfangsabschnitt (die Bezugszahl 23 in Fig. 20) zu dem Netzwerk gesendet wird, ohne chif­ friert zu werden (Schritt S47). Die Chiffriervorrich­ tung 2a sendet den von dem Server 11s empfangenen Datenrahmen so wie er ist zu dem Netzwerk 3a, ohne ihn zu dechiffrieren, da der Server 11s in der trans­ parenten Verarbeitungsadressentabelle 30a registriert ist, und die Leiteinrichtung 4a überträgt den Daten­ rahmen zu dem Netzwerk 3b (Schritt S48). Der Server 11s mit einem Nicht-Chiffriersystem empfängt den Da­ tenrahmen von dem Netzwerk 3b (Schritt S49).
Wie vorbeschrieben ist, führt der Kunde 12c mit einem Chiffriersystem Kryptokommunikationen mit dem Server 12s mit einem Chiffriersystem durch, und er kann auch Nicht-Cryptokommunikationen mit dem Server 11s mit einem Nicht-Chiffriersystem durchführen.
Obgleich ein Chiffriersystem und ein Nicht-Chiffrier­ system in dem Diensttyp gemäß dem ersten Ausführungs­ beispiel voneinander unterschieden werden, werden bei diesem Ausführungsbeispiel beide Systeme entsprechend der Anzahl von Sprüngen (Hops) voneinander unter­ schieden.
Fig. 24 zeigt die Konfiguration der Chiffriervorrich­ tung. In Fig. 24 zeigt die Bezugszahl 32 einen Spei­ cher für die Anzahl von Sprüngen an, welcher die An­ zahl von zu der von der Anschlußseite empfangenen SAP-Antwort zu addierenden Sprüngen speichert. Die Bezugszahl 33 zeigt eine Serverinformationstabelle an, welche Serverinformationen für die zu verbinden­ den Server speichert, die jeweils vorher darin regi­ striert wurden als erforderlich für SAP-Anfragen für den nächsten Dienst, die von dem Anschluß empfangen wurden.
Die Bezugszahl 28 zeigt einen SAP-Verarbeitungsab­ schnitt an, welcher die in der Serverinformationsta­ belle 33 gespeicherten Serverinformationen zu der Anschlußseite sendet als eine SAP-Antwort in einem Fall, in welchem er die SAP-Anfrage für den nächsten Dienst von der Anschlußseite empfängt, und er bricht die SAP-Anfrage ab in einem Fall, in welchem er die SAP-Anfrage über den nächsten Dienst von dem Netzwerk empfängt.
Der SAP-Verarbeitungsabschnitt 28 addiert auch in einem Fall, in welchem er eine SAP-Antwort von der Anschlußseite empfängt, den Inhalt des Speichers 32 für die Anzahl von Sprüngen zu der Anzahl von Sprün­ gen, die in der SAP-Antwort enthalten ist, um sie zu der Netzwerkseite zu senden. Andere Abschnitte in Fig. 24 sind dieselben wie diejenigen in Fig. 1, so daß ihre Beschreibung hier weggelassen wird.
Fig. 25 zeigt die Konfiguration des Netzwerksystems. In Fig. 25 sind die Bezugszeichen 11c, 12c, 11s, 12s, 13s, 2a, 2b, 2c, 3a, 3b, 4a, 51 bis 53 dieselben wie diejenigen in Fig. 21. Die Bezugszahl 33 ist dieselbe wie die in Fig. 24, welche eine Serverinformations­ tabelle anzeigt, die erforderlich ist für eine SAP- Anfrage nach dem nächsten Dienst in der Chiffriervor­ richtung 2a, nämlich eine Tabelle zum Speichern von Serverinformationen für den Server, mit welchem die Vorrichtung 2a verbunden wird, wenn sie initialisiert wird, und in diesem Ausführungsbeispiel wird ein Fall angenommen, in welchem Informationen für der Server 12s mit einem Chiffriersystem (Servername 12s, Diensttyp 0 × 04, die Anzahl von Sprüngen 0 × 02) registriert sind in den Serverinformationen für die Anfrage nach dem nächsten Dienst, die von dem An­ schluß der Chiffriervorrichtung 2a gesandt wurde.
Die Bezugszahl 32 ist dieselbe wie die in Fig. 24, welche einen Speicher für die Anzahl von Sprüngen anzeigt zum Speichern der Anzahl von Sprüngen, die zu einer SAP-Antwort von der Chiffriervorrichtung 2b zu addieren sind, und es wird ein Beispiel zur Regi­ strierung von 5 darin angenommen.
Als nächstes erfolgt die Beschreibung der Arbeitswei­ se. Bei der Konfiguration des Netzwerksystems nach Fig. 25 zeigt Fig. 26 eine Folge, bei welcher jeder der Server 11s, 12s, 13s periodisch Serverinformatio­ nen zu dem Netzwerk sendet.
In der Figur sendet der Server 11s mit einem Nicht- Chiffriersystem periodisch die Serverinformationen zu dem Netzwerk aus wie den Servernamen 11s, den Dienst­ typ 0 × 04, die Anzahl von Sprüngen 0 × 01 (Schritt S11). Die Chiffriervorrichtung 2b speichert den von dem netzwerkseitigen Sende/Empfangsabschnitt (die Bezugszahl 23 in Fig. 24) empfangenen Rahmen in dem Rahmenspeicher (die Bezugszahl 22 in Fig. 24), und der Rahmen wird von dem Protokollidentifizierungsab­ schnitt (die Bezugszahl 26 in Fig. 24) als ein SAP- Rahmen identifiziert zur Übertragung zu dem SAP-Ver­ arbeitungsabschnitt (die Bezugszahl 28 in Fig. 24). Der SAP-Verarbeitungsabschnitt bestimmt, daß der Rah­ men so wie er ist zu senden ist, und der Rahmen wird von dem anschlußseitigen Sende/Empfangsabschnitt (die Bezugszahl 21 in Fig. 24) zu dem Anschluß, nämlich zu dem Server 12s mit einem Chiffriersystem gesandt (Schritt S12).
Der Server 12s mit einem Chiffriersystem empfängt die Serverinformationen hiervon und registriert die Ser­ verinformationen wie den Servernamen 11s, den Dienst­ typ 0 × 04 und den die Anzahl von Sprüngen 0 × 01 in der Servertabelle 53 (Schritt S13).
Die Chiffriervorrichtung 2c sendet den Rahmen so wie er ist wie der in der Chiffriervorrichtung 2b zu dem Server 13s (Schritt S14). Der Server 13s mit einem Chiffriersystem empfängt die Serverinformationen hiervon und registriert die Serverinformationen wie den Servernamen 11s, den Diensttyp 0 × 04 und die Anzahl von Sprüngen 0 × 01 in der Servertabelle (Schritt S15).
Der Server 12s mit einem Chiffriersystem sendet peri­ odisch die eigenen Serverinformationen aus wie den Servernamen 12s, den Diensttyp 0 × 04 und die Anzahl von Sprüngen 0 × 01 (Schritt S16).
Die Chiffriervorrichtung 2b speichert den von dem anschlußseitigen Sende/Empfangsabschnitt (die Bezugs­ zahl 21 in Fig. 24) empfangenen Rahmen in dem Rahmen­ speicher (die Bezugszahl 22 in Fig. 24), und der Rah­ men wird von dem Protokollidentifizierungsabschnitt (die Bezugszahl 26 in Fig. 24) identifiziert als ein SAP-Rahmen zur Übertragung zu dem SAP-Verarbeitungs­ abschnitt (die Bezugszahl 28 in Fig. 24). Der SAP- Verarbeitungsabschnitt addiert die in dem Speicher 32 registrierte Anzahl von Sprüngen (5 in diesem Fall) zu den Dateiserverinformationen von dem Anschluß, nämlich zu der Anzahl von Sprüngen, die in dem SAP- Antwortrahmen enthalten ist (SP9 in Fig. 5), und sen­ det die Informationen von dem netzwerkseitigen Sen­ de/Empfangsabschnitt (die Bezugszahl 21 in Fig. 24) zu dem Netzwerk 3b (Schritt S17).
Der Server 11s mit einem Nicht-Chiffriersystem emp­ fängt die Serverinformationen wie den Servernamen 12s, den Diensttyp 0 × 04 und die Anzahl von Sprüngen 0 × 06 und registriert diese in der Servertabelle 52 (Schritt S18).
Die Chiffriervorrichtung 2c bestimmt, daß die empfan­ genen Serverinformationen so wie sie sind durch den SAP-Verarbeitungsabschnitt zu dem Server 13s zu sen­ den sind, und sendet sie zu dem Server 13s (Schritt S19).
Der Server 13s mit einem Chiffriersystem empfängt die Serverinformationen hiervon und registriert die Ser­ verinformationen wie den Servernamen 12s, den Dienst­ typ 0 × 04 und die Anzahl von Sprüngen 0 × 06 in der Servertabelle (Schritt S20).
Der Server 13s mit einem Chiffriersystem sendet peri­ odisch die eigenen Serverinformationen aus entspre­ chend derselben Folge wie der bei dem Empfang der Serverinformationen für den Server 12s mit einem Chiffriersystem. Der Server 11s registriert die Ser­ verinformationen wie der Servernamen 13s, den Dienst­ typ 0 × 04 und die Anzahl von Sprüngen 0 × 06 in der Servertabelle 52. Der Server 12s registriert die Ser­ verinformationen wie den Servernamen 13s, den Dienst­ typ 0 × 04 und die Anzahl von Sprüngen 0 × 06 in der Servertabelle 53 (Schritt S21 bis Schritt S25).
Es ist festzustellen, daß die Beschreibung der Leit­ einrichtung 4a bei der obigen Beschreibung der Fig. 26 weggelassen ist, jedoch aktualisiert die Leitein­ richtung 4a die Servertabelle 51 entsprechend den von dem Netzwerk 3b empfangenen Serverinformationen. Das heißt, die Leiteinrichtung 4a empfängt die Serverin­ formationen für den Server 11s wie den Servernamen 11s, den Diensttyp 0 × 04 und die Anzahl von Sprüngen 0 × 01 von dem Netzwerk 3b und registriert sie in der Servertabelle 51.
Auch empfängt die Leiteinrichtung 4a die Serverinfor­ mationen für den Server 12s wie den Servernamen 12s, den Diensttyp 0 × 04 und die Anzahl von Sprüngen 0 × 06 von dem Netzwerk 3b und registriert sie in der Servertabelle 51, und sie empfängt auch die Serverin­ formationen für den Server 13s wie den Servernamen 13s, den Diensttyp 0 × 04 und die Anzahl von Sprüngen 0 × 06 von dem Netzwerk 3b und registriert sie in der Servertabelle 51.
Wie vorbeschrieben ist, erfahren die Server und die Leiteinrichtungen in dem Netzwerk die Serverinforma­ tionen wie durch die Bezugszeichen 51, 52, 53 ange­ zeigt ist, die jeweils in Fig. 25 gezeigt sind.
In dem in Fig. 25 gezeigten Netzwerksystem ist, wenn der Kunde 1c mit einem Nicht-Chiffriersystem auf­ steht, die verarbeitete Folge dieselbe wie die in Fig. 11. In Fig. 11 sendet die Leiteinrichtung 4a, wenn sie die SAP-Anfrage über den nächsten Dienst von dem Kunden 11c empfängt, die Serverinformationen für die kleinste Zahl von Sprüngen (in dem Beispiel der Servername 11s, der Diensttyp 0 × 04, die Anzahl von Sprüngen 0 × 01), die in der Servertabelle 51 gespei­ chert sind, zu dem Netzwerk als die SAP-Antwort, so daß die Leiteinrichtung 4a immer Informationen dazu für den Server 11s mit einem Nicht-Chiffriersystem sendet für die SAP-Anfrage über den nächsten Dienst von dem Kunden 22c mit einem Nicht-Chiffriersystem. In dem Chiffriersystem wird die Anzahl der Sprünge von 5 zu der in den Informationen in der Chiffrier­ vorrichtung addiert, um eine Anzahl von Sprüngen zu sein, die größer ist als die in dem Nicht-Chiffrier­ system, und die größere wird in dem Vorgang ausge­ schlossen, und aus diesem Grund können Nicht-Crypto­ kommunikationen in dem identischen Netzwerk durchge­ führt werden, in welchem Anschlüsse mit einem Chif­ friersystem sowie mit einem Nicht-Chiffriersystem gemischt sind.
Bei dem in Fig. 25 gezeigten Netzwerksystem zeigt Fig. 27 eine Folge der Verarbeitung für den Kunden 12c mit einem Chiffriersystem von seiner Initialisie­ rung bis zum Start von Kommunikationen mit dem Server 12s mit einem Chiffriersystem. In der Figur sendet der Kunde 12c mit einem Chiffriersystem eine SAP-An­ frage über den nächsten Dienst mit dem Diensttyp 0 × 04, wenn er initialisiert ist (Schritt S21), und die Chiffriervorrichtung 2a empfängt sie. Die Chif­ friervorrichtung 2a empfängt den Rahmen von dem an­ schlußseitigen Sende/Empfangsabschnitt (die Bezugs­ zahl 21 in Fig. 24) und speichert ihn in dem Rahmen­ speicher (die Bezugszahl 22 in Fig. 24). Der Rahmen wird identifiziert als ein SAP-Rahmen der Anfrage über den nächsten Dienst durch den Protokollidentifi­ zierungsabschnitt (die Bezugszahl 26 in Fig. 24), zur Übertragung zu dem SAP-Verarbeitungsabschnitt (die Bezugszahl 28 in Fig. 24). Der SAP-Verarbeitungsab­ schnitt bereitet einen SAP-Antwortrahmen vor entspre­ chend den Serverinformationen von in diesem Beispiel dem Servernamen 12s, den Diensttyp 0 × 04 und der Anzahl von Sprüngen 0 × 02, die jeweils vorher in der Serverinformationstabelle 53 (die Bezugszahl 33 in Fig. 24) gesetzt wurden die erforderlich ist für die von dem Anschluß gesandte SAP-Anfrage über den näch­ sten Dienst, und sendet die Informationen von dem anschlußseitigen Sende/Empfangsabschnitt zu dem Kun­ den 12c (Schritt S23).
Der Kunde 12c mit einem Chiffriersystem empfängt den SAP-Antwortrahmen (Schritt S24) und sendet einen RIP- Anfragerahmen für eine Netzwerkzahl (SP6 in Fig. 5) des in dem SAP-Ant 05542 00070 552 001000280000000200012000285910543100040 0002019721949 00004 05423wortrahmen gesetzten Servers (Schritt S31).
Die Chiffriervorrichtung 2a empfängt den Rahmen von dem anschlußseitigen Sende/Empfangsabschnitt (die Bezugszahl 21 in Fig. 24) und speichert ihn in dem Rahmenspeicher (die Bezugszahl 22 in Fig. 24). Der Rahmen wird durch den Protokollidentifizierungsab­ schnitt (die Bezugszahl 26 in Fig. 24) als ein RIP- Rahmen identifiziert und wird so wie er ist von dem netzwerkseitigen Sende/Empfangsabschnitt (Schritt S32) zu dem Netzwerk gesandt.
Die Leiteinrichtung 4a empfängt die RIP-Anfrage (Schritt S33) und sendet eine Antwort (Schritt S34).
Die Chiffriervorrichtung 2a empfängt den Rahmen von dem netzwerkseitigen Sende/Empfangsabschnitt (die Bezugszahl 23 in Fig. 24) und speichert sie in dem Rahmenspeicher (die Bezugszahl 22 in Fig. 24). Der Rahmen wird durch den Protokollidentifizierungsab­ schnitt (die Bezugszahl 26 in Fig. 24) als ein RIP- Rahmen identifiziert und wird so wie er ist von dem anschlußseitigen Sende/Empfangsabschnitt zu dem An­ schluß gesandt (Schritt S35), und der Kunde 12c mit einem Chiffriersystem empfängt ihn (Schritt S36).
Der Kunde 12c mit einem Chiffriersystem beginnt die Kommunikation mit dem Server 12s gemäß der RIP-Ant­ wort (Schritt S41). Die Chiffriervorrichtung 2a emp­ fängt den Rahmen von der Anschlußseite, speichert ihn in dem Rahmenspeicher (die Bezugszahl 22 in Fig. 24) und überträgt ihn zu dem Protokollidentifizierungs­ abschnitt (die Bezugszahl 26 in Fig. 24). Der Rahmen wird von dem Protokollidentifizierungsabschnitt als ein Datenrahmen identifiziert und die Abschnitte nach dem Datenabschnitt (X11 in Fig. 2) in dem Rahmen wer­ den chiffriert, um gesandt zu werden (Schritt S42). Die Leiteinrichtung 4a sendet den Rahmen zu der Emp­ fängeradresse entsprechend der Leittabelle (Schritt S43).
Die Chiffriervorrichtung 2b empfängt den Rahmen von der Netzwerkseite, speichert ihn in dem Rahmenspei­ cher (die Bezugszahl 22 in Fig. 24) und überträgt ihn zu dem Protokollidentifizierungsabschnitt (die Be­ zugszahl 26 in Fig. 24). Der Rahmen wird von dem Pro­ tokollidentifizierungsabschnitt als ein Datenrahmen identifiziert, und der Datenabschnitt (X11 in Fig. 2) in dem Rahmen wird dechiffriert, um zu dem Server gesandt zu werden (Schritt S44). Der Server 12s mit einem Chiffriersystem empfängt die Informationen (Schritt S45).
Die Daten werden von dem Server 12s mit einem Chif­ friersystem zu dem Kunden 12c mit einem Chiffriersy­ stem gesandt entsprechend der Verarbeitung von Schritt S41 bis Schritt S45 in der umgekehrten Rei­ henfolge.
Wie vorbeschrieben ist, spezifiziert eine Kunden auf­ nehmende Chiffriervorrichtung einen Server mit einem Chiffriersystem für die Initialisierung, so daß ein Server mit einem Chiffriersystem mit einem Kunden mit einem Chiffriersystem verbunden werden kann.
Auch selbst wenn die Systemkonfiguration keine Leit­ einrichtung hat, wie in Fig. 28 gezeigt ist, bricht die Chiffriervorrichtung 2b, die mit dem Server 12s mit einem Chiffriersystem verbunden ist, eine SAP- Anfrage über den nächsten Dienst ab zu der Anfrage hiervon von dem Kunden 11c, und der Server 11s mit einem Nicht-Chiffriersystem teilt den Servernamen 11s mit der kleinsten Anzahl von Sprüngen in der eigenen Servertabelle dem Kunden 11c mit, so daß ein Server mit einem Nicht-Chiffriersystem und ein Kunde mit einem Nicht-Chiffriersystem miteinander verbunden werden können.
Wie vorbeschrieben ist, wird die Anzahl von Sprüngen des Servers mit einem Chiffriersystem auf einen grö­ ßeren Wert gebracht, und wenn ein Kunde mit einem Nicht-Chiffriersystem initialisiert wird, wählt ir­ gendeiner der Server oder eine Leiteinrichtung, die eine SAP-Anfrage über den nächsten Dienst empfangen haben, einen Server mit einem kleineren Wert für die Anzahl von Sprüngen aus, um diesen dem Kunden mitzu­ teilen, während eine Chiffriervorrichtung die SAP- Anfrage über den nächsten Dienst von dem Netzwerk abbricht, so daß der Server mit einem Nicht-Chif­ friersystem und der Kunde mit einem Nicht-Chiffrier­ system miteinander verbunden werden können unter Ver­ meidung der Auswahl eines Servers mit einem Chif­ friersystem.
Demgemäß können Crypto- oder Nicht-Cryptokommunika­ tionen in einem Netzwerk durchgeführt werden, in wel­ chem Anschlüsse mit einem Chiffriersystem sowie mit einem Nicht-Chiffriersystem gemischt sind.
In diesem Beispiel wird angenommen, daß die vorlie­ gende Erfindung auf einen Betrieb durch einen Bustyp von LAN angewendet wird, jedoch kann dieselbe Wirkung selbst durch einen Ringtyp von LAN oder WAN erzielt werden. Auch kann dieselbe Wirkung in einem Fall er­ halten werden, in welchem irgendein Netzwerk mit ei­ nem anschlußseitigen Sende/Empfangsabschnitt verbun­ den ist und eine Chiffrierung oder Dechiffrierung durchgeführt wird, wenn Informationen zu dem Netzwerk zu übertragen sind.

Claims (5)

1. Chiffriervorrichtung (2), die in einem Netzwerk (3) verwendet wird, in welchem ein Anschluß (1) mit einer Funktion als ein Kunde und ein Anschluß mit einer Funktion als ein Server miteinander hierdurch verbunden sind, oder in einem lokalen Netzwerk, in welchem mehrere Netzwerke mit jeweils der obigen Konfiguration mit einer Leiteinrichtung verbunden sind, wobei die Chiffriervorrichtung (2) zwischen den Anschluß (1) und das Netzwerk (3) eingefügt ist zur Durchführung einer Cryptokommunikation, so­ wie mit Chiffriermittel (27) zum Empfang eines Datenrahmens von dem Anschluß (1) und zum Chiff­ rieren eines in dem Datenrahmen enthaltenen spe­ zifizierten Datenabschnitts, um den Datenab­ schnitt zu dem Netzwerk (3) zu senden;
Dechiffriermittel (27) zum Empfang eines Daten­ rahmens von dem Netzwerk (3) und zum Dechiff­ rieren eines in diesem Datenrahmen enthaltenen spezifizierten Datenabschnitts, um ihn zu dem Anschluß (1) zu senden, gekennzeichnet durch
eine Chiffrierdienstvorrichtung (28) zum Empfang eines Serverinformationen mitteilenden Rahmens von dem Anschluß (1), Umwandeln des Diensttyps für Cryptokommunikation, wenn der in den Server­ informationen für diesen Rahmen enthaltene Diensttyp des Servers für Nicht-Cryptokommuni­ kation ist, um den Rahmen zu dem Netzwerk (3) zu senden;
eine Nicht-Chiffrierdienstvorrichtung (28) zum Empfang eines Serverinformationen mitteilenden Rahmens von dem Netzwerk (3) und zum Umwandeln des Diensttyps hiervon, wenn der in dem Rahmen enthaltene Diensttyp der Serverinformationen für Cryptokommunikation ist, für Nicht-Cryptokommu­ nikation, um den Rahmen zu dem Anschluß (1) zu senden, und auch zum Abbrechen der Serverinfor­ mationen oder Umwandeln der Anzahl von Sprüngen, die die Anzahl von Zwischen-Leiteinrichtungen anzeigt, in eine nicht erreichbare Anzahl, wenn der Diensttyp hiervon für Nicht-Cryptokommunika­ tion ist, um den Rahmen zu dem Anschluß (1) zu senden; und
eine Kommunikationsweginformationen-Übertra­ gungsvorrichtung (21, 23) zum Empfang eines Kom­ munikationsweginformationen mitteilenden Rahmens von dem Anschluß (1), zum Senden des Rahmens zu dem Netzwerk (3) und zum Empfang eines Kommuni­ kationsweginformationen mitteilenden Rahmens von dem Netzwerk (3), um den Rahmen zu dem Anschluß (1) zu senden.
2. Chiffriervorrichtung (2), die in einem Netzwerk (3) verwendet wird, in welchem ein Anschluß (1) mit einer Funktion eines Kunden und ein Anschluß mit einer Funktion eines Servers hierdurch miteinander verbun­ den sind, oder in einem lokalen Netzwerk, in welchem mehrere Netzwerke mit jeweils der obigen Konfigurati­ on mit einer Leiteinrichtung verbunden sind, wobei die Chiffriervorrichtung (2) zwischen den Anschluß (1) und das Netzwerk (3) eingefügt ist zum Durchfüh­ ren einer Cryptokommunikation, sowie mit Chiffriermit­ tel (27) zum Empfang eines Datenrahmens von dem An­ schluß (1) und Dechiffriermittel (27) zum Empfang ei­ nes Datenrahmens von dem Netzwerk (3), gekennzeichnet durch
eine transparente Verarbeitungsadressentabelle (30) zum Speichern einer nicht zu chiffrierenden Adresse;
daß das Chiffriermittel (27) ein Chiffriermittel (27) ist zum Empfang eines Datenrahmens von dem Anschluß (1) und zum Senden eines spezifizierten Datenab­ schnitts eines Datenrahmens zu dem Netzwerk (3), wenn eine Empfängeradresse für diesen Datenrahmen in der transparenten Verarbeitungsadressentabelle (30) regi­ striert worden ist, ohne den spezifizierten Datenab­ schnitt zu chiffrieren, oder durch Chiffrieren des spezifizierten Datenabschnitts des Datenrahmens, wenn die Empfängeradresse des Datenrahmens nicht in der transparenten Verarbeitungsadressentabelle (30) regi­ striert wurde;
daß das Dechiffriermittel (27) ein Dechiffriermittel (27) ist zum Empfang eines Datenrahmens von dem Netz­ werk (3) und zum Senden eines spezifizierten Datenab­ schnitts des Datenrahmens zu dem Anschluß (1), wenn eine Sendeadresse des Datenrahmens in der transparen­ ten Verarbeitungsadressentabelle (30) registriert wurde, ohne den spezifizierten Datenabschnitt des Da­ tenrahmens zu dechiffrieren, oder durch Dechiffrieren des spezifizierten Datenabschnitts des Datenrahmens, wenn die Sendeadresse des Datenrahmens nicht in der transparenten Verarbeitungsadressentabelle (30) regi­ striert wurde;
eine transparente Verarbeitungsservertabelle (31) zum Speichern von Serverinformationen für einen Server, für welchen eine Chiffrierung nicht erforderlich ist;
eine transparente Verarbeitungsvorrichtung (28) für einen Serverinformationen mitteilenden Rahmen zum Empfang eines Serverinformationen mitteilenden Rah­ mens von dem Netzwerk (3) und zum Senden des Rahmens zu dem Anschluß (1) in Abhängigkeit von einem Ergeb­ nis eines Vergleichs zwischen einem in Serverinforma­ tionen für diesen Rahmen enthaltenen Servernamen und einem in der transparenten Verarbeitungsservertabelle (31) gespeicherten Servernamen; und
eine Kommunikationsweginformationen-Übertragungsvor­ richtung (21, 23) zum Empfang eines Kommunikationswe­ ginformationen mitteilenden Rahmens von dem Anschluß (1), zum Senden dieses Rahmens zu dem Netzwerk (3), und auch zum Empfang eines Kommunikationsweginforma­ tionen mitteilenden Rahmens von dem Netzwerk (3) und Senden des Rahmens zu dem Anschluß (1).
3. Chiffriervorrichtung (2), die in einem Netzwerk verwendet wird, in welchem ein Anschluß (1) mit einer Funktion als ein Kunde und ein Anschluß mit einer Funktion als ein Server hierdurch mit­ einander verbunden sind, oder in einem lokalen Netzwerk, in welchem mehrere Netzwerke mit der obigen Konfiguration mit einer Leiteinrichtung verbunden sind, wobei die Chiffriervorrichtung (2) zwischen den Anschluß (1) und das Netzwerk (3) eingefügt ist zur Durchführung einer Crypto­ kommunikation, sowie mit Chiffriermittel (27) zum Empfang eines Datenrahmens von dem Anschluß (1) und zum Chiffrieren eines spezifizierten Datenabschnitts des Datenrahmens, um diesen zu dem Netzwerk (3) zu senden;
eine Dechiffriervorrichtung (27) zum Empfang eines Datenrahmens von dem Netzwerk (3), De­ chiffrieren des spezifizierten Datenabschnitts des Datenrahmens und Senden des dechiffrierten Datenabschnitts zu dem Anschluß (1), gekennzeichnet durch
eine Sprungzahl-Addiervorrichtung (32) zum Em­ pfang eines Serverinformationen mitteilenden Rahmens von dem Anschluß (1) und zum Senden eines Rahmens, der durch Addieren einer spezifi­ zierten Zahl zu einer Sprungzahl, die in den Serverinformationen für diesen Rahmen enthalten ist, erhalten wurde, zu dem Netzwerk (3);
eine Initialisierungsanfrage-Antwortvorrichtung (28) zum Empfang von Serverinformationen für eine Verbindungsbestimmung anfordernden Rahmens bei Initialisierung von dem Anschluß (1), und zum Senden eines Serverinformationen für eine spezifizierte Verbindungsbestimmung mitteilenden Rahmens zu dem Anschluß (1); und
eine Abbrechvorrichtung (28) zum Empfang eines Serverinformationen für eine Verbindungsbestim­ mung anfordernden Rahmens bei Initialisierung von dem Netzwerk (3), und zum Abbrechen des Rah­ mens; und
eine Kommunikationsweginformationen-Übertra­ gungsvorrichtung (21, 23) zum Empfang eines Kom­ munikationsweginformationen mitteilenden Rahmens von dem Anschluß (1), zum Senden des Rahmens zu dem Netzwerk (3), und auch zum Empfang eines Kommunikationsweginformationen mitteilenden Rah­ mens von dem Netzwerk (3) und Senden des Rahmens zu dem Anschluß (1).
4. Chiffriervorrichtung nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die Chif­ friervorrichtung (2) in Bustyp- oder Ringtyp-LAN (Lokalbereichs-Netzwerk) oder WAN (Weitbereichs- Netzwerk) angewendet wird.
5. Chiffriervorrichtung nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß das Netzwerk (3) mit dem Sende/Empfangsabschnitt des An­ schlusses verbunden ist, wobei ein Chiffrier- /Dechiffriervorgang durch Übertragung zu dem Netzwerk (3) durchgeführt wird.
DE19721949A 1996-06-28 1997-05-21 Chiffriervorrichtung Expired - Fee Related DE19721949C2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP16995096A JP3446482B2 (ja) 1996-06-28 1996-06-28 暗号化装置

Publications (2)

Publication Number Publication Date
DE19721949A1 DE19721949A1 (de) 1998-01-08
DE19721949C2 true DE19721949C2 (de) 2000-07-13

Family

ID=15895880

Family Applications (1)

Application Number Title Priority Date Filing Date
DE19721949A Expired - Fee Related DE19721949C2 (de) 1996-06-28 1997-05-21 Chiffriervorrichtung

Country Status (5)

Country Link
US (1) US6016350A (de)
JP (1) JP3446482B2 (de)
CA (1) CA2205637C (de)
DE (1) DE19721949C2 (de)
GB (1) GB2314741B (de)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6185305B1 (en) * 1998-05-04 2001-02-06 Motorola, Inc. Method and system for broadcasting digital audio to a radio
WO2000068814A1 (en) * 1999-05-06 2000-11-16 General Dynamics Information Systems, Inc. Transient network architecture
JP3259724B2 (ja) * 1999-11-26 2002-02-25 三菱電機株式会社 暗号装置、暗号化器および復号器
EP1156694B1 (de) * 1999-12-27 2004-08-18 Mitsubishi Denki Kabushiki Kaisha Funkkommunikationsgerät
KR20010090241A (ko) * 2000-03-24 2001-10-18 손진운, 박영찬 인터넷 정보 이용자의 선호도 관리 대행 시스템 및 방법
JP4481518B2 (ja) * 2001-03-19 2010-06-16 株式会社日立製作所 情報中継装置及び転送方法
US7328336B2 (en) * 2001-06-26 2008-02-05 Ncipher Corporation Ltd System and method for small-area system data processing
US7415005B1 (en) 2001-10-29 2008-08-19 The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration Ad hoc selection of voice over internet streams
JP2003244122A (ja) * 2002-02-14 2003-08-29 Sony Corp 情報処理システム、情報処理装置および方法、記録媒体、並びにプログラム
WO2003096612A1 (en) * 2002-05-09 2003-11-20 Niigata Seimitsu Co., Ltd. Encryption device, encryption method, and encryption system
JP4235824B2 (ja) * 2004-09-09 2009-03-11 村田機械株式会社 暗号化装置
US20060294383A1 (en) * 2005-06-28 2006-12-28 Paula Austel Secure data communications in web services
US20080072033A1 (en) * 2006-09-19 2008-03-20 Mcalister Donald Re-encrypting policy enforcement point
US8244905B2 (en) * 2009-03-31 2012-08-14 Alcatel Lucent Routing mechanisms for messaging applications using an enhanced gateway control function
CN101951554A (zh) * 2010-08-25 2011-01-19 中兴通讯股份有限公司 一种实现加密会议电话预接入的方法及系统
CN113163395B (zh) * 2020-01-07 2024-08-20 阿里巴巴集团控股有限公司 一种终端与服务器通信、密钥配置的方法和装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63155930A (ja) * 1986-12-19 1988-06-29 Nec Corp デ−タ暗号化通信方式
JPH04154233A (ja) * 1990-10-17 1992-05-27 Fujitsu Ltd 通信秘匿方式

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4924513A (en) * 1987-09-25 1990-05-08 Digital Equipment Corporation Apparatus and method for secure transmission of data over an unsecure transmission channel
US4881263A (en) * 1987-09-25 1989-11-14 Digital Equipment Corporation Apparatus and method for secure transmission of data over an unsecure transmission channel
GB8927623D0 (en) * 1989-12-06 1990-02-07 Bicc Plc Repeaters for secure local area networks
US5052040A (en) * 1990-05-25 1991-09-24 Micronyx, Inc. Multiple user stored data cryptographic labeling system and method
US5086469A (en) * 1990-06-29 1992-02-04 Digital Equipment Corporation Encryption with selective disclosure of protocol identifiers
GB9015799D0 (en) * 1990-07-18 1991-06-12 Plessey Telecomm A data communication system
US5369707A (en) * 1993-01-27 1994-11-29 Tecsec Incorporated Secure network method and apparatus
US5442708A (en) * 1993-03-09 1995-08-15 Uunet Technologies, Inc. Computer network encryption/decryption device
US5444782A (en) * 1993-03-09 1995-08-22 Uunet Technologies, Inc. Computer network encryption/decryption device
US5365590A (en) * 1993-04-19 1994-11-15 Ericsson Ge Mobile Communications Inc. System for providing access to digitally encoded communications in a distributed switching network
US5351295A (en) * 1993-07-01 1994-09-27 Digital Equipment Corporation Secure method of neighbor discovery over a multiaccess medium
US5386471A (en) * 1994-01-25 1995-01-31 Hughes Aircraft Company Method and apparatus for securely conveying network control data across a cryptographic boundary
US5629981A (en) * 1994-07-29 1997-05-13 Texas Instruments Incorporated Information management and security system
US5579394A (en) * 1994-09-06 1996-11-26 Motorola, Inc. Clear channel interface module and method therefor
US5548646A (en) * 1994-09-15 1996-08-20 Sun Microsystems, Inc. System for signatureless transmission and reception of data packets between computer networks
US5659615A (en) * 1994-11-14 1997-08-19 Hughes Electronics Secure satellite receive-only local area network with address filter
US5548649A (en) * 1995-03-28 1996-08-20 Iowa State University Research Foundation Network security bridge and associated method
US5615266A (en) * 1995-07-13 1997-03-25 Motorola, Inc Secure communication setup method
JP2728051B2 (ja) * 1995-10-18 1998-03-18 日本電気株式会社 Atm網構成管理方法
GB2311443A (en) * 1996-03-23 1997-09-24 Ibm Data message transfer in batches with retransmission
US5883891A (en) * 1996-04-30 1999-03-16 Williams; Wyatt Method and apparatus for increased quality of voice transmission over the internet
US5881243A (en) * 1997-05-07 1999-03-09 Zaumen; William T. System for maintaining multiple loop free paths between source node and destination node in computer network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63155930A (ja) * 1986-12-19 1988-06-29 Nec Corp デ−タ暗号化通信方式
JPH04154233A (ja) * 1990-10-17 1992-05-27 Fujitsu Ltd 通信秘匿方式

Also Published As

Publication number Publication date
GB9709339D0 (en) 1997-06-25
JPH1022996A (ja) 1998-01-23
JP3446482B2 (ja) 2003-09-16
DE19721949A1 (de) 1998-01-08
CA2205637C (en) 2000-09-12
GB2314741B (en) 1998-06-10
US6016350A (en) 2000-01-18
CA2205637A1 (en) 1997-12-28
GB2314741A (en) 1998-01-07

Similar Documents

Publication Publication Date Title
DE19721949C2 (de) Chiffriervorrichtung
DE19823666B4 (de) Verschlüsselungs-Kommunikationssystem
DE69533953T2 (de) System für signaturlose Übertragung und Empfang von Datenpaketen zwischen Computernetzwerken
DE69827252T2 (de) Architektur für virtuelle privatnetze
DE60206809T2 (de) Verfahren und Systeme zum Erzeugen von Chiffrierschlüsseln unter Verwendung von Zufallsbitfolgen
DE69217440T2 (de) Verfahren zur Algorithmus-unabhängigen Geheimübertragungsschlüsselverwaltung
DE60205548T2 (de) Verfahren und System zur Übertragung von Multimediadatenflusspaketen
DE60317296T2 (de) Sicherheitsprozessorspiegelung
DE60209475T2 (de) Datensicherungs-kommunikationsvorrichtung und -verfahren
DE69320924T2 (de) Verfahren zur Verwaltung eines Geheimübertragungsschlüssels
DE60017292T2 (de) Authentifizierungsverfahren zwischen einem Teilnehmer und einem Dienstleister, der durch einen Netzbetreiber erreichbar ist, mittels Bereitstellung eines gesicherten Kanals
DE69831974T2 (de) Verfahren zur paketauthentifizierung in gegenwart von netzwerkadressübersetzungen und protokollumwandlungen
DE60121393T2 (de) Schlüsselverwaltungsverfahren für drahtlose lokale Netze
DE60035953T2 (de) Wiederverwendung von sicherheitsbeziehungen zur verbesserung der durchführung eines handovers
DE60116610T2 (de) Netzwerkadressenübersetzungsgateway für lokale netzwerke unter verwendung lokaler ip-adressen und nicht übersetzbarer portadressen
DE69518199T2 (de) Sicheres Datenübertragungsverfahren
DE69626678T2 (de) System und verfahren zur sicherung der geheimhaltung von benutzern in der netzwerkkommunikation
DE19924575A1 (de) Kommunikationssystem und -Verfahren
DE60201522T2 (de) Ermöglichen legales abfangen von ip-verbindungen
DE10148415C2 (de) Verfahren und Vorrichtung zum Verschlüsseln und Entschlüsseln von Daten
DE10052311A1 (de) Manuelles Verhindern des unerlaubten Mithörens in einem virtuellen privaten Netzwerk über das Internet
DE602004001606T2 (de) Return-Routability-Verfahren zur sicheren Kommunikation
DE60022778T2 (de) System und verfahren zur kodierung von benutzerinformation in domänennamen
DE112005001690T5 (de) Wirksame Datenübertragung durch Datenverdichtung
EP0923826B1 (de) Anordnung und verfahren zur kryptographischen bearbeitung eines digitalen datenstroms, der eine beliebige anzahl von daten aufweist

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
D2 Grant after examination
8364 No opposition during term of opposition
8320 Willingness to grant licences declared (paragraph 23)
8339 Ceased/non-payment of the annual fee