DE69930504T2 - System zur übertragung von zugriffinformationen und web-inhalt zu einem mobilen gerät - Google Patents

System zur übertragung von zugriffinformationen und web-inhalt zu einem mobilen gerät Download PDF

Info

Publication number
DE69930504T2
DE69930504T2 DE69930504T DE69930504T DE69930504T2 DE 69930504 T2 DE69930504 T2 DE 69930504T2 DE 69930504 T DE69930504 T DE 69930504T DE 69930504 T DE69930504 T DE 69930504T DE 69930504 T2 DE69930504 T2 DE 69930504T2
Authority
DE
Germany
Prior art keywords
key
message
component
group
checksum
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 - Lifetime
Application number
DE69930504T
Other languages
English (en)
Other versions
DE69930504D1 (de
Inventor
Vinay Bellevue DEO
David Redmond TUNIMAN
R. Daniel Redmond SIMON
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.)
Microsoft Corp
Original Assignee
Microsoft 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 Microsoft Corp filed Critical Microsoft Corp
Publication of DE69930504D1 publication Critical patent/DE69930504D1/de
Application granted granted Critical
Publication of DE69930504T2 publication Critical patent/DE69930504T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
    • G06F1/3209—Monitoring remote activity, e.g. over telephone lines or network connections
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/103—Formatting, i.e. changing of presentation of documents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/103—Formatting, i.e. changing of presentation of documents
    • G06F40/117—Tagging; Marking up; Designating a block; Setting of attributes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/123—Storage facilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/149—Adaptation of the text data for streaming purposes, e.g. Efficient XML Interchange [EXI] format
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/151—Transformation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/197—Version control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72406—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by software upgrading or downloading
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72409—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories
    • H04M1/72412—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories using two-way short-range wireless interfaces
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/022—Selective call receivers
    • H04W88/023—Selective call receivers with message or information receiving capability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/26—Devices for calling a subscriber
    • H04M1/27—Devices whereby a plurality of signals may be stored simultaneously
    • H04M1/274—Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc
    • H04M1/2745—Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc using static electronic memories, e.g. chips
    • H04M1/2753—Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc using static electronic memories, e.g. chips providing data content
    • H04M1/2757—Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc using static electronic memories, e.g. chips providing data content by data transmission, e.g. downloading
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery

Description

  • HINTERGRUND DER ERFINDUNG
  • Die vorliegende Erfindung bezieht sich auf mobile PC-Geräte, üblicherweise als Mobilvorrichtungen bekannt. Genauer gesagt bezieht sich die vorliegende Erfindung auf ein System und ein Verfahren zum Versenden von Information an Mobilvorrichtungen und zum Programmieren selbiger Vorrichtungen.
  • Bei Mobilvorrichtungen handelt es sich um kleine elektronische Rechenvorrichtungen, die oft als persönliche digitale Assistenten bezeichnet werden. Viele solcher Mobilvorrichtungen sind Pager, Handgeräte (hand held devices) oder Vorrichtungen in Palm-Größe, die bequem in der Hand gehalten werden können. Eine im Handel erhältliche Vorrichtung wird unter dem Markennamen HandHeld PC (oder H/PC) verkauft, für die Microsoft Corporation of Redmont, Washington die Software bereitstellt.
  • Üblicherweise enthält die Mobilvorrichtung einen Prozessor, einen RAM-Speicher und eine Eingabevorrichtung wie z.B. eine Tastatur und ein Display. Die Tastatur kann in das Display integriert sein, beispielsweise, wenn die Tastatur in Form eines Berührungsdisplays eingebaut ist. Eine Kommunikationsschnittstelle wird wahlweise angeboten und wird üblicherweise zur Kommunikation mit dem Desktopcomputer verwendet. Eine austauschbare oder wiederaufladbare Batterie versorgt die Mobilvorrichtung mit Strom. Die Mobilvorrichtung kann optional Strom von einer externen Stromquelle beziehen, die die eingebaute Batterie außer Kraft setzt oder wiederauflädt.
  • In einigen früheren Anwendungen wird die Mobilvorrichtung in Verbindung mit dem Desktopcomputer verwendet. Beispielsweise kann der Benutzer der Mobilvorrichtung ebenfalls Zugriff auf einen Desktopcomputer am Arbeitsplatz oder zu Hause oder auf beide haben und diese auch verwenden. Wenn es sich bei der Mobilvorrichtung um ein Gerät der Marke H/PC oder ein ähnliches Gerät handelt, verwendet der Benutzer üblicherweise die gleichen Anwendungsarten auf dem Desktopcomputer sowie auf der Mobilvorrichtung. Daher ist es für solche Mobilvorrichtungen von Vorteil, wenn sie so konzipiert sind, dass sie mit dem Desktopcomputer verbunden werden können, um Informationen auszutauschen und Informationen gemeinsam mit dem Desktopcomputer zu nutzen.
  • Eine andere Methode zur Bereitstellung von Informationen für Mobilvorrichtungen ist über eine kabellose Übertragungsleitung. Solche Informationen können elektronische Post oder Nachrichten, Wetter, Sport, Verkehr und regionale Veranstaltungsinformationen beinhalten. Die Infomationen werden üblicherweise über einen mit dem Internet verbundenen Desktopcomputer erhalten, und über eine Kabelverbindung übertragen. Es könnte jedoch wünschenswert sein, solche Informationen ebenfalls über eine kabellose Verbindung zu übertragen. Ein kabelloser Empfänger auf der Mobilvorrichtung kann Informationen empfangen, wenn diese an die Mobilvorrichtung gesendet werden.
  • Handelt es sich bei der Mobilvorrichtung um einen Pager, hat jeder Pager in einem gegebenen System eine oder mehrere Adres sen. Wenn eine Nachricht über einen kabellosen Kanal übertragen wird, ist sie für eine Adresse bestimmt. Alle Pager, die diesem kabellosen Kanal zugeordnet sind, erhalten die Nachricht und überprüfen die in der Nachricht enthaltene Adresse mit ihren eigenen Adressen. Dieser Algorithmus zum Adressen-Abgleich kann entweder in der Hardware implementiert sein, oder in der Software, oder in einer Kombination aus Hardware und Software. Wenn die Adresse, die der eingehenden Nachricht zugeordnet ist, mit keiner der Adressen auf dem Pager übereinstimmt, wird die Nachricht gelöscht. Stimmt die Adresse jedoch mit einer der Adressen auf dem Pager überein, wird die Nachricht angenommen und zur Software auf einem höheren Level im Protokollregister auf dem Pager zur entsprechenden Verarbeitung weitergeleitet.
  • Üblicherweise gibt es zwei Arten von Adressen. Die erste ist eine persönliche Adresse, die einzigartig innerhalb eines vorgegebenen kabellosen Netzwerks ist (d.h. nur ein Pager hat diese Adresse). Die persönliche Adresse wird verwendet, um eine Nachricht an einen bestimmten Pager zu schicken.
  • Die zweite Art von Adresse ist eine Sendeadresse. Üblicherweise wird eine Sendeadresse in viele Pager innerhalb eines gegebenen kabellosen Netzwerks programmiert. Somit wird eine einzelne Nachricht, die über eine Sendeadresse gesendet wird, von einer Vielzahl an Pagern in dem Netzwerk empfangen und angenommen. Solche Adressen werden zur Durchführung von Sendediensten (Broadcast Services) verwendet, wie zum Beispiel Nachrichten-, Verkehrs- und Wetterdienste sowie weiterer oben erwähnter Dienste.
  • Gegenwärtig gibt es keine geeignete Art und Weise zur Umprogrammierung von Adressen in Mobilvorrichtungen, wie beispielsweise Pagern. Stattdessen müssen die Pager zurück zum Servicecenter gebracht werden, wo spezielle Werkzeuge zum Einsatz kommen, um auf den internen Speicher des Pagers, in dem die Adressen gespeichert sind, zuzugreifen und ihn zu modifizieren. Bei einigen früheren Systemen wurde versucht, das drahtlose Programmieren anzuwenden. In solchen Systemen schickt der Besitzer (oder Träger) des Netzwerks eine spezielle Nachricht an den Pager, welche die Adressen in dem Pager ändert.
  • Bis heute ist das jedoch sehr ungewöhnlich. Im Bezug auf Sicherheit bringt das kabellose Programmieren schwerwiegende Schwierigkeiten mit sich. Mit anderen Worten, wenn der Provider des programmierten Sendedienstes eine Gebühr oder einen Bezugspreis von den Benutzern für den Empfang des Sendedienstes verlangen möchte, müssen die Programmiernachrichten einen hohen Grad an Sicherheit aufweisen. Im Übrigen wäre ein unbefugte Programmieren der Pagervorrichtungen zum Empfang der Sendedienste problematisch.
  • Methoden zur Codierung werden auf dem Gebiet der Pager nicht effektiv eingesetzt. Dafür gibt es eine Vielzahl an Gründen. Erstens werden Prozessoren in gewöhnlichen Pagern üblicherweise nicht mit Mitteln zur Implementierung von Decodierungsalgorithmen ausgestattet, wodurch die beim Pager eingehenden codierten Nachrichten decodiert werden könnten. Außerdem gibt es gegenwärtig kein Verfahren, welches es ermöglicht, dass sich ein sicheres Element zur Durchführung einer Decodierung (z.B.: ein Gerätetreiber) auf ein externes Softwaresicherheitselement (z.B.: eine Sicherheitskomponente "dynamically linked library" (DLL)) verlässt. Um den Inhalt einer codierten Nachricht zu decodieren, muss die Sicherheitskomponente den geeigneten Decodierungsschlüssel vom Gerätetreiber erhalten. Der Gerätetreiber (von dem angenommen wird, dass es sich um ein ein bewährtes Gerät handelt) muss daher den Decodierungsschlüssel an ein externes Element (die Sicherheitskomponente DLL) weitergeben, welches die Sicherheit des Codierungsschlüssels und somit die Sicherheit des Abonnement-Systems aufweist.
  • Überdies sind Informationsdienste mit der Einführung von globalen Computernetzwerken wie dem Internet vorherschend und wichtig geworden.
  • Ein typischer Pager kann jedoch nur eine begrenzte Anzahl an Adressen (üblicherweise 2–8) aufweisen. Um dem breiten Umfang an Interessen und Bedürfnissen zu entsprechen, wäre es wünschenswert, wenn eine viel größere Anzahl an Sendediensten angeboten werden würde. Wenn dies der Fall wäre, müsste jeder einzelne Benutzer den Pager umprogrammieren lassen (indem er ihn zum Servicecenter zurückbringt), damit dieser die Adressen aufweist, die die vom einzelnen Benutzer gewünschten Sendedienste auswählen. Das müsste jedes Mal vorgenommen werden, wenn der Benutzer die Auswahl an Sendediensten erweitern, löschen oder ändern möchte. Das ist sehr teuer und man nimmt an, dass dadurch das Wachstum und die Verbreitung solcher Sendedienste zumindest gehemmt würde.
  • Aus diesen Gründen bieten viele Funkrufunternehmen kostenlose Sendedienste an. Diese Dienste sind kostenlos, weil es gegenwärtig keinen kostengünstigen Weg zum Abonnement dieser Dienste gibt. Der Inhalt dieser Dienste wird durch einen unabhängigen Inhaltsprovider bereitgestellt, aber durch Betreiber kabelloser Netzwerke übertragen. Wenn der Benutzer einen neuen Dienst hinzufügen möchte, oder einen Dienst löschen möchte, muss das Gerät zu dem Servicecenter des Betreibers der kabellosen Netzwerke zurückgebracht werden, um die im Pager enthaltenen Adressen umzuprogrammieren. Das bedeutet, dass der unabhängige Inhaltsprovider keine Abonnements unabhängig von den Trägern (oder Betreibern kabelloser Netzwerke) verwalten kann. Selbst wenn dies, wie oben besprochen, erreicht werden könnte, gibt es gegenwärtig keine effiziente Methode, die Inhaltsnachrichten auf sichere Art und weise zu übertragen.
  • Das Dokument WO-A-95/12931 offenbart ein Kommunikationssystem, in dem Informationen in aufeinanderfolgenden Zeitintervallen übertragen werden, die zu einer Vielzahl an "Superframes" zusammengefasst sind, die wiederum zu einer Vielzahl an "Hyperframes" zusammengefasst sind.
  • Das Dokument WO-A-97/28649 offenbart ein System zur Verhinderung des unbefugten Empfangs, unbefugten Speicherns und Kopierens sowie der unbefugten Wiedergabe digitaler Medienobjekte, welche ein verschlüsseltes (scrambled) Sendeformat und ein verschlüsseltes (scrambled) Speicherformat verwendet, dass sich wiederum von dem Sendeformat unterscheidet.
  • Zusammenfassung der Erfindung
  • Es gibt ein Verfahren, dass den Zugriffs auf Sendenachrichten überwacht, wie in Anspruch 1 dargelegt wurde. Es gibt ausserdem ein System, dass den Zugriffs auf eine Sendenachricht überwacht, wie in Anspruch 20 dargelegt wurde.
  • Ein System steuert den Zugriff auf Sendenachrichten, die von einer Vielzahl von Mobilvorrichtungen empfangen werden. Ausgewählte Mobilvorrichtungen sind mit einem Sendecodierschlüssel BEK (broadcast encryption key) ausgestattet. Unter Verwendung des BEK vor dem Senden werden die Sendenachrichten codiert, so dass die ausgewählte Mobilvorrichtung, die den BEK enthält, die Sendenachrichten decodieren kann. Die Sendenachrichten werden dann gesendet.
  • Kurze Beschreibung der Zeichnungen
  • 1 ist ein vereinfachtes Blockdiagramm, das eine Ausführungsform einer Mobilvorrichtung in einem System gemäß der vorliegenen Erfindung erläutert.
  • 2 ist ein detaillierteres Blockdiagramm einer Ausführungsform einer Mobilvorrichtung, die in 1 dargestellt ist.
  • 3 ist eine vereinfachte bildhafte Darstellung einer Ausführungsform der Mobilvorrichtung, die in 2 dargestellt ist.
  • 4 ist eine vereinfachte bildhafte Darstellung einer anderen Ausführungsform der Mobilvorrichtung, die in 2 dargestellt ist.
  • 5 ist ein Blockdiagramm einer Ausführungsform eines Desktopcomputers gemäß eines Aspekts der vorliegenden Erfindung.
  • 6 ist ein detaillierteres Blockdiagramm eines Übertragungssystems einschliesslich einer Mobilvorrichtung gemäß eines Aspekts der vorliegenden Erfindung.
  • 7 ist ein Flussdiagramm, das das Programmieren eines Sendeschlüssels in die Mobilvorrichtung erläutert, die in 6 dargestellt ist.
  • 8A, 8B und 8C erläutern die Erstellung einer Programmiernachricht, die zur Programmierung eines Sendeschlüssels in die Mobilvorrichtung, die in 6 dargestellt ist, verwendet wird.
  • 9A–9C erläutern die Erstellung einer codierten Inhaltsnachricht gemäß eines Aspekts der vorliegenden Erfindung.
  • 10A und 10B sind Flussdiagramme, die die Decodierung einer codierten Inhaltsnachricht erläutern.
  • 11A erläutert ein detaillierteres Blockdiagramm einer zweiten Ausführungsform einer Mobilvorrichtung gemäß eines Aspekts der vorliegenden Erfindung.
  • 11B und 11C erläutern das Programmieren eines Sendeschlüssels in die Mobilvorrichtung, die in 11A dargestellt ist, und das Decodieren einer codierten Inhaltsnachricht auf der Mobilvorrichtung, die in 11A dargestellt ist.
  • Detaillierte Beschreibung der bevorzugten Ausführungsformen
  • 1 erläutert ein System 10, in dem die vorliegende Erfindung bildhaft umgesetzt ist. Das System 10 enthält einen Inhaltsprovider 12, einen kabellosen Träger 14, einen Desktopcomputer 16 und eine Mobilvorrichtung 18. Der Inhaltsprovider 12 stellt jede geeignete Art von Daten einer Datenbank oder einer anderen Datenquelle bereit. Beispielsweise wird der Inhaltsprovider 12 hierbei als ein Provider von kabellosen Diensten oder anderen Arten von Diensten erörtert, die vom Benutzer der Mobilvorrichtung 18 erwünscht sein könnten. Beispiele solcher Dienste wären u.a. Nachrichten-, Wetter- und Sportdienste, Börsennotierungen, Verkehrsnachrichten usw.
  • Der kabellose Träger 14 wird später in der Anmeldung in detaillierter Form beschrieben. Kurz gesagt ist der kabellose Träger 14 so eingestellt, dass er über eine Einwahl oder eine direkte Internetverbindung, oder über eine Netzwerkverbindung Dienstinhalts- und Programmiernachrichten (hierbei Inhalt) vom Inhaltsprovider 12 empfängt. Die Art und Weise, in der der kabellose Träger 14 Informationen vom Inhaltsprovider 12 empfängt, kann geschützte (herstellerspezifische) oder nicht geschützte (herstellerneutrale) Mittel beinhalten. In einer bildhafen Ausführungsform abonniert der kabellose Träger 14 beispielsweise aktive Kanäle einer Website des Inhaltsproviders über den von der Microsoft Corporation erhältlichen Internet Explorer. Die Internet Explorer Komponente zieht Daten von der Website herunter und speichert diese in einem Cachespeicher zur späteren Übertragung an die Mobilvorrichtung 18.
  • Der kabellose Träger 14 enthält zudem einen kabellosen Informationsserver (WIS) 20. Der Server 20 teilt den vom Inhaltsprovider 12 erhaltenen Inhalt in Teile auf, die mit der vom kabellosen Träger 14 verwendeten spezifischen Übertragungsart kompatibel sind. Der Server 20 teilt die Daten beispielsweise so, dass sie den Beschränkungen der maximalen Datenpaketgröße, den Zeichenvorratsanforderungen usw. für die verwendete Kanal- oder Übertragungsart entsprechen. Vor der Übertragung werden die Daten bevorzugterweise in eine andere Form umgewandelt. Wie später in der Anmeldung detaillierter beschrieben wird, könnte eine solche Umwandlung verschiedene Formen der Codierung sowie eine Komprimierung, Verschlüsselung usw. beinhalten. Sobald die Daten in geeigneter Weise geteilt wurden, so dass sie den Übertragungsrandbedingungen entsprechen, werden die Daten zur drahtlosen Übertragung durch ein kabelloses Netzwerk (wie beispielsweise einen Funkrufkanal) so eingestellt, dass sie direkt von der Mobilvorrichtung 18 empfangen werden. Die übertragenen Daten werden von einer kabellosen Empfänger- und Treiberkomponente 22 auf der Mobilvorrichtung 18 empfangen, wo die Daten zur Verwendung durch die Mobilvorrichtung 18 vorbereitet werden.
  • Die Mobilvorrichtung 18 enthält vorzugsweise auch ein Modem 24. Daher kann der Dienstinhalt anstatt über den kabellosen Träger 14, über eine Einwahlverbindung des Modems direkt vom Inhaltsprovider 12 auf die Mobilvorrichtung 18 übertragen werden.
  • Der Desktopcomputer 16 wird ebenfalls später in dar Beschreibung detaillierter beschrieben. Kurz gesagt ist der Desktopcomputer 16 jedoch vorzugsweise mit einem Standart Webbrowser ausgestattet, wie beispielsweise mit dem im Handel erhältlichen Internet Explorer 4.0 der Firma Microsoft Corporation of Redmond, Washington. Wenn dies der Fall ist, können die Benutzer des Desktopcomputers 16 vorzugsweise auf gewöhnliche Art und Weise die Kanäle abonnieren, die den Benutzer mit einem bestimmten Kanalinhalt beliefern, der offline oder online durchsucht werden kann. Der Desktopcomputer 16 kann daher zur weiteren Übertragung an die Mobilvorrichtung 18 periodisch neuen Inhalt abrufen oder empfangen.
  • Der Desktopcomputer 1b enthält vorzugsweise auch die Synchronisationskomponente 26. Kurz gesagt ist die Synchronisationskomponente 26 so eingestellt, dass eine Wechselwirkung zwischen diesem und einer optionalen gleichen Synchronisationskomponente 28 auf der Mobilvorrichtung 18 stattfindet, so dass die Dateien, die synchronisiert werden sollen, vom Desktopcomputer 16 auf die Mobilvorrichtung 18 synchronisiert werden können, oder umgekehrt. Sobald sie synchronisiert worden sind, enthalten beide Dateien (die auf dem Computer 16 und der Mobilvorrichtung 18) aktuelle Informationen.
  • Genauer gesagt kann die Mobilvorrichtung 18 in der bevorzugten Ausführungsform entweder mit dem Desktopcomputer 16 oder mit einer anderen Mobilvorrichtung 18 oder mit beiden synchronisiert werden. In diesem Fall entsprechen die Eigenschaften der in einem Objektspeicher auf der Mobilvorrrichtung 18 gespeicherten Objekte den Eigenschaften anderer Instanzen für das gleiche Objekts, das in einem Objektspeicher auf dem Desktopcomputer 16 oder einer anderen Mobilvorrichtung 18 gespeichert ist. Wenn beispielsweise ein Benutzer eine Instanz eines Objekts verändert, das in einem Objektspeicher auf dem Desktopcomputer 16 gespeichert ist, wird die zweite Instanz jenes Objekts, das in dem Objektspeicher der Mobilvorrichtung 18 gespeichert ist, aktualisiert, wenn die Mobilvorrichtung 18 das nächste Mal mit dem Desktopcomputer 16 verbunden wird, so dass beide Instanzen des gleichen Objekts aktuelle Daten aufweisen. Dies wird als Synchronisation bezeichnet.
  • Um eine Synchronisation zu erreichen, laufen die Synchronisationskomponenten 26 und 28 sowohl auf der Mobilvorrichtung 18 als auch auf dem Desktopcomputer 16 (oder einer anderen Mobilvorrichtung 18). Die Synchronisationskomponenten kommunizieren über klar definierte Schnittstellen, um die Kommunikation und Synchronisation zu ermöglichen.
  • Es ist zu beachtet, dass die Mobilvorrichtung 18 in der bevorzugten Ausführungsform nicht nur mit dem Desktopcomputer 16 gekoppelt werden kann, sondern auch mit einer anderen Mobilvorrichtung 18. Diese Verbindung kann über jede geeignete und im Handel erhältliche Kommunikationsleitung unter Verwendung eines geeigneten Kommunikationsprotokolls erreicht werden. In einer bevorzugten Ausführungsform kommuniziert die Mobilvorrichtung 18 beispielsweise über ein Anschlusskabel, das mittels eines seriellen Kommunikationsprotokolls kommuniziert, entweder mit dem Desktopcomputer 16 oder mit einer anderen Mobilvorrichtung 18. Andere Kommunikationsmechanismen werden bei der vorliegenden Erfindung ebenfalls eingesetzt, wie zum Beispiel die Kommunikation mittels Infrarot (IR) oder andere geeignete Kommunikationsmechanismen.
  • 2 ist ein detaillierteres Blockdiagramm der Mobilvorrichtung 18. Die Mobilvorrichtung 18 enthält vorzugsweise einen Mikroprozessor 30, einen Speicher 32, Eingabe-/Ausgabebauteile (E/A), eine Desktop-Kommunikationsschnittstelle 36, einen kabellosen Empfänger 37 und eine Antenne 39. In einer bevorzugten Ausführungsform sind diese Bauteile des Systems 10 zur gegensei tigen Kommunikation über einen geeigneten Datenbus 30 verbunden.
  • Der Speicher 32 wird vorzugsweise als permanenter elektronischer Speicher eingesetzt, beispielsweise als RAM (random access memory) mit einem Reserve-Batteriemodul (nicht dargestellt), so dass die im Speicher 32 gespeicherten Informationen nicht verloren gehen, wenn die Stromzufuhr zu der Mobilvorrichtung 18 abgeschaltet wird. Ein Teil des Speichers 32 ist vorzugsweise als addressierbarer Speicher zur Programmausführung belegt, wohingegen ein anderer Teil des Speichers 32 vorzugsweise zum Speichern verwendet wird, um zum Beispiel das Speichern auf einem Laufwerk zu simulieren.
  • Der Speicher 32 enthält ein Betriebssystem 40, ein Anwenderprogramm 42 (wie beispielsweise einen PIM (Personal Information Manager – persönlicher Informationsverwalter), ein E-Mailprogramm, usw.), sowie einen Objektspeicher 44. Während des Betriebs wird das Betriebssystem 40 vorzugsweise durch den Prozessor 30 vom Speicher 32 ausgeführt. In einer bevorzugten Ausführungsform handelt es sich bei dem Betriebssystem 40 um ein handelsübliches "Windows-CE"-Betriebssystem der Firma Microsoft Corporation. Das Betriebssystem 40 wurde vorzugsweise für Mobilvorrichtungen entwickelt, und führt Datenbankeigenschaften aus, die von dem PIM 42 über eine Reihe von freiliegender Schnittstellen und Methoden zur Anwendungsprogrammierung verwendet werden können. Die Objekte in dem Objektspeicher 44 werden vorzugsweise zumindest teilweise in Erwiderung auf Aufrufe an die freiliegenden Anwendungsprogrammierschnittstellen und -methoden von dem PIM 42 und dem Betriebssystem 40 verwaltet.
  • Die E/A-Bauteile 34 sind in einer bevorzugten Ausführungsform zur Unterstützung von Eingabe- und Ausgabeabläufen der Mobilvorrichtung 18 ausgelegt. Die E/A-Bauteile sind mit Bezug auf die 3 und 4 detaillierter beschrieben.
  • Die Desktop-Kommunikationsschnittstelle 36 wird wie jede geeignete Kommunikationsschnittstelle optional angeboten. Die Schnittstelle 36 wird vorzugsweise zur Kommunikation mit dem Desktopcomputer 16, dem Inhaltsprovider 12, dem kabellosen Träger 14 und optional mit einer anderen Mobilvorrichtung 18 eingesetzt, wie mit Bezug auf 1 beschrieben ist. Daher enthält die Kommunikationsschnittstelle 36 vorzugsweise eine Synchronisationskomponente 28 zur Kommunikation mit dem Desktopcomputer 16 und ein Modem 24 zur Kommunikation mit dem Inhaltsprovider 12. Der kabellose Empfänger und der kabellose Treiber 22 werden zur Kommunikation mit dem kabellosen Träger 14 eingesetzt.
  • 3 ist eine vereinfachte bildhafte Darstellung einer bevorzugten Ausführungsform einer Mobilvorrichtung 18, die gemäß der vorliegenden Erfindung verwendet werden kann. Bei der in 3 erläuterten Mobilvorrichtung 18 kann es sich um einen Desktopassistenten handeln, der unter der Bezeichnung H/PC verkauft wird und Software aufweist, die von der Firma Microsoft Corporation bereitgestellt wurde. In einer bevorzugten Ausführungsform enthält die Mobilvorrichtung 18 eine Miniaturtastatur 43, ein Display 45 und einen Stift 46 den Bildschirm. Bei der in 3 dargestellten Ausführungsform handelt es sich bei dem Display 45 um ein Flüssigkristall-Display (LCD), das in Verbindung mit einem Stift 46 für den Bildschirm einen Berührungsbildschirm verwendet. Der Stift 46 für den Bildschirm wird verwendet, um das Display an vorgegebenen Punkten anzutippen oder zu berühren, um so bestimmte, vom Benutzer festgelegte, Funktionen auszuführen. Die Miniaturtastatur 43 ist vorzugsweise als alphanumerische Miniaturtastatur ausgelegt, wobei alle geeigneten und erwünschten Funktionstasten ebenfalls so ausgelegt sind, dass sie bestimmte, vom Benutzer festgelegte Funktionen, ausführen.
  • 4 ist eine andere vereinfachte bildhafte Darstellung der Mobilvorrichtung 18 gemäß einer anderen bevorzugten Ausführungsform der vorliegenden Erfindung. Die in 4 erläuterte Mobilvorrichtung 18 weist einige Bestandteile auf, die denen ähneln, die mit Bezug auf 3 beschrieben wurden, und die daher ähnliche Bezugszeichen haben. Beispielsweise enthält die in 4 dargestellte Mobilvorrichtung ebenfalls einen Berührungsbildschirm 45, der in Verbindung mit dem Stift 46 für den Bildschirm zur Durchführung bestimmter, vom Benutzer festgelegter, Funktionen verwendet werden kann. Wenn die Mobilvorrichtung 18 jedoch als Pager ausgeführt ist, ist der Bildschirm 45 kein Berührungsbildschirm und der Stift 46 für den Bildschirm ist nicht notwendig.
  • Es sollte erwähnt werden, dass das Display 45 für die in den 3 und 4 dargestellte Mobilvorrichtung die gleiche Größe haben kann, oder unterschiedlich groß sein kann, aber üblicherweise viel kleiner als ein gewöhnliches Display eines Desktopcomputers ist. Beispielsweise können die in den 3 und 4 dargestellten Displays 45 durch eine Matrix festgelegt sein, die nur eine Größe von 240 × 320 hat, oder eine Größe von 160 × 160, oder jede andere passende Größe.
  • Die in 4 dargestellte Mobilvorrichtung 18 enthält außerdem eine Anzahl an Eingabetasten oder anderen Tasten (wie beispielsweise die Tasten 47 zum Scrollen), die es dem Benutzer ermöglichen, durch die auf dem Bildschirm 45 angezeigten Menüoptionen oder andere Displayoptionen zu scrollen oder Anwendungen zu verändern oder bestimmte Eingabefunktionen auszuwählen, ohne das Display 45 zu berühren. Zusätzlich enthält die in 4 dargestellte Mobilvorrichtung 18 vorzugsweise eine Ein-/Austaste 49, mit der die Mobilvorrichtung 18 ein- oder ausgeschaltet werden kann.
  • Es sollte ausserdem erwähnt werden, dass in der in 4 dargestellten Ausführungsform die Mobilvorrichtung 18 einen Bereich 51 zur handschriflichen Eingabe enthält. Dieser Bereich kann in Verbindung mit dem Stift 46 für den Bildschirm verwendet werden, so dass der Benutzer Nachrichten scheiben kann, die im Speicher 42 zur späteren Verwendung von der Mobilvorrichtung 18 gespeichert werden. In einer erläuternden Ausführungsform werden die handschriftlich eingegebenen Nachrichten einfach in handschriftlicher Form gespeichert und können vom Benutzer abgerufen und auf dem Bildschirm 45 angezeigt werden, so dass der Benutzer die in die Mobilvorrichtung 18 eingegebenen handschriftlichen Nachrichten überprüfen kann. In einer anderen bevorzugten Ausführungsform ist die Mobilvorrichtung 18 mit einem Modul zur Zeichenerkennung ausgestattet, so dass der Benutzer alphanumerische Informationen in die Mobilvorrichtung 18 eingeben kann, indem er diese alphanumerischen Informationen in den Bereich 51 mit dem Stift 46 für den Bildschirm handschriftlich eingibt. In diesem Fall erkennt das Modul zur Zeichenerkennung in der Mobilvorrichtung 18 die alphanumerischen Zeichen und wandelt die Zeichen in vom Computer erkennbare alphanumerische Zeichen um, die von den Anwendungsprogrammen 42 in der Mobilvorrichtung 18 verwendet werden können.
  • Natürlich sind der Bereich 51 zur handschriftlichen Eingabe und der Stift 46 für den Bildschirm nicht notwendig, wenn die Mobilvorrichtung 18 als Pager ausgeführt ist. Stattdessen ist die Mobilvorrichtung 18 nur mit einem Bildschirm 45, Eingabetasten 47 und einer Ein-/Austaste 49 ausgestattet.
  • 5 und die dazugehörige Erörterung sollen eine kurze, allgemeine Beschreibung eines geeigneten Desktopcomputers 16 bieten, in dem Teile der Erfindung umgesetzt sein können. Obwohl das nicht erforderlich ist, wird die Erfindung, zumindest in Teilen, im allgemeinen Kontext der am Computer ausführbaren Befehle beschrieben werden, wie beispielsweise Programm-Module, die von einem PC 16 oder einer Mobilvorrichtung 18 ausgeführt werden. Programm-Module enthalten üblicherweise Routine-Programme, Objekte, Komponenten, Datenstrukturen usw., die bestimmte Aufgaben erfüllen oder bestimmte abstrakte Datentypen implementieren. Außerdem werden diejenigen, die sich in der Technik auskennen, es zu schätzen wissen, dass der Desktopcomputer 16 mit Systemkonfigurationen anderer Computer ausgeführt werden kann, einschließlich Multiprozessorsystemen, der auf Mikroprozessoren basierenden oder programmierbaren Unterhaltungselektronik, Netzwerk-PCs, Kleinrechnern, Großrechnern und dergleichen. Die Erfindung könnte ebenfalls in verteilten Rechenumgebungen ausge führt werden, wobei Aufgaben durch Fernverarbeitungsvorrichtungen durchgeführt werden, die über ein Kommunikationsnetz verbunden sind. In einer verteilten Rechenumgebung können Programm-Module sowohl in lokalen Speichervorrichtungen als auch in Fern-Speichervorrichtungen vorhanden sein.
  • Mit Bezug auf 5 enthält ein beispielhaftes System zur Implementierung des Desktopcomputers 16 eine Rechenvorrichtung für allgemeine Zwecke in Form eines gewöhnlichen PCs 16, einschließlich eines Prozessors 48, eines Systemspeichers 50 und eines Systembusses 52, der verschiedene Systemkomponenten, einschließlich des Systemspeichers 50, mit dem Prozessor 48 verbindet. Bei dem Systembus 52 kann es sich um jede der zahlreichen Arten an Bus-Strukturen handeln, einen Speicherbus oder eine Speichersteuerung, einen Peripheriebus, und einen lokalen Bus eingeschlossen, der jede der zahlreichen Bus-Architekturen anwenden kann. Der Systemspeicher 50 enthält einen Festwertspeicher 54 (ROM) und einen Direktzugriffsspeicher 55 (RAM). Ein BIOS (basic input/output system), das die Grundprogrammroutine enthält, die bei der Übertragung von Informationen zwischen Elementen im Desktopcomputer, wie beispielsweise beim Starten unterstützt, ist im ROM 54 gespeichert. Der Desktopcomputer 16 enthält desweiteren ein Festplattenlaufwerk 57 zum Abrufen von der Festplatte (nicht dargestellt) oder zum Schreiben auf die Festplatte, ein Magnetplattenlaufwerk 58, um etwas von der entnehmbaren Magnetplatte 59 abzurufen oder etwas darauf zu schreiben, sowie ein optisches Laufwerk 60, um etwas von dem entnehmbaren optischen Datenträger 61, beispielsweise eine CD Rom oder andere optische Datenträger, abzurufen oder etwas darauf zu schreiben. Das Festplattenlaufwerk 57, das Magnetplattenlaufwerk 58 und das optische Laufwerk 60 sind über eine Festplattenlaufwerks-Schnittstelle 62, eine Magnetplattenlaufwerks-Schnittstelle 63 und eine optische Laufwerksschnittstelle 64 jeweils mit dem Systembus 52 verbunden. Die Laufwerke und die dazugehörigen, am Computer abrufbaren, Datenträger bieten eine per manente Speicherung von am Computer abrufbaren Befehlen, Datenstukturen, Programm-Modulen und anderen Daten für den Desktopcomputer 16.
  • Obwohl die hierbei beschriebene beispielhafte Umgebung eine Festplatte, eine entnehmbare Magnetplatte 59 und einen entnehmbaren optischen Datenträger 61 verwendet, sollten diejenigen, die sich in der Technik auskennen, es zu schätzen wissen, dass andere Arten von, am Computer abrufbaren, Datenträgern wie Magnetkassetten, Flash-Speicherkarten, DVDs, Bernoulli-kassetten, Direktzugriffsspeicher (RAM), Festwertspeicher (ROM) und dergleichen, die Daten speichern können, auf die vom Computer aus zugegriffen werden kann, auch in der beispielhaften Betriebsumgebung verwendet werden können.
  • Eine Vielzahl von Programm-Modulen können auf der Festplatte, der Magnetplatte 59, dem optischen Datenträger 61, ROM 54 oder dem Direktzugriffsspeicher 55 gespeichert werden, einschließlich des Betriebssystems 65, eines oder mehrerer Anwendungsprogramme 66 (die PIMs enthalten können), anderer Programm-Module 67 (die die Synchronisationskomponente 67 enthalten können), und der Programmdaten 68. Ein Benutzer kann über Eingabevorrichtungen wie die Tastatur 70, die Zeigevorrichtung 72 und das Mikrophon 74 Befehle und Informationen in den Desktopcomputer 16 eingeben. Bei anderen Eingabevorrichtungen (nicht dargestellt) kann es sich um einen Joystick, ein Gamepad, eine Satellitenschüssel, einen Scanner oder dergleichen handeln. Diese und andere Eingabevorrichtungen sind oftmals über eine serielle Anschlussschnittstelle 76 mit dem Prozessor 48 verbunden, können aber durch andere Schnittstellen, wie zum Beispiel eine Soundkarte, eine Parallelschnittstelle, einen Gameport oder einen USB (Universal Serial Bus) verbunden sein. Ein Monitor 77 oder andere Arten von Bildschirmgeräten sind ebenfalls über eine Schnittstelle, wie zum Beispiel einen Videoadapter 78, mit dem Systembus 52 verbunden. Zusätzlich zu dem Monitor 77 können Desktopcomputer üblicherweise andere periphere Ausgabegeräte wie Lautsprecher 75 und Drucker aufweisen.
  • Der Desktopcomputer 16 kann in einer Netzwerkumgebung arbeiten, indem er logische Verbindungen zu einem oder mehreren entfernten Computern (außer der Mobilvorrichtung 18), wie dem entfernten Computer 79, verwendet. Bei dem entfernten Computer 79 kann es sich um einen anderen PC, einen Server, einen Router, einen Netzwerk-PC, ein Peergerät oder einen anderen Netzknoten handeln, und er enthält üblicherweise viele oder alle der Elemente, die weiter oben mit Bezug auf den Desktopcomputer 16 beschrieben wurden, obwohl nur eine Speichervorrichtung 80 in 4 erläutert wurde. Die in 4 aufgezeigten logischen Verbindungen enthalten ein lokales Netz (LAN) 81 und ein Weitverkehrsnetz (WAN) 82. Solche Netzwerkumgebungen sind in Büros, bei Unternehmensinternen Netzwerken (Intranet) und dem Internet üblich.
  • Bei Verwendung des Desktopcomputers 16 in einer LAN-Netzwerkumgebung, wird er über eine Netzwerkschnittstelle oder den Adapter 83 mit dem lokalen Netz (LAN) 81 verbunden. Bei Verwendung des Desktopcomputers 16 in einer WAN-Netzwerkumgebung, enthält er üblicherweise ein Modem 84 oder andere Mittel zur Herstellung der Kommunikation über das Weitverkehrsnetz (WAN) 82, wie beispielsweise das Internet. Das Modem 84, das interner oder externer Art sein kann, wird über die serielle Anschlussschnittstelle 76 mit dem Systembus 52 verbunden. In einer Netzwerkumgebung können Programm-Module, die mit Bezug auf den Desktopcomputer 16 dargestellt sind, oder Teile davon, einschließlich der Synchronisationskomponente 26, in lokalen oder Fern-Speichervorrichtungen gespeichert werden. Man wird es zu schätzen wissen, dass die dargestellten Netzwerkverbindungen beispielhaft sind und dass andere Mittel zum Aufbau einer Kommunikationsleitung zwischen den Computern verwendet werden können.
  • Der Desktopcomputer 16 führt das Betriebssystem 65 aus, das üblicherweise im permanenten Speicher 54 gespeichert ist und auf dem Prozessor 48 läuft. Ein geeignetes Betriebssystem ist ein Windows Betriebssystem der Firma Microsoft Corporation, wie zum Beispiel Windows 95 oder Windows NT, andere abgeleitete Versi onen von Windows Betriebssystemen oder andere geeignete Betriebssysteme. Andere geeignete Betriebssysteme sind beispielsweise Macintosh OS der Firma Apple Corporation sowie der OS/2 Präsentationsmanager der Firma International Business Machines (IBM) aus Armonk, New York. Anwendungsprogramme werden in permanenter oder nicht permanenter Form vorzugsweise im Programm-Modul 67 gespeichert, oder sie können von einer Diskette 59 oder einem CDROM Laufwerk 61 in jede der in 5 dargestellten Komponenten geladen werden, von einem Netzwerk über einen Netzwerkadapter 83 heruntergeladen werden oder unter Verwendung eines anderen geeigneten Mechanismus geladen werden. Eine "dynamically linked library" (DLL), die eine Vielzahl an ausführbaren Funktionen aufweist, wird zur Ausführung durch den Prozessor 48 im Speicher den PIMs zugeordnet. Interprozessoraufrufe und Interkomponentenaufrufe werden unter Verwendung von dem COM (Component Object Model) ermöglicht, wie es bei Programmen üblich ist, die für die Microsoft Windows Betriebssysteme geschrieben wurden. Kurz gesagt hat eine Softwarekomponente wie beispielsweise eine DLL unter Verwendung des COM eine Anzahl an Schnittstellen. Jede Schnittstelle offenbart eine Vielzahl an Methoden, die einzeln aufgerufen werden können, um verschiedene Dienste zu nutzen, die von der Softwarekomponente angeboten werden. Desweiteren sind Schnittstellen vorhanden, damit Methoden oder Funktionen von anderen Softwarekomponenten aufgerufen werden können, die ein oder mehrere Parameterargumente wahlweise empfangen und zurücksenden.
  • Im Allgemeinen ist die DLL, die dem bestimmten PIM oder einem anderen Programm zugeordnet ist, speziell dafür ausgelegt, in Verbindung mit diesem PIM zu arbeiten und Desktop-Synchronisationsschnittstellen gemäß einem Synchronisationsprotokoll freizulegen. Die DLL ruft wiederum Schnittstellen auf, die von dem PIM freigelegt wurden, um so auf Daten zuzugreifen, die einzelne Eigenschaften der Objekte repräsentieren, die in einem Objektspeicher enthalten sind. Der Objektspeicher 6 kann sich natürlich in jedem der geeigneten Speicherkomponenten befinden, die mit Bezug auf 4 beschrieben wurden.
  • 6 ist ein detallierteres Blockdiagramm bestimmter Komponenten eines Systems, das in 1 dargestellt ist.
  • 6 erläutert den Inhaltsprovider 12, den kabellosen Träger 14 und die Mobilvorrichtung 18 auf detailliertere Weise.
  • Der Inhaltsprovider 12 enthält die Kryptographiekomponente 200 und die Komponente 202 zur Erstellung von Nachrichten. 6 erläutert ausserdem eine Übertragungsleitung, die den kabellosen Träger 14 mit der Mobilvorrichtung 18 verbindet. In der in 6 erläuterten Ausführungsform handelt es sich bei dieser Übertragungsleitung um eine kabellose Übertragungsleitung, wie etwa einen Funkrufkanal. Andere Übertragungsleitungen könnten jedoch verwendet werden, um Nachrichten des Inhaltsproviders 12 auf die Mobilvorrichtung 18 zu übertragen, wie etwa die Synchronisationskomponenten 26 und 28 und das oben erwähnte Modem 24. Der Einfachheit halber wird die vorliegende Erfindung nur mit Bezug auf die kabellose Übertragungsleitung ausgeführt.
  • 6 erläutert ausserdem, dass die Mobilvorrichtung 18 eine Radiohardware (Radio HW) 208, einen Treiber 210, einen Router 212, wahlweise zusätzliche Übersetzer 214 und eine Ziel-Speicheradresse 216 aufweist. Die Radio HW 208 enthält vorzugsweise eine Steuerschaltung 218 und hält eine Vielzahl an Datenstrukturen aufrecht. Die Datenstukturen in der Radiokarte 208 in 6 sind in Form von Tabellen erläutert. Dabei handelt es sich jedoch nur um eine beispielhafte Erläuterung. Die Radio HW 208 ist in Wirklichkeit leer, um die Daten auf andere Art und Weise zu speichern, um so die Speicherung oder die Zugriffsgeschwindigkeit zu optimieren. Es ist ausserdem nicht notwendig, dass die Radio HW 208 diese Datenstrukturen ebenfalls speichert. Es handelt sich einfach um eine bevorzugte Ausführung, wenn die Radio HW 208 als auswechselbares Hardwarebauteil (z.B. als Radiokarte der PCMCIA-Art) ausgeführt ist. Das Speichern der Datenstrukturen im permanenten Speicher auf der Radio HW 208, ermöglicht es einem Benutzer, die Karte aus der einen Mobilvorrichtung 18 zu entnehmen und sie in eine andere zu stecken und so die Abonnementinformationen auf einfache Art und Weise auf die neue Mobilvorrichtung 18 zu übertragen. Dadurch wird auch ermöglicht, dass ein größerer Teil der Abonnement-Verwaltungsfunktion (wie z.B. die AnalyzeMessage() oder die anderen unten erwähnten Funktionen) in der Radio Hardware umgesetzt wird. Der Gerätetreiber 210 kann jedoch ebenfalls diese Datenstrukturen im Systemspeicher speichern und die Filterfunktionen und Abonnement-Verwaltungsfunktionen in der Software ausführen, obwohl dies in mancher Hinsicht nicht so ideal ist.
  • In jedem Fall erläutert 6 eine Ausführungsform, in der die Radio HW 208 die Adresstabelle 220, die Gruppeninformations-Tabelle 222 und die Schlüsseltabelle 224 verwaltet. Diese Datenstrukturen sind im Folgenden vollständig erläutert.
  • • Adresstabelle
  • Diese Tabelle dient der Speicherung von adressrelevanten Informationen.
  • Figure 00200001
  • Die Felder, die mit einem '*' versehen sind, können im flüchtigen Speicher (z.B. in dem Register) gespeichert werden, um Speichergröße des permanenten Speichers in der Radio HW zu sparen. Diese wurden in den Größenberechnungen nicht berücksichtigt.
  • Status: Dies ist ein Kennzeichnungsbyte. Die Folgenden sind erläuternde Kennzeichen:
    Figure 00210001
  • Der Treiber ermittelt vorzugsweise Veränderungen im Status des AC und im EIN/AUS Status des Geräts, um die auf ADRESS_FLAG_AC_ONLY und ADRESS_FLAG_PU_ONLY basierenden Adressen freizugeben/ zu sperren zu machen.
    KeyIndex: Wenn nicht-0, wird der Index in die Schlüsseltabelle
    für den zugehörigen Schlüssel eingegeben.
    Dieser Schlüssel wird verwendet, wenn eine
    Nachricht auf dieser Adresse ankommt, die keinen
    Service-Gruppencode verwendet.
    ExpirationDate: Wenn nicht-0, gibt es das Datum an, an dem diese
    Adresse gesperrt würde. Es wird z.B. als Anzahl
    der Tage seit dem 1. Januar 1997 gespeichert.
    Mitternacht wird angenommen (daher ist das
    Ablaufdatum der letzte Tag des Dienstes). Es ist
    zu beachten, dass die Möglichkeit besteht, dass
    die Karte oder der Treiber nicht auf diesen Wert
    reagieren – Anwendungen höherer Levels werden
    auf diesen Wert zugreifen und darauf reagieren.
    AddressTag: Kennzeichen für die Adresse. Das Adresskennzeichen
    wird nur intern zum Programmieren der Adressen und
    zum Zugriff auf die Adressen verwendet.
    AddressInfo: Hierbei handelt es sich um die Adresse und die
    zugehörigen Informationen zur Verwendung des zu
    Grunde liegenden Netzwerks (z.B.: in einem
    FLEX-(Betriebs-)System wäre das der Capcode und die
    zugehörigen Eigenschaften wie der Absturzwert
    (Collapse Value), die Phase, usw.). In Funksystemen wäre
    dies die EIN (equipment identification number).
    AddressName: Erläuternde Bezeichnung für die Adresse (z.B.:
    MSNBC, NewsNow, usw.)
    Description: Erläuternder Text zu der Adresse (z.B.: "Ihr Kanal
    für Börsen und Unternehmensnachrichten")
    • Gesamtgröße = (1 + 1 + 2 + 8 + 32)·16 = 704 Bytes (Für ein FLEX Radio)
  • • Schlüsseltabelle
  • Diese Tabelle wird zum Speichern von sicherheitsrelevanten Informationen verwendet. Hierbei handelt es sich um eine Pool-Resource (zusammengefasste Quellen), da eine oder mehrere Dienstgruppen oder Dienstadressen sich den gleichen Schlüssel teilen können.
    Figure 00220001
    KeyTag: Kennzeichen für den Schlüssel. Das Schlüsselkennzeichen
    wird nur intern zum Programmieren des Schlüssels und zum
    Zugriff auf den Schlüssel verwendet.
    AlgCode: Algorithmuscode zum Codieren. Dieser dient zur Verwendung
    mit dem Sicherheitsalgorithmus.
    Key: Der Sicherheitsschlüssel. Der Treiber unterstützt das
    Speichern von 16-Byte-Schlüsseln (128-bits) für spätere
    Versionen.
    • Gesamtgröße = (8 + 4 + 16)·16 = 448 Bytes
  • • Dienstgruppen-Infotabelle und Dienstgruppen-Iadextabelle
  • Die Dienstgruppen-Tabelle speichert Informationen über die Dienstgruppen. Üblicherweise ist das Nachschlagen des Dienstgruppen-Codes und des zugehörigen Schlüssels eine häufiger anfallende und zeitaufwendigere Aufgabe als die Eingabe oder das Löschen von Dienstgruppen. Daher hat der Treiber vorzugsweise eine Datenstruktur, die so aufgebaut ist, dass sie dies unterstützt.
  • In der unten vorgeschlagenen Ausführung werden die Einträge der Dienstgruppen nach Adressnummern und dann nach Dienstgruppencodes sortiert. Eine separate Dienstgruppen-Indextabelle speichert den Index für den letzten Eintrag einer jeden gegebenen Adresse. (Es ist zu beachten, dass es sich hierbei einfach nur um ein Ausführungsbeispiel handelt. Sie ist für das Nachschlagen des Dienstgruppencodes und die Minimierung der Speicheranforderungen optimiert. Jedes Mal, wenn eine neue Dienstgruppe definiert wird, müssen die Tabelleneinträge nach unten verschoben werden, um Platz dafür zu schaffen. Andere geeignete Ausführungen können jedoch auch verwendet werden.)
  • In einer erläuternden Ausführungsform werden die zugehörigen Dienstgruppen-Einträge nicht entfernt oder auf irgendeine Arte und Weise geändert, wenn die Adresse gesperrt wird (da die Karte jedoch die Nachrichten für diese Adresse auf jeden Fall löscht, werden diese Einträge nicht verwendet werden).
  • KeyIndex ist der Index in der Schlüsseltabelle, der dieser Dienstgruppe zugeordnet ist. Index 0 ist für die Bedeutung "kein Schlüssel vorhanden – der Inhalt für diese Dienstgruppe ist nicht codiert" reserviert.
  • Figure 00240001
  • Figure 00240002
  • Die Felder, die mit einem '*' versehen sind, können im flüchtigen Speicher (z.B. in dem Register) gespeichert werden, um Speichergröße des permanenten Speichers in der Radio HW zu sparen. Diese wurden in den Größenberechnungen nicht berücksichtigt.
  • ServiceGroupCode Der Dienstgruppencode im druckbaren ASCII-Bereich von 0 × 20 und 0 × 7
  • Status: Dies ist ein Kennzeichenbyte. Die folgenden Kennzeichen sind erläuternd definiert.
  • Figure 00250001
  • Der Treiber ermittelt vorzugsweise Veränderungen im Status des AC und im EIN/AUS Status des Geräts, um die auf GROUP_FLAG_AC_ONLY und GROUP_FLAG_PU_ONLY basierenden Serviegruppen freizugeben/ unwirksam zu machen.
    KeyIndex: Wenn nicht-0, wird der Index in die Schlüsseltabelle
    für den zugehörigen Schlüssel eingegeben.
    Dieser Schlüssel wird verwendet, wenn eine
    Nachricht auf diesem Dienstgruppencode ankommt.
    ExpirationDate: Wenn nicht-0, gibt es das Datum an, an dem diese
    Dienstgruppe gesperrt würde. Es wird z.B. als
    Anzahl der Tage seit dem 1. Januar 1997 gespeichert.
    Eine Zeit 12.01 AM (12.01 mittags) wird
    angenommen. Es ist zu beachten, dass die
    Möglichkeit besteht, dass die Karte oder der Treiber
    nicht auf diesen Werte reagieren – Anwendungen
    höherer Levels werden auf diesen Wert
    zugreifen und darauf reagieren.
    ServiceGroupTag: Kennzeichen für die Dienstgruppe. Das
    Dienstgruppenkennzeichen wird nur intern zum Programmieren
    der Dienstgruppe und zum Zugriff auf die
    Dienstgruppen verwendet.
    ServiceGroupName: Erläuternder Bezeichnung für die Dienstgruppe
    (z.B.: "Internationale Nachrichten", "Regionales
    Wetter", usw.). Die vorgeschlagene Größe
    für dieses Feld ist 32, aber OEM kann mehr
    unterstützen.
    Description: Erläuternder Text zu der Dienstgruppe (z.B.
    "Nachrichten aus aller Welt, die ihre kleine
    Gemeinde betreffen"). Die vorgeschlagene Größe für
    dieses Feld ist 64, aber OEM kann mehr unterstützen.
  • Die Indextabelle wird verwendet, um eine Dienstgruppe für eine gegebene Adresse schnell zu finden.
    • Gesamtgröße = (1 + 1 + 1 + 2 + 8)·64 = 832 (Dienstgruppentabelle) (1)·16 = 16 (Indextabelle)j = 848 Bytes
  • 6 erläutert ebenfalls, dass der Treiber 210 eine Sicherheitskomponente 226 und einen nachrichtenspezifischen Schlüsselspeicher 228 aufweist. 6 erläutert ausserdem, dass der Treiber 210 vorzugsweise eine Programmbibliothek unterstützt, die bestimmte Funktionen beinhaltet, die typisch für das System sind, die jedoch der erhöhten Effizienz oder Sicherheit halber vorzugsweise auf dem Level des Treibers ausgeführt werden. Die Unterstützungsbibliothek ist fest mit den restlichen Treiberkom ponenten verbunden. Die in 6 erläuterte Unterstützungsbibliothek des Treibers umfasst die AnalyzeMessage-Funktion 230 und die DeriveEncryptionKey-Funktion 232. Diese Funktionen werden unten detaillierter beschrieben. Es ist ebenfalls zu beachten, dass in einer bevorzugten Ausführungsform die Radio HW 208 und der Treiber 210 zusätzliche Datenstrukturen bzw. Funktionen unterstützen. Bei den hierbei erläuterten Datenstrukturen und Funktionen handelt es sich jedoch um jene, die für ein klares Verständnis der vorliegenden Erfindung notwendig sind.
  • Außerdem ist der Router 212 (der üblicherweise als ein Anwendungsprogramm eingebaut ist) in einer bevorzugten Ausführungsform so konfiguriert, dass er eine Anzahl von E/A-Steuerungsaufrufen zur Ausführung verschiedener Abläufe verwendet. Der Treiber 210 unterstützt und implementiert die E/A-Steuerungsaufrufe nach einem vordefinierten Syntax und eines vordefinierten Ablaufs, der unten beschrieben wird.
  • Die allgemeinen Typen-Definitionen, die in der Treiber API (Application Program Interface – Anwenderprogramm-Schnittstelle) verwendet werden, werden im Folgenden beschrieben. Es ist zu beachten, dass die meisten der folgenden Typen im Wesentlichen den oben erwähnten Datenstrukturen, die durch die Radio HW 208 unterstützt werden, direkt entsprechen, obwohl dies nicht notwendig ist.
  • Die folgenden grundlegenden Typen werden verwendet:
    BYTE 8-bit ohne Vorzeichen
    WORD 16-bit mit Vorzeichen
    DWORD 32-bit mit Vorzeichen
    TEXT In einem BYTE-Array gespeicherte Zeichenkette (string).
    Da die Länge der Zeichenkette üblicherweise in einem
    anderen Feld verfügbar ist, ist keine Null-Termination
    notwendig.
  • Die folgende Typen-Definition zeigen eine erläuternde Minimalgröße an, die der Treiber zur Unterstützung benötigt. Die in der API verwendeten Strukturen (structs) haben in einem anderen Feld die tatsächliche Länge.
    RADIO_TAG Struktur
    TEXT Wert [8] Kennzeichen werden zur Identifizierung
    einer bestimmten Adresse, Dienstgruppe
    oder eines bestimmten Schlüsseleintrages
    verwendet.
    RADIO_KEY Struktur
    BYTE Wert [16] Speichert die Codierungsschlüssel.
    RADIO_NAME Struktur
    TEXT Wert [32] Speichert den Trägernamen, Hersteller
    namen, Adressnamen, usw.
    RADIO_DESC Struktur
    TEXT Wert [64] Speichert die Beschreibung der Karte,
    der Dienste, der Adressen, usw.
  • Komplexe Typen (Strukturen)
  • Alle Strukturen haben die folgenden zwei Felder am Anfang:
    WORD wStructSize Jede Struktur hat festgelegte Größenfelder,
    gefolgt von der Länge der
    variablen Felder. Die variablen Felder
    folgen in der gleichen Reihenfolge wie
    ihre Längen. Das wStructSize-Feld
    beinhaltet die Größe des festgelegten Teils
    der Struktur (d.h., die festgelegten
    Felder und die Längen der variablen
    Felder) in Bytes. Dieses Feld bietet
    auch eine Methode zur Versionierung,
    die in den zukünftigen Versionen für
    die Abwärtskompabilität verwendet wird.
    DWORD dwMemberValidMask Eine Maske, die angibt, welche festgelegten
    Größenfelder der Struktur gültig
    sind und verwendet werden können (für
    variable Größenfelder gibt eine Länge
    mit dem Wert 0 an, dass das Feld nicht
    vorhanden ist). Dies ermöglicht es uns,
    die gleiche Struktur zu verwenden,
    selbst wenn manche Felder nicht notwendig
    sind. Das ist insbesondere dann
    nützlich, wenn ein einzelnes Feld in
    einer Struktur programmiert wird, ohne
    die Werte anderer Felder zu ändern.
  • Außerdem sind die variablen Längenfelder zum Ende hin angeordnet und für jedes von ihnen ist ein Längenfeld vorhanden. Dies ermöglicht die Erweiterung dieser Strukturen, ohne dass die Abwärts- oder Aufwärtskompabilität verloren geht. Bei Zugriff auf die variablen Längenfelder, sollte der Treiber den Wert des wStrukturGröße-Felds als Startabstand für das erste variable Längenfeld verwenden. Dies wird die Aufwärtskompabilität ermöglichen, wenn der Struktur zusätzliche Felder hinzugefügt werden (die Verwendung eines wStructSize-Felds stellt sicher, dass diese neuen Felder von den Alttreibern ignoriert werden).
  • Obwohl eine grobe Auswahl an spezifischen Strukturarten beim normalen Betrieb der Treiber API verwendet werden, werden hierbei nur diejenigen erörtert, die sich auf die vorliegende Erfindung beziehen. Solche Strukturen umfassen die Folgenden:
  • RADIO_ADDRESS Struktur
  • Diese Struktur enthält Informationen über die Adresse.
    Figure 00300001
    WORD wStructSize Größe von (RADIO_ADDRESS)
    DWORD dwMemberValidMask Eine Maske, die angibt, welche
    Felder der Struktur gültig sind.
    Erstellen des Werts durch eine
    'ODER'-Verknüpfung von einem oder
    mehreren der folgenden:
    0 × 0001 AdressNumber-Feld ist
    gültig
    0 × 0002 Statusfeld ist gültig
    0 × 0004 ExpirationDate-Feld ist
    gültig
    BYTE AdressNumber Adressseintragsnumer.
    Adresseinträge sind von 0 aufwärts
    nummeriert.
    BYTE Status Statuskennzeichen.
    BYTE ExpirationDate (2) Ablaufdatum. Ist 0, wenn keins
    vorhanden ist.
    BYTE AdressTagLen Länge des AdressTag-Felds.
    BYTE KeyTagLen Länge des KeyTag-Felds.
    BYTE AdressNameLen Länge des AdressName-Felds
    WORD wAdressDescriptionLen Länge des AdressDescription-Felds
    WORD wAdressInfoLen Länge des Adressinfo-Felds
    RADIO_TAG AdressTag Adresskennzeichen
    RADIO_TAG KeyTag Zu dieser Adresse zugehöriger
    Schlüssel. (Wenn das Feld nicht
    vorhanden ist, ist dieser Adresse
    kein Schlüssel zugeordnet).
    RADIO_DESC AdressBeschreibung Beschreibung zu der Adresse.
    Es ist zu beachten, dass diese
    Information nicht unbedingt in
    dem permanenten Speicher vorliegen
    muss. Sie wird dem Benutzer
    nur zu Informationszwecken
    gezeigt.
    RADIO_ADRESS AdressInfo Adress- und zugehörige
    Informationsfelder. Diese Struktur ist
    protokollspezifisch. Für das
    FLEX-Protokoll kann es den die
    Capcode-Information codierenden
    Absturzwert (Collapse Value), die
    Phase, die Adresse usw. enthalten.
  • Struktur RADIO_GROUP
  • Diese Struktur enthält Informationen über die Dienstgruppe.
    Figure 00320001
    WORT wStructSize Größe von (RADIO_GROUP)
    DWORT dwMemberValidMask Eine Maske, die angibt, welche
    Felder der Struktur gültig sind.
    Erstellen des Werts durch eine
    'ODER'-Verknüpfung von einem oder
    mehreren der folgenden:
    0 × 0001 GroupNumber-Feld ist
    gültig
    0 × 0002 Statusfeld ist gültig
    0 × 0004 GroupCode-Feld ist
    gültig
    0 × 0008 ExpirationDate-Feld ist
    gültig
    WORT wGroupNumber Dienstgruppennummer. Dienstgruppen
    sind von 0 aufwärts nummeriert.
    BYTE Status Status Kennzeichen.
    BYTE Groupcode Dienstgruppencode.
    BYTE ExpirationDate [2] Ablaufdatum. Ist 0, wenn keins
    vorhanden ist.
    BYTE GroupTagLen Länge des GroupTag-Felds.
    BYTE KeyTagLen Länge des KeyTag-Felds.
    BYTE AdressTagLen Länge des GroupTag-Felds
    BYTE GroupNameLen Länge des GroupName-Felds.
    WORD wGroupDescriptionLen Länge des GroupDescription-Felds.
    RADIO_TAG GroupTag Dienstgruppenkennzeichen.
    RADIO_TAG KeyTag Zu dieser Dienstgruppe zugehöriger
    Schlüssel. (Wenn das Feld nicht
    vorhanden ist, ist dieser Dienstgruppe
    kein Schlüssel zugeordnet).
    RADIO_TAG AddressTag Die Adresse, zu der die Dienstgruppe
    gehört.
    RADIO_DESC GroupDescription Beschreibung zu der Dienstgruppe.
    Es ist zu beachten, dass diese
    Information nicht im permanenten
    Speicher gespeichert sein muss. Sie
    wird dem Benutzer nur zu Informationszwecken
    gezeigt.
  • Struktur RADIO_KEY
  • Diese Struktur enthält Informationen über die Codierschlüssel.
    Figure 00340001
    WORT wStructSize Größe von (RADIO_KEY)
    DWORT dwMemberValidMask Eine Maske, die angibt, welche
    Felder der Struktur gültig sind.
    Erstellen des Werts durch eine
    'ODER'-Verknüpfung von einem oder
    mehreren der folgenden:
    0 × 0001 KeyNumber-Feld ist
    gültig
    0 × 0002 dwAlgCode-Feld ist gültig
    BYTE KeyNumber Schlüsselnummer, Schlüssel sind
    von 1 an aufwärts nummeriert.
    DWORT dwAlgCode Codierungs-Algorithmus-Code.
    BYTE KeyTagLen Länge des KeyTag-Felds.
    BYTE KeyLen Länge des Key-Felds.
    RADIO_TAG KeyTag Schlüsselkennzeichen.
    RADIO_KEY Key Der Codierungsschlüssel.
  • Struktur RADIO_CRYPT
  • Diese Struktur wird verwendet, um funktionsrelevante E/A-Steuerungsaufrufe zu verschlüsseln.
    Figure 00350001
    WORT wStructSize Größe von (RADIO_CRYPT)
    DWORT dwMemberValidMask Eine Maske, die angibt, welche
    Felder der Struktur gültig sind.
    Erstellen des Werts durch eine
    'ODER'-Verknüpfung von einem oder
    mehreren der folgenden:
    0 × 0001 hCryptoProv-Feld ist
    gültig
    0 × 0002 dwCryptoFlags-Feld ist
    gültig
    0 × 0004 dwCryptoAlgId-Feld ist
    gültig
    HCRYPTOPROV hCryptoProv Kennung für einen
    Kryptographie-Service-Provider.
    DWORD dwCryptoAlgId Kryptographie-Algorithmus ID (ID =
    Anwenderkennung), z.B. CALG_RC4
    DWORD dwCryptoFlags Kennzeichen für die Kryptographiefunktion
    CryptDeriveKey (), z.B.
    CRYPT_EXPORTABLE
    BYTE AdressTagLen Länge des AdressTag-Felds
    BYTE GroupTagLen Länge des GroupTag-Felds
    WORT wMsgSpecificDataLen Länge des MsgSpecificData-Felds
    RADIO_TAG AdressTag Adresskennzeichen
    RADIO_TAG GroupTag Dienstgruppenkennzeichen
    BYTE MsgSpecificData () Nachrichtenspezifische Daten
  • Wie oben erwähnt wurde, finden die E/A-Steuerungsaufrufe vom Router 212 zum Treiber 210 statt, um bestimmte Abläufe zu erreichen. Wie bei den zahlreichen Datenstrukturen werden eine Vielzahl an E/A-Steuerungsaufrufen in der Treiber-API unterstützt.
  • Es werden jedoch nur diejenigen hier erläutert, die sich auf die vorliegenden Erfindung beziehen.
  • E/A-Steuerungsaufrufe haben die folgende Syntax: Syntax
    Figure 00360001
    Parameter
    hOpenContext Bestimmt eine Kennung, die den offenen
    Kontext des Geräts ermittelt. Die
    xxx_Open-Funktion erstellt diese
    Identifizierung und gibt sie zurück.
    dwCode Bestimmt einen Wert, der den
    auszuführenden E/A-Steuerungsablauf angibt.
    Diese Codes sind gerätespezifisch und
    werden Anwendungsprogrammierern
    üblicherweise durch eine Header-Datei
    offenbart.
    pBufIn Weist auf den Puffer hin, der Daten
    enthält, die auf das Gerät übertragen
    werden sollen.
    dwLenIn Bestimmt die Anzahl an Bytes der Daten
    in dem Puffer, der für pBufIn festgelegt
    ist.
    pBufOut Weist auf den Puffer hin, der verwendet
    wird, um Ausgabedaten vom Gerät zu
    übertragen.
    dwLenOut Bestimmt die maximale Anzahl an Bytes in
    dem Puffer, der durch pBufOut festgelegt
    ist.
    pdwActualOut Weist auf den DWORD Puffer hin, den die
    Funktion verwendet, um die tatsächliche
    Anzahl an Bytes wiederzugeben, die von
    dem Gerät empfangen wurde.
  • Rückmeldung
  • Gibt TRUE aus, wenn das Gerät seinen festgelegten E/A-Steuerungsablauf erfolgreich durchlaufen hat, andernfalls gibt er FALSE aus.
  • RADIO_GET_XXX_INFO
  • Dieser EA-Steuerungsaufruf ermöglicht es der aufrufenden Person, Informationen über den Träger, den Hersteller, die Karte usw. zu erhalten. Die E/A-Steuerungscodes sind:
    RADIO_GET_CARRIER_INFO Erhält die RADIO_CARRIER_INFO Struktur
    RADIO_GET_MANUFACTURER_INFO Erhält die RADIO_MANUFACTUTER_INFO
    Struktur
    RADIO_GET_DRIVER_INFO Erhält die RADIO_DRIVER_INFO Struktur
    RADIO_GET_HW_INFO Erhält die RADIO_HW_INFO Struktur
    RADIO_GET_ADRESS_INFO Erhält die RADIO_ADRESS Struktur (siehe
    Anmerkungen unten)
    RADIO_GET_GROUP_INFO Erhält die RADIO_GROUP Struktur (siehe
    Anmerkungen unten)
    RADIO_GET_KEY_INFO Erhält die RADIO_KEY Struktur (siehe
    Anmerkungen unten)
  • Syntax
  • Für Informationen über Träger, Hersteller, Treiber und Hardware:
    Figure 00380001
    Figure 00390001
  • Für Informationen über Adresse, Gruppe und zum Schlüssel:
    Figure 00390002
  • Ablauf
  • Dieser E/A-Steuerungsaufruf gibt die angeforderte Informationsstruktur wieder. Für Informationen über Adresse, Gruppe und zum Schlüssel muss der Eingabepuffer, der die entsprechende Struktur beinhaltet, in einer erläuternden Ausführungsform vorgegeben sein, und in dieser Struktur muss entweder das Nummern- oder das Kennzeichenelement initialisiert sein. RADIO_GET_ADRESS_INFO erfordert es beispielsweise, dass entweder das AdressNumber-Element oder das AdressTag-Element in pInBuf[] auf die gewünschte Adresse festgelegt wird. Wenn beide gegeben sind, wird Adress-Number verwendet.
  • Wenn pBufOut NULL ist und dwLenOut gleich 0 ist, gibt der Aufruf die für die Daten in pdwActualOut benötigte Nummer oder Bytes zurück. Die aufrufende Person kann dann einen Puffer von dieser Größe zuweisen und diesen Aufruf erneut durchführen.
  • Anmerkungen
  • Für den RADIO_GET_ADRESS_INFO Aufruf wird das AdressInfo-Feld in einer erläuternden Ausführungsform ebenfalls NIE ausgegeben. Dies geschieht zum Schutz der Programmierinformation.
  • Ferner wird für den RADIO_GET_KEY_INFO Aufruf das Key-Feld NIE ausgegeben. Dies geschieht zum Schutz der Codierungsschlüssel.
  • RADIO_CRYPT_DERIVE_KEY
  • Dieser E/A-Steuerungsaufruf ermöglicht es dem aufrufenden Benutzer, eine Adresse, eine Dienstgruppe, Schlüssel oder Trägerinformationen zu programmieren oder zu de-programmieren.
  • Syntax
    Figure 00400001
  • Ablauf
  • Diese E/A-Steuerung wird von der Sicherheitskomponente des Systems verwendet. Sie wird verwendet, um eine Kennung zu einem Schlüssel zu erhalten. Hierfür ist der Zugriff auf die Elektronische ID (EID = Elektronische Anwenderkennung) notwendig, die nicht ausserhalb des Treibers offenbart werden sollte. Eine DeriveEncryptionKey()-Funktion ist in der Unterstützungsbibliothek des Treibers vorhanden und wird unten detaillierter beschrieben, um die E/A-Steuerung auszuführen. Der Treiber sollte diese Funktion aufrufen und die Kennung an den von ihr ausgegebenen Schlüssel (hKey) weitergeben. Auf diese Art und Weise kann eine Sicherheitskomponente eine Kennung zu dem Schlüssel erhalten, ohne einen Zugriff auf die EID zu erhalten.
  • Um die E/A-Steuerungsaufrufe zu implementieren, ruft der Treiber 210 eine Anzahl der in seiner Unterstützungsbibliothek gespeicherten Funktionen auf. Solche Funktionen werden unten beschrieben: AnalyzeMessage() Syntax
    Figure 00410001
    pMsg Zeiger zu den Bytes der Nachricht.
    dwMsgLen Länge der Nachricht
    pDiscard Empfängt einen BOOL-Wert, der angibt,
    ob die Nachricht gelöscht oder erhalten
    werden soll.
    pServiceGroupCode Empfängt den Dienstgruppen-Code.
  • Ausgaben
  • Gibt TRUE aus, wenn der Dienstgruppen-Code gefunden wurde, ansonsten FALSE.
  • Beschreibung
  • Diese Funktion analysiert die Nachricht, um festzustellen, ob sie einen Dienstgruppen-Code aufweist. Sie kann auch analysieren, ob die Nachricht andere Kennzeichen aufweist, um festzulegen, ob diese Nachricht gelöscht oder behalten werden soll.
  • DeriveEncryptionKey() Syntax
    Figure 00420001
  • Einige Parameter für diese Funktion werden von der aufrufenden Person eingegeben, der Treiber gibt sie lediglich an diese Funktion weiter. Die restlichen Parameter stehen dem Treiber in seiner internen Datenstruktur zur Verfügung.
    pCrypt_Input Eingabe zum
    RADIO_CRYPT_DERIVE_KEY
    E/A-Steuerungsaufruf
    pbKeyValue Der zu verwendende Schlüssel
    beruht auf den AdressTag- und
    GroupTag-Feldern innerhalb
    der RADIO_CRYPT Struktur (Die
    den E/A-Steuerungsaufruf
    durchführende Person stellt
    diese zwei Felder bereit. Der
    Treiber muss sie verwenden,
    um den in der Schlüsseltabelle
    gespeicherten Schlüssel
    zu lokalisieren und den
    Schlüssel dann in den
    pbKey-Parameter weiterzugeben).
    dwKeySize Anzahl der Bytes in dem
    pbKeyValue Parameter.
  • Ausgaben
  • Diese Funktion gibt TRUE aus, wenn der Vorgang erfolgreich war, ansonsten FALSE. Wenn er erfolgreich war, gibt sie ausserdem eine Kennung zu dem Schlüssel aus, die aus den gegebenen Informationen erzeugt wurde.
  • Beschreibung
  • Die Codierungsschlüssel werden auf einer oder mehreren der folgenden Informationen basierend berechnet: der Adresse zugeordneter Schlüssel, der Dienstgruppe zugeordneter Schlüssel, nachrichtsspezifische Daten, bestimmte Kennzeichen und eine Algorithmus-Kennung. Diese Funktion verarbeitet das alles und erzeugt eine Kennung zu einem Schlüssel, die vom Aufrufablauf verwendet werden kann, um die Codierungs-/Decodierungsabläufe durchzuführen.
  • 6 erläutert ausserdem, dass die Sicherheitskomponente 226 eine Kryptographie-Anwendungs-Programmierschnittstelle (Crypto-API oder CAPI) 236 aufweist, sowie einen kryptographischen Serviceprovider 238. CAPI 236 bietet eine Reihe von Funktionen, die es anderen Softwarekomponenten ermöglichen, Daten auf flexible Art und Weise zu decodieren. In einer bevorzugten Ausführungsform ist CAPI 236 als die Kryptographie-Anwendungs-Programmierschnittstelle (CryptoAPI) implementiert, die von der Firma Microsoft Corporation of Redmond, Washington, im Handel erhältlich ist. Der kryptographische Serviceprovider 238 ist vorzugsweise als Einzelmodul ausgeführt, das kryptographische Operationen durchführt. Ein solcher kryptographischer Serviceprovider ist im Handel unter dem Markennamen Microsoft RSA Hase Provider erhältlich. Andere kryptographische Serviceprovider könnten jedoch ebenfalls verwendet werden. Manche solcher kryptographischen Serviceprovider bieten stärkere kryptographische Algorithmen an, während andere Hardwarekomponenten, wie beispielsweise Chipkarten (smart cards) aufweisen. Daher können Programm-Module Funktionen verwenden, die von der CAPI 236 freigelegt wurden, ohne den zu Grunde liegenden kryptographischen Algorithmus zu kennen.
  • In Übereinstimmung mit einem erläuternden Aspekt der vorliegenden Erfindung, können der Inhaltsprovider 12 und der Träger 14 sowohl codierte Programmiernachrichten senden, die zur Programmierung von Werten in die Radio HW 208 verwendet werden, als auch codierte Inhaltsnachrichten, die nur von Mobilvorrichtungen 18 empfangen und verarbeitet werden können, die die passenden Decodierungsschlüssel aufweisen, welche zur Decodierung der Inhaltsnachrichten zur weiteren Verwendung durch die Mobilvorrichtung 18 verwendet werden können. Der Treiber 210 ist so konfiguriert, dass er die Integrität des Codierungsschlüssels in einer sicheren Umgebung aufrecht erhält, sogar während der Decodierung von entweder Programmier- oder Inhaltsnachrichten.
  • Die Radio HW 208 hat eine Anzahl von progammierbaren Adress-Schlitzen. Zur Erweiterung der Verwendungszwecke, denen jede Adresse zugeordnet werden kann, teilt die vorliegende Erfindung ausserdem die Sendeadressen in Unteradressen auf, die als Gruppen bezeichnet und durch Gruppencodes bestimmt werden. Eine Adresse könnte beispielsweise verwendet werden, um Nachrichteninformationen zu übertragen, während ein Gruppencode verwen det werden könnte, um Unterteilungen der Nachrichten, wie z.B. nationale Nachrichten, regionale Nachrichten und internationale Nachrichten zu übertragen.
  • In einer bevorzugten Ausführungsform speichert die Mobilvorrichtung 18 einen Codierungsschlüssel für jede Sendeadresse sowie für jeden Gruppencode. Alternativ kann ein Schlüssel für eine Adresse und all ihre Gruppen verwendet werden, oder für jede andere Kombination, die Adressen und Gruppen einbezieht. Die Mobilvorrichtung 18 ist ausserdem vorzugsweise mit einer elektronischen Identifizierung (EID) vorprogrammiert, die vom Hersteller der Mobilvorrichtung 18 während der Produktion erzeugt und zugewiesen wird. Die EID wird vorzugsweise willkürlich erzeugt und beruht in keinster Weise auf und hat keinerlei Bezug zu der Seriennummer des Geräts (die ausserhalb des Geräts erkennbar sein könnte). Die EID wird von dem Hersteller der Mobilvorrichtung 18 und des kabellosen Trägers 14 vertraulich verwahrt.
  • Um eine effiziente Abonnementverwaltung zu ermöglichen, müssen daher eine Vielzahl von Operationen durchgeführt werden. Zuerst werden der Inhaltsprovider 12 und der Träger 14 vorzugsweise so eingerichtet, dass sie eine Mobilvorrichtung 18 mit Adressen und Gruppencodes programmieren, über die der Benutzer der Mobilvorrichtung 18 die gewünschten Dienste empfangen kann. Um die Dienste nur den gewünschten oder ausgewählten Mobilvorrichtungen 18 zu ermöglichen, die diese Dienste abonniert haben, werden sowohl die Programmiernachrichten, die zur Programmierung der Adressen und Gruppencodes in die Mobilvorrichtung 18 verwendet werden, als auch die Inhaltsnachrichten codiert. Daher sind der Inhaltsprovider 12 und der kabellose Träger 14 ebenfalls vorzugsweise so konfiguriert, dass sie die Mobilvorrichtung 18 mit den notwendigen Codierungsschlüsseln zur Decodierung von Programmier- und Inhaltsnachrichten programmieren.
  • Der kabellose Träger 14 beinhaltet vorzugsweise die Adressen, wohingegen sich die Gruppencodes im Inhaltsprovider 12 oder im kabellosen Träger 14 befinden können. Zur Verwaltung seiner Abonnements ist der Inhaltsprovider 12 daher vorzugsweise so konfiguriert, dass er die Mobilvorrichtung 18 durch den kabellosen Träger 14 mit neuen Gruppenschlüsseln (oder Sendeschlüsseln) umprogrammiert, ohne die Gruppenschlüssel (oder Sendeschlüssel) anderer Inhaltsprovider ändern zu können, die Dienste durch den kabellosen Träger 14 oder durch andere kabellose Träger anbieten könnten. Dadurch ist es dem Inhaltsprovider 12 möglich, die zur Codierung der Inhaltsnachrichten verwendeten Codierungsschlüssel zu drehen, um die Sicherheit des Übertragungssystems zu erhöhen.
  • Da die Inhaltsnachrichten des Inhaltsproviders 12 codiert sind, ist der Inhaltsprovider 12 natürlich vorzugsweise so konfiguriert, dass er diese Nachrichten auf sichere Art und Weise codiert, so dass sie nur von den Mobilvorrichtungen 18 decodiert werden können, die die notwendigen Sendeschlüssel enthalten.
  • Da sowohl die Programmiernachrichten als auch die Inhaltsnachrichten codiert sind, ist die Mobilvorrichtung 18 vorzugsweise so eingerichtet, dass sie solche Nachrichten sicher decodieren kann, um so die Integrität der Codierungsschlüssel aufrecht zu erhalten, die zur Codierung und Decodierung der Nachrichten verwendet werden.
  • DIE PROGRAMMIERUNG DER MOBILVORRICHTUNG 18
  • 7 ist ein Flussdiagramm, das in Verbindung mit 6 besprochen werden wird, und welches erläutert, wie der Inhaltsprovider 12 und der kabellose Träger 14 Adressen, Gruppencodes und entsprechende Codierungsschlüssel in die Mobilvorrichtung 18 programmieren, um einem neuen Abonnenten den Empfang der gewünschten Dienste zu ermöglichen.
  • Der Inhaltsprovider 12 empfängt eine Meldung von einem bestimmten Benutzer einer Mobilvorrichtung 18, dass der Benutzer ein Abonnement bestimmter Diensten erhalten möchte. Der Inhalts provider 12 fordert daher den kabellosen Träger 14 auf, einen passenden Gruppencode oder eine passende Gruppenadresse in die gewünschte Mobilvorrichtung 18 zu programmieren. Dies ist durch den Block 242 in 7 dargestellt. Der Inhaltsprovider 12 leitet dann die Identität des Benutzers sowie die Seriennummer des vom Benutzer verwendeten Pagers oder einer anderen Mobilvorrichtung 18 an den kabellosen Träger 14 weiter. Dies ist durch den Block 244 in 7 dargestellt.
  • Als Reaktion darauf erzeugt der kabellose Träger 14 einen vorübergehenden willkürlichen Sendeschlüssel, der vom Inhaltsprovider vorübergehend zur Übertragung der Dienste an die Mobilvorrichtung 18 verwendet wird. Der kabellose Träger 14 gibt den vorübergehenden Sendeschlüssel dann an den Inhaltsprovider 12 zurück. Dies ist durch die Blöcke 246 und 248 dargestellt.
  • Der kabellose Träger 14 bereitet dann unter Verwendung eines geheimen Schlüssels eine codierte Programmnachricht vor, die nur dem kabellosen Träger 14 und dieser einzelnen Mobilvorrichtung 18 bekannt ist, die programmiert wird. Der geheime Schlüssel könnte beispielsweies die durch den Hersteller in die Mobilvorrichtung programmierte EID sein, die nur gemeinsam mit dem kabellosen Träger 14 verwendet wird. Dies ist durch den Block 250 dargestellt. Der kabellose Träger 14 überträgt dann die Programmiernachricht an die Mobilvorrichtung 18. Dies ist durch Block 252 dargestellt.
  • Die Mobilvorrichtung 18 empfängt die Programmiernachricht, identifiziert sie als Programmiernachricht und decodiert die Nachricht. Die Mobilvorrichtung 18 stellt den neuen Adress- oder Gruppencode dann der Radio HW 208 zur Verfügung, die den neuen Adress- oder Gruppencode in die entsprechende Tabelle auf der Radio HW 208 programmiert. Dies ist durch den Block 254 dargestellt. Die Mobilvorrichtung 18 stellt den vorübergehenden Sendeschlüssel (der ebenfalls mit der Programmiernachricht übertragen wurde) auch der Radio HW 208 zur Verfügung, die den vorübergehenden Sendeschlüssel in die Schlüsseltabelle 224 program miert. Dies ist durch den Block 256 dargestellt. Der vorübergehende Sendeschlüssel wird dem neu programmierten Adress- oder Gruppencode (oder beiden) zugeordnet und wird von der Mobilvorrichtung 18 verwendet, um zumindest die erste codierte Nachricht zu decodieren, die vom Inhaltsprovider 12 erzeugt wurde.
  • Es ist zu beachten, dass der kabellose Träger 14 eine weitere Programmiernachricht auf ähnliche Weise an die Mobilvorrichtung 18 senden kann, um so den neuen Adress- oder Gruppencode unwirksam zu machen. Wenn der Benutzer der Mobilvorrichtung 18 beispielsweise das Abonnement beenden möchte, kann der kabellose Träger 14 eine Programmiernachricht bereitstellen, die den neuen Adress- oder Gruppencode im Wesentlichen von der Mobilvorrichtung 18 entfernt. Wenn der Benutzer nur vorübergehend aussteigt (weil er z.B. in den Urlaub fährt oder aufhört, die Abonnementgebühr zu zahlen), kann der Inhaltsprovider 12 ebenfalls eine Programmiernachricht erzeugen (welche durch den kabellosen Träger 14 nur an die Mobilvorrichtung 18 geschickt werden kann), die den neuen Adress- oder Gruppencode unwirksam macht. In beiden Fällen ist es dem Benutzer der Mobilvorrichtung 18 nicht länger möglich, Inhaltsnachrichten vom Inhaltsprovider 12 zu empfangen.
  • ÄNDERN DER SENDESCHLÜSSEL
  • Bei den 8A–8C handelt es sich um Diagramme, die erläutern, wie der Inhaltsprovider 12 den vorübergehenden Sendeschlüssel in seinen eigenen Sendeschlüssel umwandelt, oder einfach nur den Sendeschlüssel dreht, der gegenwärtig in der Mobilvorrichtung 18 enthalten ist. Die 8A–8C werden auch in Verbindung mit 6 beschrieben. Natürlich können andere geeignete Codierungsschemata verwendet werden, aber die 8A–8C erläutern ein erläuterndes Codierungsschema. Genau genommen erläutern die 8A und 8B die Bildung eines Codierungsschlüssels (festgelegter Programmierschlüssel) und einer codierten Nachricht gemäß eines Aspekts der vorliegenden Erfindung.
  • Um den Programmierschlüssel zu erhalten, verwendet die vorliegende Erfindung nachrichtenspezifische Daten 58 und den alten Schlüssel 260, der gegenwärtig auf der Mobilvorrichtung 18 gespeichert ist. In dem Fall, dass der Inhaltsprovider 12 den vorübergehenden Sendeschlüssel ändert, entspricht der der alte Schlüssel 260 dem vorübergehenden Sendeschlüssel, der dann auf der Mobilvorrichtung 18 gespeichert wird. Bei den nachrichtenspezifischen Daten 258 handelt es sich vorzugsweise um einen Teil des alten Schlüssels 260 selbst, aber es kann sich auch um andere nachrichtenspezifische Informationen handeln. Die nachrichtenspezifischen Daten 258 ändern sich daher mit jeder gesendeten Nachricht. Der alte Schlüssel 260 wird durch die Komponente 202 zur Nachrichtenerzeugung erstellt (oder abgerufen) und wird zusammen mit den nachrichtenspezifischen Daten der Kryptographiekomponente 200 im Inhaltsprovider 12 (von dem alle in 6 dargestellt sind) zur Verfügung gestellt. Die Kryptographiekomponente 200 stellt nachrichtenspezifische Daten 258 und den alten Schlüssel 260 einer HMAC (hashed message authentication code)-Generatorkomponente 262 zur Verfügung. Der HMAC-Generator 262 berechnet einen Hash-Wert, der zur Ausrichtung eines Schlüsselberechnungs-Algorithmus verwendet wird. Der durch den HMAC erzeugten Wert hat die folgende Eigenschaft: sein Wert hängt von den Eingabedaten (MSD 258 – nachrichtenspezifische Daten – und der alte Schlüssel 260) ab, und schon eine kleine Bit-Veränderung in einer der Daten führt zu einem völlig neuen Hash-Wert. Bei einem gegebenen Hash-Wert ist es zugleich äußerst schwierig zu entschlüsseln, welche Eingabedaten zur Erzeugung verwendet wurden.
  • Die Bias-Komponente wird der Schlüsselberechnungskomponente zur Verfügung gestellt, die auf die Bias-Komponente wirkt, um den Programmierschlüssel 266 zu berechnen. Da die MSD 258 zur Erzeugung des Ausrichtungswertes verwendet werden und sich die MSD 258 für jede Nachricht ändern, ist es logisch, dass sich der Programmierschlüssel 266 für jede Programmiernachricht ändern wird, sogar wenn sie für dieselbe Mobilvorrichtung gedacht ist. Das macht es äußerst schwierig, den Programmierschlüssels zu entschlüsseln (wenn derselbe Schlüssel in einer Stromverschlüsselung wiederholt verwendet wird, um Vielfach-Nachrichten zu codieren, dann reicht es aus, eine Einzel-Nachricht zu kennen oder zu erraten, um den Rest zu erschließen). Selbst wenn der Schlüssel decodiert wurde, ist es überdies sinnlos, da die nächste Nachricht nicht den gleichen Schlüssel verwenden wird. Daher bietet das vorliegende System einen hohen Grad an Sicherheit, außer ein nicht autorisierter Benutzer kennt eine Vielzahl an Informationen, wie beispielsweise die MSD 258, den alten Schlüssel 260, den HMAC 262 Algorithmus, usw.
  • Der Programmierschlüssels 266 wird verwendet, um den neuen Sendeschlüssel zu codieren, der von der Mobilvorrichtung 18 verwendet wird, um Nachrichten zu decodieren, die über den neuen Adress- oder Gruppencode empfangen wurden, der in die Mobilvorrichtung programmiert wurde. In einer erläuternden Ausführungsform wird der API CryptDeriveKey verwendet, um den Programmierschlüssel 266 zu berechnen. Der API CryptDeriveKey ist eine gewöhnliche Windows API, die den Schlüssel für Standardkryptographiealgorithmen berechnet.
  • 8H erläutert die Codierung des neuen Schlüssels 268 unter Verwendung des Programmierschlüssels 266. Der Programmierschlüssel 266 und der neue Schlüssel 268 werden der Codierungskomponente 270 zur Verfügung gestellt, die den neuen Schlüssel 268 unter Verwendung des Programmierschlüssels 266 codiert. Jede geeignete Codierungsmethode kann von der Codierungskomponente 270 eingesetzt werden. Die Ausgabe der Codierungskomponente 270 ist ein codierter neuer Schlüssel 272. Der codierte neue Schlüssel 272 wird dann zurück an die Nachrichtenerstellungskomponente 202 am Inhaltsprovider 12 gegeben. Die Nachrichtenerstellungskomponente 202 hängt dann die nachrichtenspezifischen Daten 258 in nicht codierter Form an den codierten neuen Schlüssel 272 an. Die Nachrichtenerstellungskomponente 202 fügt dann dem codierten neuen Schlüssel 272 und den nachrichtenspezifischen Daten 258 einen Header 274 hinzu. Bei dem Header 274 handelt es sich vorzugsweise um eine Byte-Sequenz, die eine Vielzahl an Zwecken erfüllt. Zuerst identifiziert er eine Nachricht als Programmiernachricht. Dann ermittelt er den Anfang und das Ende des codierten Teils 272 der Nachricht, und den Anfang und das Ende des nachrichtenspezifischen Datenteils 258 der Nachricht (der nicht codiert ist). Als letztes ermittelt der Header 274, ob die EID (oder ein anderer geheimer Schlüssel) zum Berechnen der Nachricht verwendet wurde. Es ist zu beachten, dass dem kabellose Träger 14 die Verantwortung für das Hinzufügen des Headers 274 an die Nachricht übertragen werden kann. In jedem Fall wird die Nachricht dann dem kabellosen Träger 14 zur Verfügung gestellt, der die Nachricht zur Übertragung über die Übertragungsleitung in geeigneter Form anordnet, und die Nachricht auf die Mobilvorrichtung 18 überträgt.
  • 8C ist ein Flussdiagramm, dass die Erstellung der Programmiernachricht erläutert, die in den 8A und 8B erläutert wurde. Zuerst werden die nachrichtenspezifischen Daten (oder andere Daten) zusammen mit dem alten Sendeschlüssel erhalten. Dies ist durch die Blöcke 276 und 278 dargestellt. Der Hash-Wert wird dann berechnet, wie in Block 280 dargestellt ist. Der Programmierschlüssel wird dann basierend auf dem in Block 280 erzeugten Hash-Wert berechnet. Dies ist durch den Block 282 dargestellt.
  • Der neue Schlüssel wird dann erhalten und mit Hilfe des Programmierschüssels codiert. Dies ist durch die Blöcke 284 und 286 dargestellt. Die nachrichtenspezifischen Daten sowie der Header werden dann dem codierten neuen Schlüssel hinzugefügt, und die Nachricht wird übertragen. Dies ist durch die Blöcke 288, 290 und 292 dargestellt.
  • Sobald die Mobilvorrichtung 18 die Programmiernachricht empfängt, wird die Programmiernachricht decodiert, um den neuen Schlüssel zu erhalten, der dem, in die Mobilvorrichtung 18 programmierten, Adress- oder Gruppencode zugeordnet ist, und der neue Schlüssel 268 wird in die Schlüsseltabelle 224 programmiert. Kurz gesagt führt die Mobilvorrichtung im Wesentlichen die gleichen Schritte durch wie in den 8A und 8B. Wenn das Gerät den alten Schlüssel nicht aufweist, kann es diese Schritte nicht erfolgreich durchführen und kann folglich die Nachricht nicht erfolgreich decodieren. Daher ist es nur einem autorisierten Gerät möglich, die Programmiernachricht erfolgreich zu decodieren und zu verwenden.
  • ERZEUGUNG DES CODIERTEN INHALTS
  • Sobald die Mobilvorrichtung 18 mit dem neuen Adress- oder Gruppencode und einem oder mehreren entsprechenden Codierungsschlüsseln programmiert wurde, kann der Inhaltsprovider 12 eine codierte Inhaltsnachricht erzeugen, die durch den kabellosen Träger 14 an die Mobilvorrichtung 18 übertragen wird. Die 9A–9C erörtern eine erläuternde Ausführungsform, in der der Inhaltsprovider 12 eine codierte Inhaltsnachricht zur Übertragung über den kabellosen Träger auf die Mobilvorrichtung 18 erzeugt.
  • Der Inhaltsprovider 12 erhält zuerst den gegenwärtigen Sendeschlüssel 268, der zu diesem Zeitpunkt auf der Mobilvorrichtung 18 gespeichert ist und der dem Adress- oder Gruppencode entspricht, über den die codierte Inhaltsnachricht gesendet werden soll. Dieser Schlüssel ist nur in den autorisierten Mobilvorrichtungen gespeichert, wofür die Methode verwendet wurde, die oben mit Bezug auf die 8A, 8B und 8C beschrieben wurde. Der Inhaltsprovider 12 enthält ebenfalls nachrichtenspezifische Daten 294, die vorzugsweise ein Teil der übertragenen Inhaltsnachricht sind und die Eigenschaft aufweisen, dass sie sich mit jeder Nachricht ändern (um abzusichern, dass der unten beschriebene nachrichtenspezifische Codierungsschlüssel 296 für jede Nachricht anders ist, wodurch die Möglichkeit eines böswilligen Angriffs verringert wird). Der Sendeschlüssel 268 und die nachrichtenspezifischen Daten 294 werden der HMAC-Komponente 262 zur Verfügung gestellt, die einen Hash-Wert berechnet, der zum Berechnen eines nachrichtenspezifischen Codierungsschlüssels 296 verwendet wird. Die HMAC-Komponente 262 und die Schlüsselberech nungskomponente 264 können die gleichen Methoden anwenden, die oben mit Bezug auf 8A beschrieben wurden.
  • 9B erläutert, dass die bestimmte gesendete Inhaltsnachricht 298 durch die Codierungskomponente 270 mit dem nachrichtenspezifischen Codierungsschlüssel 296 codiert wird. Die Codierungskomponente 270 kann ebenfalls den gleichen Codierungsalgorithmus oder die Codierungsmethoden anwenden, die oben mit Bezug auf 8B beschrieben wurden. Die Codierungskomponente 270 stellt in ihrer Ausgabe die codierte Inhaltsnachricht 300 zur Verfügung. Die nachrichtenspezifischen Daten 298 werden dann der codierten Inhaltsnachricht 300 in nicht codierter Form angehängt. Ein geeigneter Header 302 wird hinzugefügt, um die gesamte Inhaltsnachricht 304 zu bilden, die an die Mobilvorrichtung 18 gesendet werden soll.
  • 9C ist ein Flussdiagramm, das die Erzeugung der Inhaltsnachricht 304 erläutert. Zuerst werden die nachrichtenspezifischen Daten 294 und der Sendeschlüssel 304 erhalten und der Hash-Wert berechnet. Dies ist durch die Blöcke 306, 308 und 310 dargestellt. Danach wird der nachrichtenspezifische Codierungsschlüssel berechnet und die Inhaltsnachricht wird unter Verwendung des nachrichtenspezifischen Codierungsschlüssels codiert. Dies ist durch die Blöcke 312 und 314 dargestellt. Die nachrichtenspezifischen Daten sowie der Header werden dann der codierten Inhaltsnachricht hinzugefügt. Dies ist durch die Blöcke 316 und 318 dargestellt.
  • Es ist zu beachten, dass in der obigen Beschreibung der Sendeschlüssel oder der nachrichtenspezifische Codierungsschlüssel nicht mit der codierten Inhaltsnachricht zusammen gesendet werden müssen. Es werden nur nachrichtenspezifische Daten gesendet, die für die Berechnung des Codierungsschlüssels verwendet werden, die sich mit jeder Nachricht ändern. Zur erfolgreichen Decodierung der codierten Nachricht muss der Empfänger die fehlenden Informationen haben, nämlich den Sendeschlüssel, den HMAC Algorithmus und die Kenntnis, wie man den Header der Nachricht auswertet, der bestimmt, welcher Teil codiert ist und bei welchem Teil es sich um die MSD 294 handelt. Dies wird der Integrität des Übertragungssystems hinzugefügt.
  • DECODIERUNG DER CODIERTEN INHALTSNACHRICHT
  • 10A und 10B sind Flussdiagramme, die in Verbindung mit 6 besprochen werden, und die die Decodierung einer Inhaltsnachricht erläutern, sobald diese von der Mobilvorrichtung 18 empfangen wurde. Zuerst wird die Nachricht von der Steuerschaltung 218 und der Radio HW 208 empfangen.
  • Die Steuerschaltung 218 enthält vorzugsweise einen Mikroprozessor oder einen Microcontroller, sowie die Antenne und die eigentliche Funkempfänger-Hardware auf der Mobilvorrichtung 18. Außerdem enthält die Steuerschaltung 218 vorzugsweise zugehörige Taktstromkreise und einen Speicher, sowie geeignete Eingabe- und Ausgabepuffer.
  • Die Steuerschaltung 218 ist so konfiguriert, dass sie die Nachricht gemäß den jeweiligen Übertragungsbedingungen empfängt, die dem Kanal durch den kabellosen Träger 14 auferlegt sind. Wenn die Nachricht beispielsweise paketiert ist, und die Pakete willkürlich gesendet werden, empfängt die Steuerschaltung 218 (oder die Steuerschaltung 218 in Verbindung mit dem Treiber 210) die Pakete und ordnet sie, um eine verständliche Nachricht zu bilden. Ausserdem verwendet die Steuerschaltung 218 vorzugsweise eine Logik, die feststellt, ob ein ganzes Paket oder ein Teil-Paket empfangen wurde. Der Empfang der Nachricht ist durch den Block 320 in 10A dargestellt.
  • Sobald die Nachricht empfangen wurde, greift die Radio HW 208 auf Informationen in der Adressinformationstabelle 220 zu, um festzustellen, ob die Adresse, über die die Nachricht geschickt wurde, einer Adresse entspricht, die gegenwärtig in die Radio HW 208 programmiert wurde. Die Steuerschaltung 218 filtert Nachrichten darauf basierend, ob sie über eine Adresse empfangen wurden, die freigegeben und gegenwärtig nicht abgelaufen ist. Dies ist durch den Block 322 dargestellt.
  • Wenn die Nachricht einer Adresse auf der Radio HW 208 entspricht, wird die Nachricht für den Empfang durch den Treiber 210 in die Ausgabepuffer der Steuerschaltung 208 gegeben. Der Treiber 210 empfängt die Nachricht und ruft die AnalyzeMessage-Funktion 230 auf, die in seiner Funktionsbibliothek vorhanden ist. Die AnalyzeMessage-Funktion 230 analysiert die Nachricht, um festzustellen, ob sie einen zugewiesenen Gruppencode aufweist. "Wiederaufruf des Nachrichteninhalts" kann über eine Adresse oder einen Gruppencode oder über beide gesendet werden. Dies ist durch den Block 324 dargestellt.
  • Wenn es eine Gruppencodeinformation gibt, muss der Treiber 210 weiter verarbeiten, um festzustellen, ob die Radio HW 208 mit dem passenden Gruppencode programmiert wurde. Für diesen Zweck verwendet der Treiber 210 die Gruppentabelle. (Wenn die Gruppentabelle in der Radio HW 208 gespeichert ist, bekommt der Gerätetreiber 210 durch hardwarespezifische Mechanismen, wie direktes Lesen des Radio HW Speichers usw., Zugriff auf diese). Basierend auf dem Inhalt der Gruppentabelle kann der Treiber 210 eine weitere Filterung der Nachricht vornehmen, um festzustellen, ob sie gelöscht werden sollte. Dies ist durch den Block 326 dargestellt.
  • Wenn die Nachricht nicht ausgefiltert wurde, leitet der Treiber 210 die Nachricht an den Router 212 weiter. Dies ist durch den Block 328 dargestellt.
  • Basierend auf den Header Informationen in der Nachricht, stellt der Router 212 fest, dass es sich bei der Nachricht um eine codierte Inhaltsnachricht handelt, die zur weiteren Verwendung auf der Mobilvorrichtung 18 decodiert werden muss. Der Router 212 macht daher einen API-Aufruf an den Treiber 210, damit der Treiber 210 den nachrichtenspezifischen Codierungsschlüssel berechnen kann, der zur Decodierung der Nachricht verwendet wird. Dadurch macht der Router 212 (oder eine andere Anwendung) einen Treiber-E/A-Steuerungsaufruf, um eine Kennung zu dem Codierungsschlüssel zu erhalten. Der Aufruf beinhaltet die nachrichtenspezifischen Daten, die der Nachricht in nicht codierter Form angehängt wurden, und die Adresse und Gruppe, über die die Nachricht empfangen wurde. Dies ist durch den Block 330 dargestellt. Basierend auf der Adress- und Gruppeninformation, die als Teil des E/A-Steuerungsaufrufs weitergegeben wurde, erhält der Treiber 210 den Codierungsschlüssel aus der Schlüsseltabelle. Dies ist durch den Block 332 dargestellt. Der Treiber 210 ruft dann die DeriveEncryptionKey-Funktion 232 aus seiner Funktionsbibliothek auf. Dies ist durch den Block 334 dargestellt. Die DeriveEncryptionKey-Funktion 232 verwendet diesen oder diese Schlüssel, der oder die dem Adress- oder Gruppencode zugeordnet ist oder sind, über die die Nachricht übertragen wurde, zusammen mit den nachrichtenspezifischen Daten, die in nicht codierter Form an die Nachricht angehängt wurden, um den nachrichtenspezifischen Schlüssel 296 erneut zu berechnen. Es sollte erwähnt werden, dass die Schlüsseltabelle sicher gespeichert ist und nur der Gerätetreiber 210 darauf Zugriff hat, und daher nur der Gerätetreiber 210 den richtigen DeriveEncryption-Key() API-Aufruf machen kann.
  • Die erneute Berechnung des Schlüssels 296 kann erfolgen, indem man einfach nur den Hash-Algorithmus wiederholt, der von der HMAC-Komponente 262 ausgeführt wurde und den Schlüsselberechnungsalgorithmus, der vom Schlüsselberechnungsgenerator 264 bei der Erzeugung des nachrichtenspezifischen Schlüssels angewandt wurde.
  • Die Bibliotheksfunktion berechnet daher den nachrichtenspezifischen Schlüssel 296, der zur Codierung der Inhaltsnachricht verwendet wurde, und der den nachrichtenspezifischen Schlüssel 296 in dem nachrichtenspezifischen Schlüsselspeicher 228 speichert. Die Funktion gibt auch eine Kennung hKey an den Treiber 210 zurück (welcher diesen wiederum an den Router 212 weitergibt), die eine Speicherstelle im nachrichtenspezifischen Speicher 228 angibt, an der der nachrichtenspezifische Schlüssel gespeichert ist. Dies ist durch den Block 336 dargestellt.
  • Als Reaktion darauf, macht der Router 212 einen API-Aufruf an die CAPI-Komponente 236 in der Sicherheitskomponente 226, und stellt dadurch den hKey und die codierte Inhaltsnachricht zur Verfügung. Die CAPI-Komponente 236 lädt den im Speicher 228 gespeicherten nachrichtenspezifischen Schlüssel zurück und stellt den nachrichtenspezifischen Schlüssel zusammen mit der codierten Inhaltsnachricht dem kryptographischen Serviceprovider 238 zur Verfügung. Dies ist durch die Blöcke 338 und 340 dargestellt.
  • Der kryptographische Serviceprovider 238 decodiert die Inhaltsnachricht und gibt sie in nicht codierter Form an die CAPI-Komponente 236, die die decodierte Nachricht wiederum zurück an den Router 212 gibt. Dies ist durch die Blöcke 342 und 344 dargestellt. Der Router 212 leitet die Nachricht dann an die zusätzlichen Übersetzer 214 weiter, wenn dies notwendig ist. Solche Übersetzer können aufgerufen werden, um die Nachricht zu dekomprimieren, wenn diese komprimiert wurde, um die Nachricht zu decodieren, wenn diese codiert wurde, usw. Die Nachricht wird dann an ihr Ziel 216 gegeben, wobei es sich um ein Anwendungsprogramm zum Anzeigen der Inhaltsnachricht auf dem Bildschirm der Mobilvorrichtung 18 oder ein anderes gewünschtes Ziel handeln kann. Dies ist durch den Block 346 dargestellt.
  • Es ist zu beachten, dass die obige Beschreibung weiter erläutert hat, dass der Router 212 die Komponente ist, die den Decodierungsvorgang hauptsächlich steuert. Dies könnte jedoch auch von jeder anderen Anwendung vorgenommen werden. In einer bevorzugten Ausführungsform wird dieser Vorgang beispielsweise von einem seperaten Decodierungsübersetzer durchgeführt.
  • Daher kann man erkennen, dass die oben beschriebene Ausführungsform der vorliegenden Erfindung ein System bietet, in dem der Inhaltsprovider 12 und der kabellose Träger 14 die Mobilvorrich tung 18 über eine geeignete Übertragungsleitung (wie z.B. kabellos) auf sichere Art mit Abonnementinformationen programmieren können. Dadurch empfangen nur die Benutzer der Mobilvorrichtung 18, die ein Abonnement haben, die betreffenden Dienste. Ein weiterer Aspekt der oben beschriebenen vorliegenden Erfindung bietet ein System, durch das codierte Inhalsnachrichten zur Verwendung auf der Mobilvorrichtung 18 decodiert werden können, ohne dass der zur Codierung der Inhaltsnachrichten verwendete Sendeschlüssel jemals den Treiber 210 verlässt. Die vorliegende Erfindung stattet ausserdem den Inhaltsprovider 12 und den kabellosen Träger 14 mit der Fähigkeit aus, Dienste für einzelne Benutzer der Mobilvorrichtung 18 oder für alle Benutzer gleichzeitig auszuschalten. Ausserdem stattet die vorliegende Erfindung den Inhaltsproviders 12 mit der Fähigkeit aus, den Sendeschlüssel für eine größere Sicherheit zu drehen.
  • DIE ÄUßERE SICHERHEITSKOMPONENTE
  • 11A ist ein Blockdiagramm, das eine zweite Ausführungsform der Mobilvorrichtung 18 gemäß eines anderen Aspekts der vorliegenden Erfindung erläutert. Manche Bestandteile entsprechen denen, die in 6 erläutert sind, und sind entsprechend nummeriert. Manche Bestandteile wurden zudem der Klarheit halber in 11A weggelassen. Die in 11A dargestellten Komponenten der Mobilvorrichtung 18, die zum Verständnis dieses Aspekts der vorliegenden Erfindung notwendig sind, sind jedoch erläutert.
  • 11A erläutert, dass die Mobilvorrichtung 18 eine Radio HW 208, einen Gerätetreiber 348, einen Nachrichten-Router 212, optionale zusätzliche Übersetzer 214, eine äußere Sicherheitskomponente 350, die Nachrichtenkennung 352 und das Ziel 216 aufweist. Die 11B und 11C sind Flussdiagramme, die den Betrieb der Mobilvorrichtung 18 erklären, wenn diese neue Adress- oder Gruppencodeschlüssel empfängt, diese Schlüssel decodiert und diese Schlüssel zur Decodierung der eingehenden Nachrichten verwendet. Die 11B und 11C werden in Verbindung mit 11A beschrieben.
  • 11A erläutert eine Ausführungsform der Schlüsseltabelle 224, die Schlitze, Adressen, Gruppen, zugehörige Schlüssel und Prüfsummen aufweist. Der als Ki gekennzeichnete Schlüssel wird verwendet, um einen einzigartigen Codierungsschlüssel zu bestimmen, der der Mobilvorrichtung 18 gegenüber einzigartig ist und der vom einem geheimen Wert abgeleitet wird, der der Mobilvorrichtung 18 und dem kabellosen Träger 14 (z.B. die EID) gegenüber geheim ist. Die Gruppenschlüssel werden als Kg und Kh gekennzeichnet, und die Prüfsummen werden als CS gekennzeichnet.
  • Ki wird von dem Kartenhersteller festgelegt und ist in der Schlüsseltabelle 224 in der Radio HW 208 permanent gespeichert. Die Schlüssel Kg und Kh können drahtlos, oder über das Internet oder über jede andere geeignete Übertragungsleitung in die Schlüsseltabelle 224 programmiert werden.
  • Der Ausdruck SetKey stellt eine freigelegte API vom Gerätetreiber 348 dar, die es einer Anwendung erlaubt, codierte Schlüssel in der Schlüsseltabelle 224 der Radio HW 208 festzulegen. Die SetKey-API läuft auf einer gegebenen Adress- und Gruppennummer, um Gruppenschlüssel und Prüfsummen in die Schlüsseltabelle 224 zu geben. Die Gruppenschlüssel werden dem Gerätetreiber 348 immer in codierter Form mit Ki bereitgestellt (wobei die Bezeichnung Ki (kg) verwendet wird, um den Schlüssel Kg darzustellen, der unter Verwendung von Ki codiert wurde), so dass ein gültiger Gruppenschlüssel nicht erzeugt werden kann, wenn der vertrauliche Ki nicht ebenfalls bekannt ist (der nur dem Träger und dem Hersteller bekannt ist).
  • Die Prüfsummen CS werden dem Gerätetreiber 348 ebenfalls in codierter Form übergeben, mit Ki (d.h., Ki (CS)) codiert. Um einen Schlüssel in die Schlüsseltabelle 224 zu geben, ruft jeder Aufrufer einfach nur die SetKey-API auf, die Ki (Kg) und Ki (CS) bereitstellt. Der Gerätetreiber 348 macht wiederum einen E/A-Steuerungsaufruf an die Radio HW 208, um den codierten Gruppenschlüssel und die Prüfsumme (Ki (Kg) und Ki (CS)) in die Schlüsseltabelle 224 zu geben. Das ist durch die Blöcke 354 und 356 in 11B dargestellt.
  • Wenn eine neu codierte Inhaltsnachricht für eine spezifische Gruppe auf einem spezifischem Schlitz bei der Radio HW 208 ankommt, macht der Gerätetreiber 348 einen E/A-Steuerungsaufruf an die Radio HW 208, um die Nachricht von der Radio HW 208 abzurufen. Dies ist durch die Blöcke 358 und 360 dargestellt. Der Gerätetreiber 348 gibt die Nachricht wiederum an den Nachrichten-Router 212 weiter. Der Nachrichten-Router 212 leitet die codierte Nachricht an die äußere Sicherheitskomponente 350 weiter, die sich außerhalb des Gerätetreibers 348 befindet. Dies wird vom Nachrichten-Router 212 basierend auf den weitergeleiteten Headern der Nachrichten festgestellt. Dies ist durch die Blöcke 362 und 364 dargestellt.
  • Die Sicherheitskomponente 350 macht einen API-Aufruf (hierbei als GetKey bezeichnet) an den Gerätetreiber 348, um den Schlüssel für die Schlitznummer und die Gruppennummer zu erhalten, über die die Nachricht empfangen wurde. Dies ist durch den Block 366 dargestellt.
  • Wenn dies das erste Mal ist, dass der Gerätetreiber 348 einen API-Aufruf von dieser bestimmten äußeren Sicherheitskomponente 350 empfangen hat, überprüft der Treiber 348, dass es sich um die richtige Komponente handelt, die die Schlüsselinformation erhalten sollte. Die Ermittlung, ob es sich hierbei um den ersten API-Aufruf der Sicherheitskomponente handelt, ist durch den Block 368 dargestellt.
  • Um zu überprüfen, ob es sich bei der Sicherheitskomponente um die richtige Komponente handelt, decodiert der Gerätetreiber 348 Ki (CS) und vergleicht die decodierte Prüfsumme mit einer tatsächlichen Prüfsumme, die auf der DLL-Datei der Sicherheitskom ponente 250 berechnet wurde. Dies ist durch die Blöcke 370 und 372 dargestellt.
  • Bei der Prüfsumme der Sicherheitskomponente 350 handelt es sich vorzugsweise um einen bekannten Wert, der auf einem eng gehaltenen Algorithmus basiert. Es ist zu beachten, dass die Prüfsumme, wie die Gruppenschlüssel, dem Gerätetreiber 348 immer schon von Ki codiert bereitgestellt werden. Sogar wenn der Wert der Prüfsumme bekannt ist, ist es dem Gerätetreiber 348 daher nicht möglich, diese Prüfsumme zu verwenden, da der Gerätetreiber 348 diese nur verwenden wird, wenn sie von Ki codiert ist. Es ist ebenfalls zu beachten, dass, falls einem böswilligen Benutzer Kg bekannt ist, dieser Benutzer versuchen könnte, die Sicherheitskomponente 350 so zu verändern, dass Kg immer verwendet wird. Eine Veränderung der Sicherheitskomponenten-DLL würde jedoch von der Prüfsumme erkannt werden und wäre daher nicht erfolgreich.
  • Wenn die decodierte Prüfsumme nicht mit der Prüfsumme der DLL der Sicherheitskomponente übereinstimmt, wird der Schlüssel der Sicherheitskomponente 350 nicht bereitgestellt werden. Dies ist durch die Blöcke 374 und 376 dargestellt.
  • Wenn die Prüfsummen jedoch übereinstimmen, ist es wünschenswert, die DLL der Sicherheitskomponente aufrecht zu erhalten, um zu verhindern, dass sie sich bei aufeinander folgenden Aufrufen verändert. Mit anderen Worten, wenn der Gerätetreiber 348 weiß, dass sich die Prüfsumme der DLL in der Sicherheitskomponente 350 seit dem letzten Aufruf nicht verändert hat, muss mit jedem aufeinanderfolgenden Aufruf keine neue Prüfsumme für die DLL berechnet werden, Es gibt eine Vielzahl an Möglichkeiten, wie der Gerätetreiber 348 die DLL offen halten kann. Sobald die DLL von der Sicherheitskomponente durch den Gerätetreiber 348 geladen wurde, kann der Gerätetreiber 348 einfach davon absehen, die DLL zu entladen. Die DLL bleibt also offen und kann daher nicht verändert werden. Daher kann angenommen werden, dass der ursprüngliche Prüfsummennachweis gültig ist, ohne dass man den tatsächlichen Vergleich für jede erhaltene codierte Nachricht vornimmt.
  • Alternativ kann der Gerätetreiber 348 "offen" ausführen, um auf der DLL zu schreiben und die DLL einfach offen zu halten. Auf diese Weise erlaubt das System keine Veränderungen bei der DLL, solange sie offen ist. Die DLL ist dann zur späteren Verwendung vertrauenswürdig. Das Offenhalten der DLL ist durch den Block 378 dargestellt.
  • Nachdem die DLL der Sicherheitskomponente offen gehalten wurde, kann der Gerätetreiber 348 den Gruppenschlüssel an die Sicherheitkomponente 350 zurückgeben. In einer bevorzugten Ausführungsform wird der Gruppenschlüssel jedoch in codierter Form zurückgegeben, mit der Prüfsumme CS codiert, so dass immer noch nicht auf den Schlüssel zugegriffen werden kann. Die Prüfsumme CS wird vorzugsweise zur Codierung des Gruppenschlüssels verwendet, da die Sicherheitskomponente diese, basierend auf ihrer eigenen DLL, berechnen kann. Alternativ kann die decodierte Prüfsumme CS in den sicheren Speicher auf der Radio HW 208 gegeben werden. Die Rückgabe des Gruppenschlüssels CS (Kg) ist durch den Block 380 dargestellt.
  • Nach Empfang des codierten Gruppenschlüssels, führt die Sicherheitskomponente 350 eine Prüfsumme auf seiner eigenen DLL durch und verwendet diese Prüfsumme zur Decodierung von CS (Kg), um den Gruppenschlüssel Kg zu erhalten. Dies ist durch die Blöcke 382 und 384 dargestellt.
  • Die Sicherheitskomponente 350 verwendet dann den decodierten Gruppenschlüssel Kg, um die codierte Inhaltsnachricht zu decodieren, und gibt die decodierte Nachricht an den Router 212 zurück. Der Router 212 leitet die Nachricht wahlweise an andere Übersetzer weiter, wenn dies notwendig ist, und dann an die Nachrichtenkennung 352. Die Nachrichtenkennung 352 liefert die decodierte Nachricht dann an ihr Ziel. Dies ist durch die Blöcke 386, 388 und 390 dargestellt.
  • Daher kann man erkennen, dass diese Ausführungsform der vorliegenden Erfindung eine äußere Sicherheitskomponente 350 verwendet, so dass die Sicherheitskomponente sich nicht im Inneren des Gerätetreibers 348 befinden muss. Der Gerätetreiber 348 codiert jedoch all die Schlüssel, die auf der Radio HW 208 gespeichert sind, unter Verwendung der geheimen EID und er schickt den Decodierungsschlüssel nur ausserhalb seines Codes, nachdem der gespeicherte Schlüssel selbst decodiert wurde. Sogar noch bevor der Schlüssel ausserhalb seines Codes verschickt wird, wird der Schlüssel unter Verwendung eines Schlüssels erneut codiert, der spezifisch für die bekannte Sicherheitskomponente ist. Die Sicherheitskomponente wendet einen Schlüssel an, den sie selbst aus dem Schlüssel berechnet, der ihr von dem Gerätetreiber 348 gegeben wurde, um den decodierten Gruppenschlüssel zur Decodierung des Inhalts zu erhalten. Außerdem führt der Gerätetreiber 348 eine Prüfsumme in der Sicherheitskomponente 350 durch, bevor er den codierten Gruppenschlüssel an die Sicherheitskomponente weitergibt. Die tatsächliche Prüfsumme, die für die Sicherheitskomponente berechnet wurde, wird mit einer codierten Prüfsumme (mit der EID codiert) verglichen, die auf der Radio HW 208 gespeichert ist. Zur optimierten Leistung muss die Prüfsumme desweiteren auf der Sicherheitskomponente nur berechnet werden, wenn die Sicherheitskomponente den Gerätetreiber 348 das erste Mal aufruft. Daher hält der Treiber 348 die DLL der Sicherheitskomponente offen, damit diese nicht verändert werden kann.
  • Obwohl die vorliegende Erfindung mit Bezug auf die bevorzugten Ausführungsformen beschrieben wurde, werden Fachleute erkennen, dass Änderungen in der Ausgestaltung und im Detail vorgenommen werden können, ohne sich aus dem Bereich der Erfindung zu entfernen.

Claims (37)

  1. Verfahren zum Steuern eines Zugriffs auf von einer Vielzahl von Mobilvorrichtungen (18) empfangenen Sendenachrichten, wobei das Verfahren folgende Schritte aufweist: Bereitstellung eines Sendecodierschlüssels BEK (= broadcast encryption key) mit einem Gruppencode, für aus der Vielzahl von Mobilvorrichtungen (18) ausgewählte Mobilvorrichtungen (18); Codierung der Sendenachrichten vor dem Senden der Sendenachrichten unter Verwendung des Sendecodierschlüssels BEK, so dass die ausgewählten, mit den dem Sendecodierschlüssel BEK aufweisenden ausgestatteten Mobilvorrichtungen zum Decodieren der codierten Sendenachrichten konfigurierbar sind; dadurch gekennzeichnet, dass der Codierschritt weiter folgende Unterschritte aufweist: Erhalt eines nachrichtenspezifischen Sendeschlüssels MSBK (= message specific broadcast key) (296), der auf dem Sendecodierschlüssel BEK und auf nachrichtenspezifischen Daten (298), die spezifisch für die Sendenachricht sind, basiert; Codierung der Sendenachricht mit dem nachrichtenspezifischen Sendeschlüssel MSBK zum Erhalt einer codierten Sendenachricht; Hinzufügen der nachrichtenspezifischen Daten (298) zur codierten Sendenachricht in uncodierter Form; Hinzufügen eines Nachrichtenkopfs (302) zur codierten Sendenachricht; und Senden der codierten Sendenachrichten (300) über eine Adresse und den dem Sendecodierschlüssel BEK zugehörigen Gruppencode an die Mobilvorrichtung (18); Bereitstellung des Gruppencodes für die ausgewählten Mobilvorrichtungen; Empfang der codierten Sendenachricht auf den ausgewählten Mobilvorrichtungen (18); und Decodierung der codierten Sendenachrichten an den ausgewählten Mobilvorrichtungen (18) unter Verwendung des Sendecodierschlüssels BEK.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die ausgewählten Mobilvorrichtungen (18) jeweils einen Funkempfänger (208) und ein Treiberbauteil (210) aufweisen und das Verfahren weiter folgende Schritte aufweist: Empfang des Sendecodierschlüssels BEK und des Gruppencodes auf den ausgewählten Mobilvorrichtungen (18); und Aufrechterhaltung einer Schlüsseldatenstruktur im Funkempfänger (208) in den ausgewählten Mobilvorrichtungen (18), in welcher der Sendecodierschlüssel BEK dem Gruppencode zugeordnet ist.
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der Aufrechterhaltungsschritt [der Schlüsseldatenstruktur] weiter folgenden Unterschritt aufweist: Aufrechterhaltung der Schlüsseldatenstruktur derart, dass der Sendecodierschlüssel BEK mit der Adresse in Zusammenhang steht.
  4. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Mobilvorrichtung (18) so konfiguriert ist, dass sie Sendenachrichten über eine Vielzahl von Adressen und Gruppencodes empfängt, und dass der Aufrechterhaltungsschritt weiter folgenden Unterschritt aufweist: Aufrechterhaltung der Schlüsseldatenstruktur, in der eine Vielzahl von Sendecodierschlüsseln BEK mit einer Vielzahl von Adressen und Gruppencodes in Zusammenhang steht.
  5. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass das Treiberbauteil (210) ein Kryptographiebauteil (200) aufweist, wobei die ausgewählten Mobilvorrichtungen (18) jeweils einen zum Treiberbauteil (210) extern angeordneten Nachrichten-Router (212) aufweisen und wobei die Decodierung der codierten Sendenachricht folgende Schritte aufweist: Weiterleiten der nachrichtenspezifischen Daten vom Nachrichten-Router (212) an das Treiberbauteil (210); Weiterleiten der Schlüsselinformationen von der Schlüsseldatenstruktur am Funkempfänger (208) an das Treiberbauteil (210); und Ableitung eines auf den nachrichtenspezifischen Daten und der Schlüsselinformation basierenden nachrichtenspezifischen Sendeschlüssels MSBK an dem Treiberbauteil (210).
  6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die Decodierung der codierten Sendenachricht weiter folgende Schritte aufweist: Speichern des im Treiber (210) abgeleiteten nachrichtenspezifischen Sendeschlüssels MSBK in einem Speicher (228) an einer Speicherstelle, der durch eine Kennung identifiziert wird; und Rücksendung der Kennung an den Nachrichten-Router (212).
  7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass die Decodierung der codierten Sendenachricht weiter folgende Schritte aufweist: Weiterleitung der codierten Sendenachricht und der Kennung vom Nachrichten-Router (212) zum Kryptographiebauteil (200) in dem Treiberbauteil (210); Abrufen des abgeleiteten nachrichtenspezifischen Sendeschlüssels MSBK aus dem vom Speicherbereich am Kryptographiebauteil (200) basierend auf der Kennung; Decodierung der codierten Sendenachricht in dem Kryptographiebauteil (200) unter Verwendung des abgeleiteten nachrichtenspezifischen Sendeschlüssels MSBK; und Rücksendung der decodierten Sendenachricht an den Nachrichten-Router (212).
  8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass der Funkempfänger (208) Adressinformationen beibehält, welche die Adressen anzeigen, über welche die Sendenachrichten von den ausgewählten Mobilvorrichtungen (18) empfangen werden können, und dass der Empfang der Sendenachrichten folgenden Schritt aufweist: Filtern der Sendenachrichten am Funkempfänger (208) basierend auf den Adressinformationen.
  9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass der Funkempfänger (208) Gruppencodeinformationen beibehält, welche Gruppencodes anzeigen, über welche Sendenachrichten von der ausgewählten Mobilvorrichtung (18) empfangen werden können, und dass der Empfang von Sendenachrichten folgende Schritte aufweist: Bestimmung, ob die Sendenachricht einen Gruppencode einschließt; falls ja, Weiterleitung der Gruppencodeinformationen vom Funkempfänger (208) an das Treiberbauteil (210); und Filtern von Sendenachrichten in dem Treiberbauteil (210) basierend auf dem in der Sendenachricht enthaltenen Gruppencode und den vom Funkempfänger (208) weitergeleiteten Gruppencodeinformationen.
  10. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass jede Mobilvorrichtung (18) die Sendenachrichten von einem Nachrichtensender über eine Adresse und einen Gruppencode empfängt, und dass jede der Mobilvorrichtungen (18) einen Funkempfänger (208), ein mit dem Funkempfänger (208) verbundenes Treiberbauteil (210), ein extern an dem Treiberbauteil (210) angebrachtes und mit dem Treiberbauteil (210) verbundenes Sicherheitsbauteil (226) und einen mit dem Sicherheitsbauteil (226) und dem Treiberbauteil (210) verbundenen Nachrichten-Router (212) aufweist, wobei die Bereitstellung eines Sendecodierschlüssels BEK für die ausgewählten Mobilvorrichtungen (18) den Schritt der Bereitstellung eines codierten Sendecodierschlüssels, der den dem Gruppencode zugehörigen Sendecodierschlüssel enthält, in codierter Form für das Treiberbauteil (210) aufweist, wobei der Sendecodierschlüssel mit einem der Mobilvorrichtung (18) und dem Nachrichtensender vertraulichen Basisschlüssel codiert ist; und Weiterleiten des codierten Sendecodierschlüssels BEK an den Funkempfänger (208) zum dortigen Speichern.
  11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass die Bereitstellung eines Sendecodierschlüssels BEK für die ausgewählten Mobilvorrichtungen (18) folgende Schritte aufweist: Bereitstellung einer codierten Prüfsumme für das Treiberbauteil (210), wobei die Prüfsumme eine dem Gruppencode zugehörige Prüfsumme des Sicherheitsbauteils (226) in codierter Form aufweist, die mit dem Basisschlüssel codiert ist; und Weiterleiten der codierten Prüfsumme an den Funkempfänger (208) zum dortigen Speichern.
  12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass die Decodierung der codierten Sendenachricht folgende Schritte aufweist: Weiterleiten der codierten Nachricht an das Sicherheitsbauteil (226); Anfordern des Sendecodierschlüssels BEK von dem Treiberbauteil (210) durch das Sicherheitsbauteil (226); Verifizieren der Gültigkeit des Sicherheitsbauteils (226) am Treiberbauteil (210); und Rücksenden des mit der Prüfsumme codierten Sendecodierschlüssels BEK an das Sicherheitsbauteil (226).
  13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass die Decodierung der codierten Sendenachricht folgende Schritte aufweist: Berechnung einer Prüfsumme in dem Sicherheitsbauteil (226); Decodierung des von dem Treiberbauteil (210) empfangenen Sendecodierschlüssels BEK in dem Sicherheitsbauteil (226) unter Verwendung der von dem Sicherheitsbauteil (226) berechneten Prüfsumme; und Decodierung der codierten Sendenachricht unter Verwendung des Sendecodierungschlüssels BEK.
  14. Verfahren nach Anspruch 13, das weiter folgenden Schritt aufweist: Zurückleiten der decodierten Sendenachricht an den Nachrichten-Router (212).
  15. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass die Verifizierung der Gültigkeit des Sicherheitsbauteils (226) folgende Schritte aufweist: Bestimmung, ob das Sicherheitsbauteil (226) zuvor den Sendecodierschlüssel BEK angefordert hat; falls nicht, Decodierung der codierten Prüfsumme in dem Treiberbauteil (210), um eine decodierte Prüfsumme zu erhalten; Berechnung einer Prüfsumme des Sicherheitsbauteils (226) in dem Treiberbauteil (210), um eine berechnete Prüfsumme zu erhalten; und Vergleich der decodierten Prüfsumme mit der berechneten Prüfsumme.
  16. Verfahren nach Anspruch 15, das weiter folgenden Schritt aufweist: Zurückhalten des Sicherheitsbauteils (226), falls die decodierte Prüfsumme identisch mit der berechneten Prüfsumme ist, um zu vermeiden, dass das Sicherheitsbauteil (226) Prüfsummenwerte verändert.
  17. Verfahren nach Anspruch 1, das weiter folgenden Schritt aufweist: Periodisches Verändern des Sendecodierschlüssels BEK an den ausgewählten Mobilvorrichtungen (18).
  18. Verfahren nach Anspruch 17, dadurch gekennzeichnet, dass das periodische Verändern des Sendecodierschlüssels BEK folgende Schritte aufweist: Erstellung eines auf dem Sendecodierschlüssel BEK und nachrichtenspezifischen Daten basierenden Programmierschlüssels; Codierung eines neuen Sendecodierschlüssels BEK mit dem Programmierschlüssel, um einen codierten neuen Sendecodierschlüssel BEK zu erhalten; Hinzufügen der nachrichtenspezifischen Daten zum codierten neuen Sendecodierschlüssel BEK, um eine neue Sendecodierschlüssel-Nachricht zu bilden; und Senden der neuen Sendecodierschlüssel-Nachricht an die ausgewählten Mobilvorrichtungen (18).
  19. Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass das periodische Verändern des Sendecodierschlüssels BEK folgende Schritte aufweist: Empfang der neuen Sendecodierschlüssel-Nachricht BEK; Erhalt des auf den nachrichtenspezifischen Daten und dem in den Mobilvorrichtungen (18) gespeicherten Sendecodierschlüssel basierenden Programmierschlüssels; Decodierung des codierten neuen Sendecodierschlüssels BEK unter Verwendung des Programmierschlüssels; und Speichern des neuen Sendecodierschlüssels BEK in der Mobilvorrichtung (18).
  20. System zum Steuern eines Zugriffs auf eine Sendenachricht, die über eine Adresse und einen Gruppencode gesendet wird und von einer Vielzahl von Mobilvorrichtungen (18) empfangen wird, wobei das System Folgendes aufweist: eine Nachrichtenquelle, die ein Codierbauteil aufweist, das so konfiguriert ist, dass es die Sendenachricht codiert, um eine codierte Nachricht zu bilden, sowie ein Übertragungsbauteil aufweist, das so konfiguriert ist, dass es die codierte Nachricht und einen Codierschlüssel an ausgewählte Mobilvorrichtungen aus einer Vielzahl von Mobilvorrichtungen (18) sendet; wobei jede der ausgewählten Mobilvorrichtungen (18) einen Nachrichtenempfänger, der ein Funkempfänger (208) -Bauteil aufweist, das so konfiguriert ist, dass es die codierte Nachricht empfängt, einen Codierschlüsselspeicher, der so konfiguriert ist, dass er den Codierschlüssel empfängt, und ein Decodierbauteil aufweist, das so konfiguriert ist, dass es die codierte Nachricht decodiert; dadurch gekennzeichnet, dass das Codierbauteil einen nachrichtenspezifischen Schlüsselgenerator aufweist, der so konfiguriert ist, dass er einen auf dem Codierschlüssel und auf für die Sendenachricht spezifischen nachrichtenspezifischen Daten basierenden nachrichtenspezifischen Schlüssel erzeugt, und dass er die Sendenachricht mit dem nachrichtenspezifischen Schlüssel codiert.
  21. System nach Anspruch 20, dadurch gekennzeichnet, dass der Sender so konfiguriert ist, dass er nachrichtenspezifische Daten zusammen mit der codierten Nachricht sendet, und dass die ausgewählten Mobilvorrichtungen (18) jeweils einen Funkempfänger (208) aufweisen, der den Codierschlüssel speichernden Schlüsselspeicher aufweist, wobei der Funkempfänger (208) so konfiguriert ist, dass er die codierte Nachricht empfängt.
  22. System nach Anspruch 21, dadurch gekennzeichnet, dass die ausgewählten Mobilvorrichtungen (18) jeweils ein Treiberbauteil (210) aufweisen, wobei sich das Decodierbauteil im Inneren des Treiberbauteils (210) befindet und Folgendes aufweist: einen nachrichtenspezifischen Schlüsselgenerator, der so konfiguriert ist, dass er den Codierschlüssel vom Schlüsselspeicher im Funkempfänger (208) und die nachrichtenspezifischen Daten erhält und den nachrichtenspezifischen Schlüssel erzeugt.
  23. System nach Anspruch 22, dadurch gekennzeichnet, dass das Treiberbauteil (210) so konfiguriert ist, dass es den abgeleiteten nachrichtenspezifischen Schlüssel in einer Schlüsselspeicherstelle in dem Treiberbauteil (210) anordnet und eine Kennung erzeugt, die die Schlüsselspeicherstelle angibt.
  24. System nach Anspruch 23, dadurch gekennzeichnet, dass jede der ausgewählten Mobilvorrichtungen (18) einen mit dem Treiberbauteil (210) verbundenen Router (212) aufweist und so konfi guriert ist, dass sie die codierte Nachricht und die Schlüsselkennung empfängt, und dass das Decodierungsbauteil weiter Folgendes aufweist: ein Sicherheitsbauteil (226), das so konfiguriert ist, dass es die Schlüsselkennung vom Router (212) sowie die codierte Nachricht empfängt, und den auf der Schlüsselkennung basierenden nachrichtenspezifischen Schlüssel von der Schlüsselspeicherstelle in dem Treiberbauteil (210) erhält, und die codierte Nachricht mit dem nachrichtenspezifischen Schlüssel decodiert, um eine uncodierte Nachricht zu erhalten.
  25. System nach Anspruch 20, dadurch gekennzeichnet, dass die ausgewählten Mobilvorrichtungen (18) jeweils ein Treiberbauteil (210) aufweisen und die Nachrichtenquelle so konfiguriert ist, dass die ausgewählten Mobilvorrichtungen (18) den Codierschlüssel erhalten, indem folgende Schritte ausgeführt werden: Bereitstellung eines codierten Gruppenschlüssels für das Treiberbauteil (210), wobei der Gruppenschlüssel in codierter Form den dem Gruppencode zugehörigen Decodierschlüssel aufweist, der mit einem der Mobilvorrichtung (18) und dem Nachrichtensender vertraulichem Basisschlüssel codiert ist; und Weiterleiten des codierten Gruppenschlüssels an den Funkempfänger (208) zum Speichern desselben im Schlüsselspeicher.
  26. System nach Anspruch 25, dadurch gekennzeichnet, dass die Nachrichtenquelle so konfiguriert ist, dass sie folgende Schritte ausführt: Bereitstellung einer codierten Prüfsumme für das Treiberbauteil (210), wobei die Prüfsumme mit dem Gruppencode in Zusammenhang stehende Prüfsumme des Sicherheitsbauteils (226) aufweist, wobei die Prüfsumme in codierter Form, mit einem Basiscode codiert, bereitgestellt wird; und Weiterleiten der codierten Prüfsumme an den Funkempfänger (208) zum dortigen Speichern.
  27. System nach Anspruch 26, dadurch gekennzeichnet, dass das Decodierbauteil ein Sicherheitsbauteil (226) aufweist und so konfiguriert ist, dass es die codierte Nachricht an das Sicherheitsbauteil (226) weiterleitet; das Sicherheitsbauteil (226) so konfiguriert ist, dass es den Gruppenschlüssel von dem Treiberbauteil (210) anfordert; das Treiber-Bauteil (210) so konfiguriert ist, dass es die Gültigkeit des Sicherheitsbauteils (226) verifiziert und den mit der Prüfsumme codierten Gruppenschlüssel an das Sicherheitsbauteil (226) zurücksendet.
  28. System nach Anspruch 27, dadurch gekennzeichnet, dass das Sicherheitsbauteil (226) so konfiguriert ist, dass es die codierte Sendenachricht decodiert, indem es folgende Schritte ausführt: Berechnung einer Prüfsumme in dem Sicherheitsbauteil (226); Lieferung des codierten Gruppenschlüssels an das Decodierbauteil; Decodierung des von dem Treiberbauteil (210) erhaltenen Gruppenschlüssels unter Verwendung der von dem Sicherheitsbauteil (226) berechneten Prüfsumme; und Decodierung der codierten Sendenachricht unter Verwendung des Gruppenschlüssels.
  29. System nach Anspruch 28, dadurch gekennzeichnet, dass das Treiberbauteil (210) so konfiguriert ist, dass die Verifizierung der Gültigkeit des Sicherheitsbauteils (226) folgende Schritte umfasst: Bestimmung, ob das Sicherheitsbauteil (226) zuvor den Gruppenschlüssel angefordert hat; falls nicht, Decodierung der codierten Prüfsumme in dem Treiberbauteil (210), um eine decodierte Prüfsumme zu erhalten; Berechnung einer Prüfsumme des Sicherheitsbauteils (226) in dem Treiberbauteil (210), um eine berechnete Prüfsumme zu erhalten; und Vergleich der decodierten Prüfsumme mit der berechneten Prüfsumme.
  30. System nach Anspruch 29, dadurch gekennzeichnet, dass das Treiberbauteil (210) weiter so konfiguriert ist, dass es folgende Schritte ausführt: Zurückhalten des Sicherheitsbauteils (226), falls die decodierte Prüfsumme identisch mit der berechneten Prüfsumme ist, um zu vermeiden, dass das Sicherheitsbauteil (226) die Werte der Prüfsumme verändert.
  31. System nach Anspruch 30, dadurch gekennzeichnet, dass das Sicherheitsbauteil (226) so konfiguriert ist, dass es die uncodierte Nachricht an den Router (212) sendet.
  32. System nach Anspruch 20, dadurch gekennzeichnet, dass die Vielzahl der Mobilvorrichtungen (18) so konfiguriert ist, dass sie Sendenachrichten über einen Gruppencode empfangen, der an den Funkempfänger (208) zum dortigen Speichern übertragbar ist, wobei der Gruppencode einer Adresse zugehörig ist und das Treiberbauteil (210) so konfiguriert ist, dass es die über den Gruppencode empfangenen Sendenachrichten mit dem Codierschlüssel decodiert.
  33. System nach Anspruch 20, dadurch gekennzeichnet, dass die Vielzahl der Mobilvorrichtungen (18) so konfiguriert ist, dass sie Sendenachrichten über einen Gruppencode empfangen, der an den Funkempfänger (208) zum dortigen Speichern übertragbar ist, wobei der Gruppencode einer Adresse zugehörig ist und einen zugehörigen Gruppenschlüssel, der im Schlüsselspeicher im Funkempfängers (208) gespeichert ist, aufweist, wobei das Treiberbauteil (210) so konfiguriert ist, dass es bestimmt, ob der Gruppencode, über den die Sendenachricht empfangen wird, einen zugehörigen Gruppenschlüssel aufweist und die über den Gruppencode gesendete Sendenachricht, mit dem Gruppencodeschlüssel decodiert.
  34. System nach Anspruch 33, dadurch gekennzeichnet, dass der Sender so konfiguriert ist, dass er eine Programmiernachricht zum Programmieren des Gruppencodes und des Gruppenschlüssels an den Funkempfänger (208) sendet, indem er den Gruppencode und den Gruppenschlüssel basierend auf einem geheimen, den ausgewählten Mobilvorrichtungen (18) und dem Sender vertraulichen Schlüssel codiert.
  35. System nach Anspruch 34, dadurch gekennzeichnet, dass die Nachrichtenquelle so konfiguriert ist, dass sie den Gruppenschlüssel ohne Zugriff auf den geheimen Schlüssel ändert.
  36. System nach Anspruch 35, dadurch gekennzeichnet, dass die Nachrichtenquelle so konfiguriert ist, dass sie eine Änderung des Gruppenschlüssels mithilfe folgender Schritte durchführt: Erzeugung eines auf einem aktuellen Gruppenschlüssel und auf nachrichtenspezifischen Daten basierenden Programmierschlüssels; Codierung eines neues Gruppenschlüssels mit dem Programmierschlüssel, um einen neuen codierten Gruppenschlüssel zu erhalten; Hinzufügen der nachrichtenspezifischen Daten zu dem codierten neuen Gruppenschlüssel um eine neue Gruppenschlüsselnachricht zu erzeugen; und Weiterleitung der neuen Gruppenschlüsselnachricht an den Sender zum Senden an die ausgewählten Mobilvorrichtungen (18).
  37. System nach Anspruch 36, dadurch gekennzeichnet, dass das Treiberbauteil (210) so konfiguriert ist, dass es folgende Schritte ausführt: Empfang der neuen Gruppenschlüsselnachricht; Erhalt des auf den nachrichtenspezifischen Daten und dem aktuellen, im Funkempfänger (208) gespeicherten Gruppenschlüssel basierenden Programmierschlüssels; Decodierung des codierten neuen Gruppenschlüssels unter Verwendung des Programmierschlüssels; und Lieferung des neuen Gruppenschlüssels an den Funkempfänger (208) zum Speichern desselben im dortigen Schlüsselspeicher.
DE69930504T 1998-01-07 1999-01-07 System zur übertragung von zugriffinformationen und web-inhalt zu einem mobilen gerät Expired - Lifetime DE69930504T2 (de)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US7072098P 1998-01-07 1998-01-07
US70720P 1998-01-07
US7423698P 1998-02-10 1998-02-10
US74236P 1998-02-10
US7512398P 1998-02-13 1998-02-13
US75123P 1998-02-13
US09/108,145 US6496928B1 (en) 1998-01-07 1998-06-30 System for transmitting subscription information and content to a mobile device
US108145 1998-06-30
PCT/US1999/000309 WO1999035801A1 (en) 1998-01-07 1999-01-07 System for transmitting subscription information and content to a mobile device

Publications (2)

Publication Number Publication Date
DE69930504D1 DE69930504D1 (de) 2006-05-11
DE69930504T2 true DE69930504T2 (de) 2006-12-14

Family

ID=27490846

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69930504T Expired - Lifetime DE69930504T2 (de) 1998-01-07 1999-01-07 System zur übertragung von zugriffinformationen und web-inhalt zu einem mobilen gerät

Country Status (6)

Country Link
US (1) US6496928B1 (de)
EP (1) EP1051824B1 (de)
JP (1) JP2002501334A (de)
CA (1) CA2314983A1 (de)
DE (1) DE69930504T2 (de)
WO (1) WO1999035801A1 (de)

Families Citing this family (94)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6282294B1 (en) * 1998-01-07 2001-08-28 Microsoft Corporation System for broadcasting to, and programming, a motor device in a protocol, device, and network independent fashion
DE19822685A1 (de) * 1998-05-20 2000-01-27 Deutsche Telekom Ag Verfahren zur gesicherten Übertragung von Nachrichten
GB2349548A (en) * 1999-04-27 2000-11-01 Roke Manor Research Downloading software to mobile telecommunication users
DE19919909C2 (de) * 1999-04-30 2001-07-19 Wincor Nixdorf Gmbh & Co Kg Signierung und Signaturprüfung von Nachrichten
US6888797B1 (en) * 1999-05-05 2005-05-03 Lucent Technologies Inc. Hashing-based network load balancing
JP3858527B2 (ja) * 1999-08-10 2006-12-13 富士ゼロックス株式会社 データ生成装置およびデータ検証装置ならびにその方法
US7581110B1 (en) 1999-08-25 2009-08-25 Nokia Corporation Key distribution for encrypted broadcast data using minimal system bandwidth
US7280978B1 (en) * 1999-09-17 2007-10-09 Raymond Anthony Joao Apparatus and method for providing and/or for fulfilling subscription services
EP1146685B1 (de) * 2000-04-12 2004-01-14 Matsushita Electric Industrial Co., Ltd. Entschlüsselungsvorrichtung
FR2812509B1 (fr) * 2000-07-26 2002-12-27 Gemplus Card Int Procede de reconnaissance securisee entre deux appareils d'un reseau radiofrequence
US7257386B1 (en) 2000-11-20 2007-08-14 Hewlett-Packard Development Company, L.P. Data transfer system and method of data transfer
US7512806B2 (en) * 2000-11-30 2009-03-31 Palmsource, Inc. Security technique for controlling access to a network by a wireless device
JP2002278903A (ja) * 2001-03-15 2002-09-27 Sony Corp 情報処理装置および方法、記録媒体、並びにプログラム
US7809944B2 (en) * 2001-05-02 2010-10-05 Sony Corporation Method and apparatus for providing information for decrypting content, and program executed on information processor
US7366533B2 (en) * 2001-05-16 2008-04-29 Motorola, Inc. Methods for providing access to wireless resources in a trunked radio communication system
US20030177378A1 (en) * 2001-06-01 2003-09-18 Erland Wittkotter Apparatus and method for the decryption of an encrypted electronic document
WO2002102484A1 (en) 2001-06-15 2002-12-27 Walker Digital, Llc Method and apparatus for planning and customizing a gaming experience
US9210137B2 (en) * 2001-08-24 2015-12-08 Thomson Licensing Local digital network, methods for installing new devices and data broadcast and reception methods in such a network
US7611409B2 (en) * 2001-09-20 2009-11-03 Igt Method and apparatus for registering a mobile device with a gaming machine
US7699703B2 (en) * 2001-09-20 2010-04-20 Igt Method and apparatus for registering a mobile device with a gaming machine
WO2003036857A1 (en) 2001-10-24 2003-05-01 Nokia Corporation Ciphering as a part of the multicast cencept
TWI256263B (en) * 2001-11-21 2006-06-01 Nagravision Sa Method for controlling access to specific services from a broadcaster
KR100446240B1 (ko) * 2001-12-05 2004-08-30 엘지전자 주식회사 이동통신 시스템의 방송형 무선 데이터 서비스 방법
US8385890B2 (en) * 2001-12-05 2013-02-26 Lg Electronics Inc. Wireless data service apparatus and method in broadcast mobile communication system
FR2834404B1 (fr) * 2001-12-31 2004-12-10 Cegetel Groupe Procede de securisation deportee d'echange de donnees
US7475248B2 (en) * 2002-04-29 2009-01-06 International Business Machines Corporation Enhanced message security
JP2004266342A (ja) * 2003-02-03 2004-09-24 Sony Corp 無線アドホック通信システム、端末、その端末における復号方法、暗号化方法及びブロードキャスト暗号鍵配布方法並びにそれらの方法を端末に実行させるためのプログラム
US7467183B2 (en) * 2003-02-14 2008-12-16 Microsoft Corporation Method, apparatus, and user interface for managing electronic mail and alert messages
US7412058B2 (en) * 2003-03-18 2008-08-12 Delphi Technologies, Inc. Digital receiver and method for receiving secure group data
US7900041B2 (en) * 2003-07-22 2011-03-01 Irdeto Canada Corporation Software conditional access system
US8512144B2 (en) 2003-10-20 2013-08-20 Tipping Point Group, Llc Method and apparatus for providing secondary gaming machine functionality
US7870354B2 (en) * 2003-11-04 2011-01-11 Bakbone Software, Inc. Data replication from one-to-one or one-to-many heterogeneous devices
US7532723B2 (en) * 2003-11-24 2009-05-12 Interdigital Technology Corporation Tokens/keys for wireless communications
JP4580635B2 (ja) * 2003-12-10 2010-11-17 ソニー株式会社 車載通信システムおよび通信方法、車載通信端末および通信方法、プログラム記録媒体、並びにプログラム
AR047414A1 (es) * 2004-01-13 2006-01-18 Interdigital Tech Corp Un metodo y un aparato ofdm para proteger y autenticar informacion digital transmitida inalambricamente
US7289629B2 (en) * 2004-02-09 2007-10-30 Microsoft Corporation Primitives for fast secure hash functions and stream ciphers
US7505588B2 (en) * 2004-03-31 2009-03-17 Microsoft Corporation Stream cipher design with revolving buffers
US7966662B2 (en) * 2004-09-02 2011-06-21 Qualcomm Incorporated Method and system for managing authentication and payment for use of broadcast material
US20070055859A1 (en) * 2005-09-02 2007-03-08 Mediatek Inc. Boot systems and methods
US20070150339A1 (en) * 2005-12-22 2007-06-28 Thumb-Find International, Inc. Method and apparatus for electronic message (coupon) distribution
US9028329B2 (en) 2006-04-13 2015-05-12 Igt Integrating remotely-hosted and locally rendered content on a gaming device
US8784196B2 (en) 2006-04-13 2014-07-22 Igt Remote content management and resource sharing on a gaming machine and method of implementing same
US8992304B2 (en) 2006-04-13 2015-03-31 Igt Methods and systems for tracking an event of an externally controlled interface
US10026255B2 (en) 2006-04-13 2018-07-17 Igt Presentation of remotely-hosted and locally rendered content for gaming systems
US7681048B2 (en) * 2006-04-27 2010-03-16 Matthew Thomas Starr Data encryption using a key and moniker for mobile storage media adapted for library storage
KR20080004165A (ko) * 2006-07-05 2008-01-09 삼성전자주식회사 브로드캐스트 암호화를 이용한 디바이스 인증 방법
US20090156303A1 (en) 2006-11-10 2009-06-18 Igt Bonusing Architectures in a Gaming Environment
US9311774B2 (en) 2006-11-10 2016-04-12 Igt Gaming machine with externally controlled content display
KR20090011152A (ko) * 2007-07-25 2009-02-02 삼성전자주식회사 콘텐츠 제공 방법 및 시스템
US8908870B2 (en) * 2007-11-01 2014-12-09 Infineon Technologies Ag Method and system for transferring information to a device
US8627079B2 (en) 2007-11-01 2014-01-07 Infineon Technologies Ag Method and system for controlling a device
US20100023752A1 (en) * 2007-12-27 2010-01-28 Motorola, Inc. Method and device for transmitting groupcast data in a wireless mesh communication network
US8479013B2 (en) * 2008-01-18 2013-07-02 Photonic Data Security, Llc Secure portable data transport and storage system
US9251337B2 (en) * 2011-04-27 2016-02-02 International Business Machines Corporation Scalable, highly available, dynamically reconfigurable cryptographic provider with quality-of-service control built from commodity backend providers
US9875607B2 (en) 2011-07-13 2018-01-23 Igt Methods and apparatus for providing secure logon to a gaming machine using a mobile device
US10297105B2 (en) 2011-09-09 2019-05-21 Igt Redemption of virtual tickets using a portable electronic device
US10121318B2 (en) 2011-09-09 2018-11-06 Igt Bill acceptors and printers for providing virtual ticket-in and ticket-out on a gaming machine
US9367835B2 (en) 2011-09-09 2016-06-14 Igt Retrofit devices for providing virtual ticket-in and ticket-out on a gaming machine
US8613659B2 (en) 2011-09-09 2013-12-24 Igt Virtual ticket-in and ticket-out on a gaming machine
US9524609B2 (en) 2011-09-30 2016-12-20 Igt Gaming system, gaming device and method for utilizing mobile devices at a gaming establishment
US8613668B2 (en) 2011-12-22 2013-12-24 Igt Directional wireless communication
US8876596B2 (en) 2012-02-29 2014-11-04 Igt Virtualized magnetic player card
US9311769B2 (en) 2012-03-28 2016-04-12 Igt Emailing or texting as communication between mobile device and EGM
US9412227B2 (en) 2012-07-11 2016-08-09 Igt Method and apparatus for offering a mobile device version of an electronic gaming machine game at the electronic gaming machine
JP6007075B2 (ja) * 2012-11-16 2016-10-12 任天堂株式会社 サービス提供システム、サービス提供方法、サーバシステムおよびサービス提供プログラム
TWI511509B (zh) * 2012-12-11 2015-12-01 Inst Information Industry 智慧型電表基礎建設網路系統及其訊息廣播方法
US9432344B2 (en) * 2013-03-15 2016-08-30 Low Gravity Innovation, Inc. Secure storage and sharing of user objects
CN114819961A (zh) * 2013-08-08 2022-07-29 维萨国际服务协会 用于为移动设备供应支付凭证的方法和系统
US10264016B2 (en) 2014-07-10 2019-04-16 Metacert, Inc. Methods, systems and application programmable interface for verifying the security level of universal resource identifiers embedded within a mobile application
US10140615B2 (en) 2014-09-22 2018-11-27 Visa International Service Association Secure mobile device credential provisioning using risk decision non-overrides
US10659959B2 (en) * 2014-11-12 2020-05-19 Blackberry Limited Enhanced cell broadcast service via secure group broadcast
EP3261355A4 (de) * 2015-02-17 2018-08-15 Sony Corporation Empfangsvorrichtung, empfangsverfahren, sendevorrichtung und sendeverfahren
US9710619B2 (en) * 2015-03-31 2017-07-18 Canon Information And Imaging Solutions, Inc. System and method for providing an electronic document
US9916735B2 (en) 2015-07-22 2018-03-13 Igt Remote gaming cash voucher printing system
US10055930B2 (en) 2015-08-11 2018-08-21 Igt Gaming system and method for placing and redeeming sports bets
US10417867B2 (en) 2015-09-25 2019-09-17 Igt Gaming system and method for automatically transferring funds to a mobile device
US20170092054A1 (en) 2015-09-25 2017-03-30 Igt Gaming system and method for utilizing a mobile device to fund a gaming session
US10652748B2 (en) 2016-04-23 2020-05-12 Metacert, Inc. Method, system and application programmable interface within a mobile device for indicating a confidence level of the integrity of sources of information
US10217317B2 (en) 2016-08-09 2019-02-26 Igt Gaming system and method for providing incentives for transferring funds to and from a mobile device
US10916090B2 (en) 2016-08-23 2021-02-09 Igt System and method for transferring funds from a financial institution device to a cashless wagering account accessible via a mobile device
US10621824B2 (en) 2016-09-23 2020-04-14 Igt Gaming system player identification device
US10505950B2 (en) * 2017-07-10 2019-12-10 Dark Matter L.L.C. System, method, and computer program product for multi-layer encryption of an efficient broadcast message
US10332344B2 (en) 2017-07-24 2019-06-25 Igt System and method for controlling electronic gaming machine/electronic gaming machine component bezel lighting to indicate different wireless connection statuses
US10360763B2 (en) 2017-08-03 2019-07-23 Igt System and method for utilizing a mobile device to facilitate fund transfers between a cashless wagering account and a gaming establishment retail account
US10360761B2 (en) 2017-08-03 2019-07-23 Igt System and method for providing a gaming establishment account pre-approved access to funds
US10380843B2 (en) 2017-08-03 2019-08-13 Igt System and method for tracking funds from a plurality of funding sources
US10373430B2 (en) 2017-08-03 2019-08-06 Igt System and method for tracking fund transfers between an electronic gaming machine and a plurality of funding sources
US11922765B2 (en) 2017-12-18 2024-03-05 Igt System and method employing virtual tickets
US10643426B2 (en) 2017-12-18 2020-05-05 Igt System and method for providing a gaming establishment account automatic access to funds
US11341817B2 (en) 2017-12-18 2022-05-24 Igt System and method for providing awards for utilizing a mobile device in association with a gaming establishment retail account
US10950088B2 (en) 2017-12-21 2021-03-16 Igt System and method for utilizing virtual ticket vouchers
US11043066B2 (en) 2017-12-21 2021-06-22 Igt System and method for centralizing funds to a primary gaming establishment account
US10970968B2 (en) 2018-04-18 2021-04-06 Igt System and method for incentivizing the maintenance of funds in a gaming establishment account
WO2021194501A1 (en) * 2020-03-27 2021-09-30 Hewlett-Packard Development Company, L.P. Alternate operating systems

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4613901A (en) 1983-05-27 1986-09-23 M/A-Com Linkabit, Inc. Signal encryption and distribution system for controlling scrambling and selective remote descrambling of television signals
US5604744A (en) 1992-10-05 1997-02-18 Telefonaktiebolaget Lm Ericsson Digital control channels having logical channels for multiple access radiocommunication
US5325432A (en) 1993-02-04 1994-06-28 Motorola, Inc. Method for updating encryption key information in communication units
FI100563B (fi) 1996-01-30 1997-12-31 Nokia Oy Ab Digitaalisten esitysobjektien salaus lähetyksessä ja tallennuksessa
US6084969A (en) * 1997-12-31 2000-07-04 V-One Corporation Key encryption system and method, pager unit, and pager proxy for a two-way alphanumeric pager network

Also Published As

Publication number Publication date
WO1999035801A1 (en) 1999-07-15
EP1051824B1 (de) 2006-03-22
EP1051824A1 (de) 2000-11-15
CA2314983A1 (en) 1999-07-15
DE69930504D1 (de) 2006-05-11
US6496928B1 (en) 2002-12-17
JP2002501334A (ja) 2002-01-15

Similar Documents

Publication Publication Date Title
DE69930504T2 (de) System zur übertragung von zugriffinformationen und web-inhalt zu einem mobilen gerät
US6282294B1 (en) System for broadcasting to, and programming, a motor device in a protocol, device, and network independent fashion
DE60309937T2 (de) System und verfahren zum schutz von daten in einem kommunikationsgerät
DE60302148T2 (de) System und verfahren zur auswahl der nachrichteneinstellungen
DE60320486T2 (de) Systeme und Verfahren zur Lieferung von Anwendungen und zur Konfigurationsverwaltung für mobile Geräte
DE69730950T2 (de) Kommunikationsnetzwerksendgerät mit einer vielfalt von applikationen
DE69824975T2 (de) Verfahren zur übertragung von informationsdaten von einem sender zu einem empfänger über einen transcoder
DE69832057T2 (de) Datendienst in einem mobilen kommunikationsnetz
DE60114986T2 (de) Verfahren zur herausgabe einer elektronischen identität
DE69913953T2 (de) Verfahren und vorrichtung zur verarbeitung von elektronischen post
DE10051571B4 (de) Methode und System zur Unterstützung von Sicherheitsvorgaben unter Verwendung einer Stylesheet-Verarbeitung
DE602006000817T2 (de) System und Methode für steuernde Datenkommunikation zwischen einem Server und einer Client-Vorrichtung
DE69734189T2 (de) Verteiltes Netzwerkrechnersystem und Datenaustauschgerät
DE60318825T2 (de) Vorrichtung und verfahren zur unterstützung von mehreren zertifizierungstatusanbietern auf einem mobilen kommunikationsgerät
EP1336937A1 (de) Zutrittskontrollsystem, Zutrittskontrollverfahren und dafur geeignete Vorrichtungen
DE60102663T2 (de) Darstellung von anwendungen in einem telekommunikationssystem
DE60206592T2 (de) Offset Sicherheitsverfahren zum Datenaustausch
CN106878446A (zh) 通讯方法
WO2003036401A2 (de) Verfahren zum erfassen von mehreren feldgeräten in einer gerätekonfiguration
DE10147889A1 (de) Proxy-Einheit, Verfahren zum rechnergestützten Schützen eines Applikations-Server-Programms und Anordnung mit einer Proxy-Einheit und einer Einheit zum Ausführen eines Applikations-Server-Programms
DE60126421T2 (de) Verfahren und terminal zum sicheren bezug von programmen
DE602005003221T2 (de) Verfahren und Vorrichtung für die Verarbeitung der digital unterzeichneten Anzeigen, um Adressen-Fehlanpassungen festzustellen
DE602004012707T2 (de) System und Verfahren zur Verarbeitung von Schriftartdaten
DE10107883B4 (de) Verfahren zur Übertragung von Daten, Proxy-Server und Datenübertragungssystem
DE60007171T2 (de) Automatisches formularzugang- und sende-system und verfahren

Legal Events

Date Code Title Description
8364 No opposition during term of opposition