-
Gebiet der
Erfindung
-
Die vorliegende Erfindung bezieht
sich auf die Lieferung von Diensten an mobile Benutzer in Abhängigkeit
von der Position der Benutzer.
-
Hintergrund
der Erfindung
-
Kommunikationsinfrastrukturen, die
geeignet für
mobile Benutzer (insbesondere, wenn auch nicht ausschließlich Zellularfunkinfrastrukturen)
sind, werden verstärkt
eingeführt.
Während
die Hauptmotivation das Mobilfernsprechen war, hat der Wunsch, mobile,
datenbasierte Dienste über
diese Infrastrukturen zu implementieren, zu der schnellen Entwicklung
von Trägerdiensten
mit Datenfähigkeit über derartige
Infrastrukturen geführt.
Dies hat die Möglichkeit
eröffnet,
daß viele
internetbasierte Dienste für
mobile Benutzer verfügbar
sind.
-
Beispielhaft zeigt 1 eine Form einer bekannten Kommunikationsinfrastruktur
für mobile
Benutzer, die sowohl Fernsprech- als auch Datenträgerdienste
liefert. Bei diesem Beispiel kommuniziert eine mobile Entität 20,
die mit einem Funkteilsystem 22 und einem Telefonteilsystem 23 versehen
ist, mit der festen Infrastruktur eines GSM-PLMN (PLMN = Public
Land Mobile Network = öffentliches
Mobilfunknetz) 10, um grundlegende Sprach-Fernsprechdienste
bereitzustellen. Zusätzlich
umfaßt
die mobile Entität 20 ein
Datenhandhabungsteilsystem 25, das über eine Datenschnittstelle 24 mit
dem Funkteilsystem 22 für
das Senden und Empfangen von Daten über einen Trägerdienst
mit Datenfähigkeit,
der durch das PLMN bereitgestellt wird, zusammenarbeitet; der Trägerdienst
mit Datenfähigkeit
ermöglicht
es der mobilen Entität 20,
mit einem Dienstsystem 40 zu kommunizieren, das mit dem öffentlichen
Internet 39 verbunden ist. Das Datenhandhabungsteilsystem 25 unterstützt eine
Betriebsumgebung 26, in der Anwendungen laufen, wobei die
Betriebsumgebung einen geeigneten Kommunikationsstapel umfaßt.
-
Insbesondere weist die feste Infrastruktur 10 des
GSM-PLMN eines oder mehrere Basisstationsteilsysteme (BSS; BSS =
Base Station Substation) 11 und ein Netz- und Schaltteilsystem
NSS (NSS = Network and Switching Subsystem) 12 auf. Jedes
BSS 11 weist eine Basisstationssteuerung (BSC; BSC = Base
Station Controller) 14 auf, die mehrere Basis-Sende-/Empfangsgerätstationen
(BTS; BTS = Base Transceiver Station) 13 steuert, wobei
jede derselben einer jeweiligen „Zelle des Funknetzes zugeordnet
ist. Wenn das Funkteilsystem 22 der mobilen Entität 20 aktiv
ist, kommuniziert dasselbe über
eine Funkverbindung mit der BTS 13 der Zelle, in der sich die
mobile Entität
gegenwärtig
befindet. Bezüglich des
NSS 12 weist dasselbe eines oder mehrere Mobilschaltstellen
(MSC; MSC = Mobile Switching Center) 15 gemeinsam mit anderen
Elementen auf, wie z. B. Besucherortsregistern 32 und einem
Heimatortsregister 31.
-
Wenn die mobile Entität 20 verwendet
wird, um einen normalen Telefonanruf durchzuführen, wird eine Verkehrsschaltung
zum Tragen digitalisierter Sprache durch das relevante BSS 11 zu
dem NSS 12 eingerichtet, das dann verantwortlich für ein Leiten des
Anrufs zu dem Zieltelefon ist (ob nun in dem gleichen PLMN oder
in einem anderen Netz).
-
Bezüglich einer Datenübertragung
zu/von der mobilen Entität 20 sind
bei dem vorliegenden Beispiel drei unterschiedliche Trägerdienste
mit Datenfähigkeit
dargestellt, obwohl andere Möglichkeiten existieren.
Ein erster Trägerdienst
mit Datenfähigkeit ist
in der Form eines Leitungsvermittlungsdaten-Dienstes (CSD-Dienstes;
CSD = Circuit Switched Data) verfügbar. In diesem Fall wird eine
Voll-Verkehrsschaltung zum Tragen von Daten verwendet und die MSC 32 leitet
die Schaltung zu einer Interworking- bzw. Zusammenarbeit- Funktion IWF 34,
deren genaue Natur davon abhängt,
was mit der anderen Seite der IWF verbunden ist. So könnte die
IWF konfiguriert sein, um einen direkten Zugang zu dem öffentlichen
Internet 39 zu liefern (d. h. eine Funktionalität zu liefern,
die einem IAP (IAP = Internet Access Provider = Internetzugriffsanbieter) ähnelt. Alternativ
könnte
die IWF einfach ein Modem sein, das mit einem PSTN verbunden ist;
in diesem Fall kann ein Internetzugang durch eine Verbindung über das PSTN
zu einem Standard-IAP erzielt werden.
-
Ein zweiter Trägerdienst mit Datenfähigkeit mit
niedriger Bandbreite ist durch die Verwendung des Kurznachrichtendienstes
(Short Message Service) verfügbar,
der Daten, die in Signalisierungskanalschlitzen getragen werden,
an eine SMS-Einheit 33 leitet, die angeordnet sein kann,
um eine Verbindbarkeit mit dem öffentlichen
Internet 39 bereitzustellen.
-
Ein dritter Trägerdienst mit Datenfähigkeit wird
in der Form eines GPRS (GPRS = General Packet Radio Service = Allgemeinpaketfunkdienst)
bereitgestellt, der es ermöglicht,
daß IP-
(oder X.25-) Paketdaten von dem Datenhandhabungssystem der mobilen
Entität 20 über die
Datenschnittstelle 24, das Funkteilsystem 21 und
das relevante BSS 11 an ein GPRS-Netz 17 des PLMN 10 (und
umgekehrt) geleitet werden können.
Das GPRS-Netz 17 umfaßt
einen SGSN (SGSN = Serving GPRS Support Node – Dienst-GPRS-Unterstützungsknoten) 18,
der schnittstellenmäßig die
BSC 14 mit dem Netz 17 verbindet, und einen GGSN
(GGSN = Gateway GPRS Support Node = Gateway-GPRS-Unterstützungsknoten) 19, der
das Netz 17 schnittstellenmäßig mit einem externen Netz
verbindet (bei diesem Beispiel dem öffentlichen Internet 39).
Volle Details des GPRS sind in der GSM 03.60-Spezifizierung der
ETSI (Europäisches Telekommunikationsstandardinstitut)
zu finden. Unter Verwendung des GPRS kann die mobile Entität 20 Paketdaten über das
BSS 11 und das GPRS-Netz 17 mit Entitäten, die
mit dem öffentlichen
Internet 39 verbunden sind, austauschen.
-
Die Datenverbindung zwischen dem
PLMN 10 und dem Internet 39 ist im allgemeinen
durch eine Firewall 35 mit einer Proxy- und/oder Gateway-Funktionalität.
-
Andere Trägerdienste mit Datenfähigkeit
als diejenigen, die oben beschrieben sind, können bereitgestellt werden,
wobei die beschriebenen Dienste einfach Beispiele dessen, was möglich ist,
sind.
-
In 1 ist
ein Dienstsystem 40 gezeigt, das mit dem Internet 40 verbunden
ist, wobei dieses Dienstsystem für
das/die BS/Anwendung 26, das/die in der mobilen Entität läuft, durch
die Verwendung eines der oben beschriebenen Trägerdienste mit Datenfähigkeit
zugänglich
ist. Die Trägerdienste
mit Datenfähigkeit
könnten
gleichermaßen
einen Zugriff auf ein Dienstsystem liefern, das sich innerhalb des
Bereichs des PLMN-Operators befindet oder mit einem anderen öffentlichen
oder privaten Datennetz verbunden ist.
-
Bezüglich der BS/Anwendungssoftware 26, die
in dem Datenhandhabungsteilsystem 25 der mobilen Entität 20 läuft, könnte dies
z. B. eine WAP-Anwendung sein, die auf einem WAP-Stapel läuft, wobei „WAP" der Drahtlosanwendungsprotokollstandard
ist. Details des WAP sind z. B in dem Buch „Official Wireless Application
Protocol", Wireless
Application Protocol Forum, Ltd., veröffentlicht 1999 durch Wiley
Computer Publishing, zu finden. Wenn die BS/Anwendungssoftware WAP-fähig ist,
dient die Firewall im allgemeinen auch als ein WAP-Proxy und -Gateway.
Natürlich
kann das/die BS/Anwendung 26 eine weitere Funktionalität (z. B.
E-Mail-Client) anstelle
von oder zusätzlich
zu der WAP-Funktionalität aufweisen.
-
Die mobile Entität 20 kann viele unterschiedliche
Formen annehmen. Sie könnte
z. B. zwei separate Einheiten sein, wie z. B. ein Mobiltelefon (mit Elementen 22–24)
und ein mobiler PC (Datenhandhabungssystem 25), die durch
eine geeignete Verbindung gekoppelt sind (Wireline-, Infrarot- oder sogar Nahbereichsfunksystem,
wie z. B. Bluetooth). Alternativ könnte die mobile Entität 20 eine
einzelne Einheit sein, wie z. B. ein Mobiltelefon mit WAP-Funktionalität. Natürlich kann
die Telefonfunktionalität 24, wenn
nur ein Daten-Senden/Empfang benötigt
wird (und keine Sprache), weggelassen werden; ein Beispiel hiervon
ist ein PDA mit eingebauter GSM-Funktionalität mit Datenfähigkeit,
während
ein weiteres Beispiel eine Digitalkamera (das Datenhandhabungssystem)
ebenso mit eingebauter GSM-Funktionalität mit Datenfähigkeit
ist, die das Hochladen von Digitalbildern von der Kamera an einen
Speicherserver ermöglicht.
-
Während
die obige Beschreibung Bezug nehmend auf ein PLMN basierend auf
einer GSM-Technologie erfolgt ist, ist es ersichtlich, daß viele
andere Zellularfunktechnologien existieren und üblicherweise den gleichen Typ
von Funktionalität
liefern, wie für
das GSM-PLMN 10 beschrieben ist.
-
In jüngster Zeit zeigte sich großes Interesse an „ortsbasierten", „ortsabhängigen" oder „ortsbewußten" Diensten für mobile
Benutzer, wobei dies Dienste sind, die den gegenwärtigen Ort
des Benutzers (oder einer anderen mobilen Partei) berücksichtigen.
Die grundlegendste Form dieses Dienstes ist der Notfallortsdienst,
durch den ein Benutzer in Schwierigkeiten einen Notknopf auf seinem
Mobiltelefon drücken
kann, um eine Notfallhilfeanforderungsnachricht mit seinen angefügten Ortsdaten
zu senden. Ein weiterer bekannter ortsbasierter Dienst ist die Bereitstellung
von Verkehrs- und Routenführungsinformationen
an Kraftfahrzeugfahrer basierend auf ihrer gegenwärtigen Position.
Ein weiterer bekannter Dienst ist ein „Gelbe-Seiten"-Dienst, bei dem
ein Benutzer etwas über
Einrichtungen (Läden, Restaurants,
Theater usw.), die bezüglich
seines gegenwärtigen
Orts lokal sind, herausfinden kann. Der Ausdruck „ortsbewußte Dienste" wird hierin verwendet,
um sich allgemein auf diese und ähnliche
Dienste zu beziehen, bei denen eine Ortsabhängigkeit existiert.
-
Ortsbewußte Dienste benötigen alle
einen Benutzerort als einen Eingabeparameter. Eine Anzahl von Verfahren
zum Bestimmen des Ortes eines mobilen Benutzers, der durch eine
zugeordnete mobile Ausrüstung
dargestellt wird, existieren bereits. Beispielhafte Ortsbestimmungsverfahren
werden nun Bezug nehmend auf die 2–5 beschrieben. Wie ersichtlich
ist, führen
einige dieser Verfahren dazu, daß der Benutzer seinen Ort kennt,
wodurch es ermöglicht
wird, daß er
denselben an einen ortsbewußten
Dienst überträgt, an dessen
Empfang er interessiert ist, während
andere der Verfahren dazu führen,
daß der
Ort des Benutzers einer Netzentität bekannt wird, von der derselbe
direkt an einen ortsbewußten
Dienst geliefert werden kann (im allgemeinen nur mit der Zustimmung
des betreffenden Benutzers). Es wird darauf hingewiesen, daß zusätzliche Verfahren
zu denjenigen, die in den 2–5 dargestellt sind, existieren.
-
Die 2–5 stellen zusätzlich zu
einer Ortsbestimmung auch dar, wie die mobile Entität einen ortsbewußten Dienst,
der durch das Dienstsystem 40 bereitgestellt wird, anfordert.
Bei den vorliegenden Beispielen ist die Anforderung dargestellt,
um über ein
Zellularmobilnetz (PLMN 10) an das Dienstsystem 40 geleitet
zu werden. Das PLMN ähnelt
z. B. dem, das in 1 dargestellt
ist, wobei die Dienstanforderung unter Verwendung eines Trägerdienstes mit
Datenfähigkeit
des PLMN gemacht wird. Das Dienstsystem 40 kann ein Teil
des PLMN selbst sein oder kann mit demselben durch ein Datennetz,
wie z. B. das öffentliche
Internet, verbunden sein. Es wird jedoch darauf verwiesen, daß eine andere
Infrastruktur als ein Zellularnetz alternativ zum Stellen der Dienstanforderung
verwendet werden kann.
-
Das Ortsbestimmungsverfahren, das
in 2 dargestellt ist,
verwendet ein Trägheitspositionierungssystem 50,
das in der mobilen Entität 20A vorgesehen
ist, wobei dieses System 50 die Verschiebung der mobilen
Entität
aus einer anfänglichen Referenzposition
bestimmt. Wenn die mobile Entität 20A einen
ortsbewußten
Dienst aufrufen möchte,
leitet dieselbe ihre gegenwärtige
Position gemeinsam mit der Dienstanforderung 51 an das
entsprechende Dienstsystem 40. Dieser Ansatz vermeidet
den Bedarf nach einer Infrastruktur, um einen externen Referenzrahmen
bereitzustellen; Kosten-, Größen- und Langzeitgenauigkeitsbelange
machen jedoch gegenwärtig
derartige Systeme zum Einbau in Massenhandvorrichtungen unattraktiv.
-
3 zeigt
zwei unterschiedliche Ortsbestimmungssysteme, die beide die Verwendung
lokaler Funkstellen mit fester Position beinhalten, die hier als
Infrarot-Funkstellen IRD gezeigt sind, obwohl andere Technologien,
wie z. B. Nahbereichsfunksysteme (insbesondere „Bluetooth"-Systeme) gleichermaßen verwendet werden könnten. Die
rechte Hälfte von 3 zeigt eine Anzahl unabhängiger Funkstellen 55,
die kontinuierlich ihre einzelnen Orte übertragen. Eine mobile Entität 20B ist
angeordnet, um die Übertragungen
von einer Funkstelle aufzugreifen, wenn dieselbe ausreichend nahe
ist, wodurch dessen Position zu der Genauigkeit seines Empfangsbereichs
eingerichtet wird. Diese Ortsdaten können dann an eine Anforderung 59,
die durch die mobile Entität 20B durchgeführt wird,
an einen ortsbewußten
Dienst, der von dem Dienstsystem 40 verfügbar ist,
angehängt
werden. Eine Variation dieser Anordnung besteht darin, daß die Funkstellen 55 Informationen übertragen,
die, während
sie keine direkten Ortsdaten sind, verwendet werden können, um
derartige Daten nachzuschlagen (z. B. können die Daten der Internet-Homepage-URL
eines Speichers sein, der die betreffende Funkstelle 55 häust, wobei
diese Homepage den Speicherort angibt – oder zumindest eine Identität, wodurch
ein Nachschlagen eines Orts in einem Verzeichnisdienst ermöglicht wird).
-
In der linken Hälfte in 3 sind
die IRB-Funkstellen 54 alle mit einem Netz verbunden, das
mit einem Ortsserver bzw. Positionsserver 57 verbunden
ist. Die Funkstellen 54 übertragen ein Präsenzsignal,
wobei, wenn eine mobile Entität 20C ausreichend
nahe an einer Funkstelle ist, um das Präsenzsignal aufzugreifen, dieselbe
durch ein Senden ihrer Identität
an die Funkstelle anspricht. (So können bei diesem Ausführungsbeispiel
sowohl die Funkstellen 54 als auch die mobile Entität 20C IR-Signale
sowohl empfangen als auch senden, wohingegen Funkstellen 55 IR-Signale
nur senden und die mobile Entität 20B dieselben
nur empfängt).
Daraufhin, daß eine
Funkstelle 54 die Identität einer mobilen Entität empfängt, sendet
dasselbe eine Nachricht über
ein Netz 56 an den Ortsserver 57, wobei diese
Nachricht die Identität
der mobilen Entität 20C mit
dem Ort der relevanten Funkstelle 54 verbindet. Nun darf,
wenn die mobile Entität
einen ortsbewußten
Dienst aufrufen möchte,
der durch das Dienstsystem 40 bereitgestellt wird, da dieselbe
ihren Ort nicht kennt, sie ihre Identität nicht in die Dienstanforderung 58 einschließen und
sich darauf verlassen, daß das
Dienstsystem 40 den gegenwärtigen Ort der mobilen Entität in dem
Ortsserver 57 nachschlägt.
Da Ortsdaten persönlich
und möglicherweise
sehr empfindlich sind, liefert der Ortsserver 57 im allgemeinen
nur Ortsdaten an das Dienstsystem 40, nachdem letzteres
einen Autorisierungstoken erzeugt hat, der durch die mobile Entität 20B in
der Anforderung 58 geliefert wird. Es ist zu erkennen,
daß, während das
Dienstsystem 40 als Handhabungsdienstanforderungen von
beiden Typen mobiler Entität 20B und 20C dargestellt
ist, separate Systeme 40 für jeden Mobilgerättyp vorgesehen
sein können
(dies trifft auch auf die Dienstsysteme, die in den 4 und 5 dargestellt sind,
zu).
-
4 stellt
mehrere Formen eines GPS-Ortsbestimmungssystems dar. Ruf der linken Seite
in 4 ist eine mobile
Entität 20D mit
einem Standard-GPS-Modul vorgesehen und ist in der Lage, den Ort
der Entität 20D zu
bestimmen, indem Signale von Satelliten 60 aufgegriffen
werden. Die Entität 20D kann
dann diesen Ort liefern, wenn in einer Anforderung 21 ein
ortsbewußter
Dienst von dem Dienstsystem 40 angefordert wird.
-
Die rechte Seite von 4 stellt bezüglich der mobilen Entität 20E zwei
Weisen dar, auf die eine Unterstützung
an die Entität
beim Herleiten eines Ortes von GPS-Satelliten bereitgestellt werden
kann. Erstens kann das PLMN 10 mit festen GPS-Empfängern 62 versehen
sein, die jeweils kontinuierlich die Satelliten 60 verfolgen,
die von dem Empfänger
sichtbar sind, und Informationen bezüglich dessen, wo nach diesen
Satelliten zu suchen ist, sowie geschätzte Signalankunftszeiten in
Nachrichten 63 an lokale mobile Entitäten 20E leiten; dies
ermöglicht
es, daß die
mobilen Entitäten 20E eine
Erfassungszeit für
die Satelliten wesentlich reduzieren und eine Meßgenauigkeit erhöhen (siehe „Geolocation
Technology Pinpoints Wireless 911 calls within 15 Feet", 1. Juli 99, Lucent
Technologies, Bell Labs). Zweitens kann als alternative Verbesserung
die Verarbeitungslast auf die mobile Entität 20E reduziert werden
und ein codiertes Zittern unter Verwendung der Dienste der Netzentität 64 entfernt
werden (in dem PLMN 10 oder durch dasselbe zugänglich).
-
Sobald die mobile Einheit 20E ihren
Ort bestimmt hat, kann dieselbe diese Informationen in einer Anforderung 65 weiterleiten,
wenn ein ortsbewußter
Dienst, der durch das Dienstsystem 40 bereitgestellt wird,
aufgerufen wird.
-
5 stellt
zwei allgemeine Ansätze
einer Ortsbestimmung aus Signalen, die in einer Zellularfunkinfrastruktur
vorhanden sind, dar. Erstens ist anzumerken, daß im allgemeinen sowohl die
mobile Entität
als auch das Netz die Identität
der Zelle kennen, in der sich die mobile Entität gegenwärtig befindet, wobei diese
Informationen als Teil des normalen Betriebs des Systems bereitgestellt
werden. (Obwohl in einem System, wie z. B. GMS, das Netz auch nur
den gegenwärtigen
Ort an eine Auflösung
einer Sammlung von Zellen speichern kann, die als ein „Ortsbereich" bekannt ist, ist
die tatsächliche
gegenwärtige Zell-ID
im allgemeinen aus einem Überwachen
der Signale, die zwischen der BSC 14 und der mobilen Entität ausgetauscht
werden, herleitbar).
-
Über
die gegenwärtige
Basis-Zell-ID hinaus ist es möglich,
eine genauere Position durch ein Messen von Zeitgebungs- und/oder Richtungsparametern
zwischen der mobilen Entität
und mehreren BTS 13 zu erhalten, wobei diese Messungen
entweder in dem Netz oder der mobilen Entität durchgeführt werden (siehe z. B. internationale
Anmeldungen WO 99/04582, die verschiedene Techniken zum Bewirken
einer Ortsbestimmung in dem Mobilgerät beschreibt, und WO 99/55114,
die eine Ortsbestimmung durch das Mobilnetz ansprechend auf Anforderungen
beschreibt, die durch ortsbewußte
Anwendungen an ein Mobilortszentrum – Server – des Mobilnetzes gestellt
werden).
-
Die linke Hälfte von 5 stellt den Fall dar, daß eine Ortsbestimmung
in der mobilen Entität
20F z. B. dadurch durchgeführt
wird, daß beobachtete Zeitunterschieds-Messungen (OTD-Messungen; OTD
= Observed Time Difference) bezüglich
Signalen von BTS 13 durchgeführt und ein Ort unter Verwendung
einer Kenntnis von BTS-Orten berechnet wird. Die Ortsdaten werden
nachfolgend an eine Dienstanforderung 66, die bezüglich eines
ortsbewußten
Dienstes an das Dienstsystem 40 gesendet wird, angehängt. Die
Berechnungslast auf die mobile Entität 20F könnte reduziert
und der Bedarf, daß das mobile
Teil BTS-Orte kennt, vermieden werden, indem man eine Netzentität einen
Teil der Arbeit erledigen läßt. Die
rechte Hälfte
von 5 stellt den Fall dar,
daß eine
Ortsbestimmung in dem Netz z. B. durch ein Durchführen von
Zeitgebungsfortgangsmessungen für
drei BTS 13 und ein Verwenden dieser Messungen, um einen
Ort herzuleiten (wobei diese Herleitung üblicherweise in einer Einheit
durchgeführt
wird, die der BSC 14 zugeordnet ist), durchgeführt wird.
Die resultierenden Ortsdaten werden an einen Ortsserver 67 geleitet,
von dem dieselben für autorisierte
Dienste verfügbar
gemacht werden können.
Wie für
die mobile Entität 20C wie
in 3 sendet die mobile Entität 20G aus 5, wenn dieselbe einen ortsbewußten Dienst
aufrufen möchte,
der auf dem Dienstsystem 50 verfügbar ist, eine Anforderung 69 einschließlich eines
Autorisierungsto kens und ihrer ID (möglicherweise in dem Token eingebettet)
an das Dienstsystem 40; das Dienstsystem verwendet dann
den Autorisierungstoken, um den gegenwärtigen Ort der mobilen Entität 20G aus
dem Ortsserver 67 zu erhalten.
-
Bei den obigen Beispielen, bei denen
die mobile Entität
verantwortlich für
eine Bestimmung des Ortes ist, wird dies im allgemeinen nur zu der
Zeit durchgeführt,
zu der der ortsbewußte
Dienst angefordert wird. Wenn eine Ortsbestimmung durch die Infrastruktur
durchgeführt
wird, kann dies praktisch für Systeme
sein, die nur eine eingegrenzte Anzahl von Benutzern (wie z. B.
das System, das in der linken Hälfte
von 2 dargestellt ist,
bei dem eine Anzahl von Infrarotfunkstellen 54 eine im
allgemeinen ziemlich eingeschränkte
Anzahl abdeckt) abdecken, damit eine Ortsdatensammlung jedesmal
durchgeführt wird,
wenn eine mobile Entität
durch ein IRB neu erfaßt
wird, wobei diese Daten an den Ortsserver 57 geleitet werden,
wo diese zur Verwendung, wenn sie benötigt werden, zwischengespeichert
werden. Für Systeme,
die jedoch große
Bereiche mit einer potentiell großen Anzahl mobiler Entitäten abdecken,
wie z. B. das System aus 5,
ist es wirksamer, eine Ortsbestimmung so und dann zu bewirken, wenn
ein wahrgenommener Bedarf danach besteht; so kann eine Ortsbestimmung
durch den Ortsserver 67 ansprechend auf die Dienstanforderung 68 von
der mobilen Entität 20G ausgelöst werden
oder die mobile Entität
kann unmittelbar vor dem Stellen der Anforderung 68 die
BSC 14 direkt auslösen,
um eine Ortsbestimmung zu bewirken und das Ergebnis zu dem Ortsserver 67 zu
führen.
-
Weiter Bezug nehmend auf die Ortsserver 57, 67 können, während eine
Zugriffsautorisierung durch ortsbewußte Dienste beschrieben wurde,
um durch Autorisierungstoken stattzufinden, die durch die betreffenden
mobilen Entitäten
geliefert werden, andere Autorisierungstechniken verwendet werden. Insbesondere
kann ein ortsbewußter
Dienst zuvor mit dem Ortsserver bezüglich bestimmter mobiler Entitäten autorisiert
werden; in diesem Fall muß jede Anforderung
von dem Dienst nach Ortsdaten nur feststellen, daß die Anforderung
von einem Dienst kommt, der bezüglich
der mobilen Entität
autorisiert ist, für
die die Ortsdaten angefordert werden.
-
Wie bereits angezeigt wurde, stellen
die 2–5 nur einige Beispiele dessen
dar, wie eine Ortsbestimmung erzielt werden kann, wobei es viele andere
mögliche
Kombinationen einer verwendeten Technologie und dessen gibt, wo
in dem System die Ortsbestimmungsmessungen gemacht werden und der
Ort berechnet, gespeichert und verwendet wird. So kann sich der
ortsbewußte
Dienst in der mobilen Entität,
deren Ort von Interesse ist, in einem vernetzten Dienstsystem 40 (wie
dargestellt) oder sogar in einer weiteren mobilen Entität befinden.
Ferner kann, während
bei den Beispielen der 2–5 ein Aufrufen des ortsbewußten Dienstes
durch die mobile Entität geschah,
deren Ort von Interesse ist, die Natur des ortsbewußten Dienstes
derart sein, daß er
durch eine andere Partei aufgerufen wird (potentiell einschließlich des
PLMN selbst). In diesem Fall ist, es sei denn, die aufrufende Partei
kennt bereits den Ort der mobilen Entität und kann diese Informationen
an den ortsbewußten
Dienst weiterleiten (was z. B. die Situation sein kann, bei der
das PLMN den Dienst aufruft), es der ortsbewußte Dienst, der für ein Erhalten
der erforderlichen Ortsdaten verantwortlich ist, und zwar entweder
durch ein Senden einer Anforderung an die mobile Entität selbst
oder durch ein Anfordern der Daten von einem Ortsserver. Es sei
denn, der Ortsserver weist bereits die benötigten Informationen in einem
Cachespeicher auf, fährt
der Server fort, um die Daten entweder durch ein Abfragen der mobilen Entität oder durch
ein Auslösen
von Infrastrukturelementen, um das Mobilgerät zu lokalisieren, zu erhalten.
Wenn z. B. ein ortsbewußter
Dienst, der auf dem Dienstsystem 40 in 5 läuft,
den Ort des Mobilgeräts 20G finden
muß, könnte derselbe
angeordnet sein, um dies durch ein Anfordern dieser Informationen
von dem Ortsserver 67 zu tun, der wiederum die Ortsdaten
von der relevanten BSC anfordert, wobei letz tere dann die notwendige
Bestimmung unter Verwendung von Messungen von BTS 13 durchführt.
-
Obwohl in dem Vorangegangenen die
Bereitstellung von Ortsdaten durch die Mobilfunkinfrastruktur zu
der mobilen Entität
als ein Dienst behandelt wurde, der über einen Trägerkanal
mit Datenfähigkeit bewirkt
wird, ist zu erwarten, daß,
da Ortsdaten als ein grundlegendes Element von Mobilfunkinfrastrukturdiensten
betrachtet werden, eine Bereitstellung in den relevanten Mobilfunkstandards
für Ortsdaten
gemacht wird, die über
einen Signalisierungskanal an die mobile Entität geleitet werden sollen.
-
Die
US
6,011,973 offenbart ein Mobiltelephon, das angeordnet ist,
um gemäß seiner
Position aktiviert oder deaktiviert zu werden, wobei Daten über die
Erlaubnis des Betriebs des Mobiltelephons in verschiedenen geographischen
Positionen entweder in dem Telephon oder anderswo gespeichert sind.
Die WO-A-97/41654 beschreibt das positionsbasierte Auslösen von
Informationsdiensten an registrierte Kunden. Die
US 5,568,153 offenbart ein System,
bei dem die Parameter eines Dienstes auf der Basis der aktuellen
Position des Benutzers bestimmt werden, wobei dies durchgeführt wird,
nachdem die Dienstlieferung angefordert wurde. Die WO-A-99/67904
beschreibt das Bezahlen für
einen elektronischen Zugriffsschlüssel zu einem Ereignis, wobei
der Schlüssel
in einem Handapparat gespeichert ist, bis er angefordert wird. Die
US 6,236,981 offenbart eine
Anordnung, bei der Token in einem Carnet gespeichert sind und durch Übertragung
an einen Online-Verkäufer
ausgegeben werden. Die WO-A-98/19479 beschreibt ein Mobilkommunikationssystem,
bei dem Informationen über
die geographische Position einer Basisstation auf einem Zellrundsendekanal
rundgesendet werden; diese Positionsinformationen werden dann durch
eine Mobilstation in eine Dienstanforderung aufgenommen, die an einen
Dienstanbieter gesendet wird, um es Letzterem zu ermöglichen,
seine Antwort gemäß der Position
der Mobilstation kundenspezifisch einzustellen.
-
Es ist eine Aufgabe der vorliegenden
Erfindung, ein verbessertes Verfahren und System für eine Dienstlieferung
an mobile Benutzer zu schaffen.
-
Zusammenfassung
der Erfindung
-
Gemäß einem Aspekt der vorliegenden
Erfindung ist ein Dienstlieferverfahren geschaffen, bei dem die
Position eines Benutzers, an den ein Dienst geliefert werden soll,
durch die Position einer mobilen Entität angezeigt wird, die dem Benutzer
zugeordnet ist, dadurch gekennzeichnet, daß das Verfahren die folgenden
Schritte umfaßt:
- (a) Qualifizieren eines Benutzers als autorisiert, um
von einem Fall eines bestimmten Dienstes zu profitieren, und Speichern
von:
- – Positionsdaten,
die zumindest eine Position anzeigen, wo die Dienstlieferung ausgelöst werden soll,
und
- – einem
Dienstfallelement, das den Benutzer und den Dienstfall zuordnet,
für den
der Benutzer qualifiziert ist;
- (b) nacheinanderfolgendes Erfassen einer Positionsübereinstimmung
zwischen der Position des Benutzers, wie sie durch die Position
einer mobilen Entität
angezeigt wird, die dem Benutzer zugeordnet ist, und einer Position,
die durch die Positionsdaten angezeigt wird, und daraufhin Auslösen der
Lieferung des Dienstfalles, der durch das Dienstfallelement dem
Benutzer zugeordnet ist, an den Benutzer; und
- (c) Modifizieren der Positionsdaten als Teil der Lieferung des
Dienstfalles, der in Schritt (b) ausgelöst wurde.
-
Die vorliegende Erfindung zieht auch
ein Dienstliefersystem zum Bewirken der Dienstlieferung gemäß dem vorhergehenden
Verfahren in Betracht.
-
Kurze Beschreibung
der Zeichnungen
-
Ein Dienstlieferverfahren und ein
Dienstliefersystem, die beide die vorliegende Erfindung umfassen,
werden nun durch ein nicht beschränkendes Beispiel mit Bezugnahme
auf die beiliegenden schematischen Zeichnungen beschrieben:
-
1 ist
ein Diagramm einer bekannten Kommunikationsinfrastruktur, die zum Übertragen von
Sprache und Daten zu/von einer mobilen Entität verwendbar ist;
-
2 ist
ein Diagramm, das einen bekannten Ansatz zur Bestimmung des Ortes
einer mobilen Entität
darstellt, wobei dieser Ansatz ein Versehen der Entität mit einem
Trägheitspositionierungssystem beinhaltet;
-
3 ist
ein Diagramm, das einen weiteren bekannten Ansatz zur Bestimmung
des Ortes einer mobilen Entität
darstellt, wobei dieser Ansatz auf einer Nähe der mobilen Entität zu lokalen
Funkstellen mit fester Position basiert;
-
4 ist
ein Diagramm, das einen weiteren bekannten Ansatz zur Bestimmung
des Ortes einer mobilen Entität
darstellt, wobei dieser Ansatz die Verwendung von GPS-Satelliten
beinhaltet;
-
5 ist
ein Diagramm, das noch einen weiteren Ansatz zur Bestimmung des
Ortes einer mobilen Entität
darstellt, wobei dieser Ansatz auf der Verwendung von Signalen basiert,
die in einem Zellularmobilfunkkommunikationssystem vorhanden sind;
-
6 ist
ein Diagramm, das die Hauptlogikkomponenten eines Dienstlieferverfahrens
und Systems, die die vorliegende Erfindung umfassen, darstellt;
-
7 ist
ein Diagramm, das ein erstes spezifisches Ausführungsbeispiel der Erfindung
darstellt;
-
8 ist
ein Diagramm, das ein zweites spezifisches Ausführungsbeispiel darstellt;
-
9 ist
ein Diagramm, das ein drittes spezifisches Ausführungsbeispiel darstellt; und
-
10 ist
ein Diagramm, das ein viertes spezifisches Ausführungsbeispiel darstellt.
-
Bester Modus
zum Ausführen
der Erfindung
-
Dienstlieferverfahren und Systeme,
die die Erfindung umfassen, werden nun mit Bezugnahme auf 6 bis 10 beschrieben. Die spezifischen Ausführungsbeispiele
von 7 bis 10 stellen einen Benutzer
mit einem Zellular-Mobilgerät
und einer mobilen Infrastruktur mit einem Positionsserver zum Liefern
von Positionsdaten über
mobile Benutzer dar; die in 7 bis 9 gezeigten spezifischen
Ausführungsbeispiele
stellen auch ein Dienstsystem 40 dar, das mit dem öffentlichen
Internet 39 verbunden ist. Es ist klar, daß die vorliegende
Erfindung nicht auf die Einzelheiten der mobilen Entität, der Positionsentdeckungseinrichtung
oder Kommunikationsinfrastruktur, die in den Figuren gezeigt sind
und oben allgemein mit Bezug auf 1 bis 5 erörtert sind, begrenzt ist, sondern
gleichermaßen
für den
Betriebszusammenhang der beschriebenen Ausführungsbeispiele der Erfindung
gelten. Somit, obwohl das Dienstsystem 40 in 7 bis 9 als mit dem öffentlichen Internet verbunden
gezeigt ist, könnte
es auch mit einem GPRS-Netzwerk 17 oder einem anderen festen
Datennetzwerk verbunden sein, das direkt oder indirekt mit dem Netzwerk 17 oder
dem Netzwerk 39 eine Schnittstelle bildet. Ferner kann
die Kommunikation zwischen der mobilen Entität des Benutzers und einem Dienstsystem über eine
Kommunikationsinfrastruktur stattfinden, die keinen Zellular-Funk
verwendet, beispielsweise könnte
ein drahtloses Nahbereichssystem verwendet werden.
-
Zunächst wird das allgemeine Ausführungsbeispiel
des in 6 gezeigten Dienstlieferverfahrens
betrachtet. In 6 ist
eine Benutzerentität 70 dargestellt,
die einen Benutzer und ein Mobilgerät umfaßt, durch die die Position
des Benutzers sichergestellt werden kann (beispielsweise eine Mobilentität 20,
wie sie in 2 bis 5 gezeigt ist). Der Zweckmäßigkeit
halber wird der Begriff „Benutzerentität" sowohl für Aktionen/Ereignisse,
die das Gerät
selbst betreffen, als auch für
Aktionen/Ereignisse, die den Benutzer betreffen, der durch das Mobilgerät agiert, verwendet;
das Bezugszeichen 70 wird sowohl für die Benutzerentität als auch
für den
Benutzer allein verwendet.
- [1]- Wenn der Benutzer 70 einen
Dienst abonniert oder ein Produkt kauft, dem ein Dienst zugeordnet ist,
bewirkt der Dienstverkäufer,
der durch einen Dienstfirmenclienten 71 wirkt, daß ein ausführbarer
Dienstfall 76 durch eine Dienstfirma 72 erzeugt wird,
die dem Dienst zugeordnet ist. Der Dienstfall ist ein Ausführungsbeispiel
des Verhaltens, das dem gekauften Dienst zugeordnet ist. Der Dienstfall
ist einem Satz von gut definierten Positionen zugeordnet, die für den Dienst
von Interesse sind. Diese Positionen sind in Positionsbeschreibern 74 spezifiziert,
die entweder Positionen oder polygonale Bereiche spezifizieren,
entweder als einen Satz von x-, y-Koordinaten, oder einen Satz von Darstellungen
hoher semantischer Ebene, wie z. B, „Lloyds Bank, Bristol", die auf physikalische
Positio nen abgebildet werden können.
Jeder Benutzer hat ein Dienstdepot 75, um den aktuellen
Satz von Dienstfällen 76 zu
halten, die für
den Kontext des Benutzers aktiv sind. Die Positionsbeschreiber 74,
die den Dienstfällen
des Benutzers zugeordnet sind, werden in einem Positionsbeschreiberdepot 73 gehalten.
- [2]- Der neu erzeugte Dienstfall 76 und ein Anfangssatz
von einem oder mehreren Positionsbeschreibern 74, die an
den Dienst angelegt werden sollen, werden jeweils zu dem Dienstdepot 75 und dem
Positionsbeschreiberdepot 73 des Benutzers heruntergeladen.
Der Dienst bleibt ruhend, bis die Position der Benutzerentität 70 mit
einer der Positionen übereinstimmt,
die durch die Positionsbeschreiber definiert sind, die für den Dienst
definiert sind.
- [3]- Die physikalische Position der Benutzerentität 70 wird
durch eine Positionsquelle 77 in jeder geeigneten Weise
erhalten und auf regelmäßiger Basis
zu einer Positionsvergleichermaschine 78 weitergeleitet.
- [4]- Die Positionsvergleichermaschine 78 vergleicht
die aktuelle Position der Entität 70 mit
dem Satz von aktiven Positionsbeschreibern 74. Falls eine Übereinstimmung
gefunden wird, wird ein Auslöser
an eine Dienstausführungsumgebung 79 gesendet,
wobei dieser Auslöser
den Dienstfall identifiziert, der ausgeführt werden soll (beispielsweise
durch Kombination von Benutzer-ID und Position, oder durch einen
Dienstfallidentifizierer, der mit dem übereinstimmenden Positionsbeschreiber
gehalten wird).
- [5]- Die Dienstausführungsumgebung 79 lädt den geeigneten
Dienstfall 76 und führt
denselben aus, und leitet denselben an die aktuelle Position weiter,
falls dies erforderlich ist. Der Dienst kann einer sein, der, sobald
er ausgelöst
wird, bis zum Abschluß läuft, unab hängig von
nachfolgenden Änderungen
der Position, oder einer, der nur funktioniert, während die
Position mit einem Positionsbeschreiber übereinstimmt. In diesem letzteren
Fall werden in Intervallen Positionsabtastwerte genommen, und der
Dienst läuft
nur so lange weiter, wie die aktuelle Position mit dem Positionsbeschreiber
des Dienstes übereinstimmt.
- [6]- Der Dienst kann aktiviert werden, um die Frequenz von Positionsaktualisierungen,
die er erfordert, zu spezifizieren und auch den Satz von Positionsbeschreibern 74 zu
modifizieren, die angewendet werden sollen.
-
Die physikalische Position der funktionalen Entitäten 71, 72, 73, 75, 77, 78 und 79 hängt von
der Architektur der Netzwerkinfrastruktur ab, die verwendet wird,
um die Entitäten
und die Fähigkeiten
des Mobilgeräts
der Benutzerentität 70 miteinander
zu kommunizieren. Obwohl die Dienstfirma 72 im allgemeinen
in der Netzwerkinfrastruktur positioniert wird, könnte somit
jede der anderen Entitäten
entweder in dem Mobilgerät
oder in dem Netzwerk positioniert sein.
-
Ein mögliches Dienstlieferszenario
ist wie folgt. Ein Kunde kauft ein Flugticket einer Fluglinie. Ein
Dienstfall 76 wird durch die Fluglinie konkretisiert, um
die spezifische Kauftransaktion zu identifizieren, so daß das Verhalten
des Dienstfalles von den Charakteristika der Transaktion abhängig gemacht
werden kann. Eine Beschreibung des/der Positionsauslöspunkts/e
des Dienstes wird entweder in dem Mobilgerät (z. B. ein Zellulartelefongerät) des Benutzers oder
in der Zellular-Funk-Infrastruktur gespeichert. Man nehme an, daß der Flughafen
ein Auslöserpunkt ist.
Wenn der Kunde am Flughafen ankommt, stimmt die Position des Mobilgeräts, wie
sie durch die Zellular-Funk-Infrastruktur bestimmt wird, mit dem
Auslöserpunkt
des Dienstes überein.
Der Dienstfall ist nun aktiviert, kann den Kunden mit Namen begrüßen, ihn höflich fragen,
einzuchecken, den Kunden in die Airlinelounge einladen und dorthin
verweisen, falls das Kundenticket vom geeignete Typ ist, und schließlich den
Kunden erinnern, die Lounge zu verlassen, wenn der Flug zum Einsteigen
bereit ist.
-
Bei dem Ausführungsbeispiel von 6 wird ein vollausführbarer
Dienstfall durch die Dienstfirma erzeugt. Dies ist insbesondere
nützlich
wo die Dienstausführungsumgebung
entweder das Mobilgerät oder
ein anderes System ist, das keine großen Ressourcen oder ständigen Netzwerkzugriff
hat. Ein alternativer Lösungsansatz
ist es, Fallanpassungsdaten zu speichern, die verwendet werden können, um einen
verallgemeinerten Dienstcode, der der Dienstausführungsumgebung verfügbar ist,
kundenspezifisch anzupassen, entweder weil der Letztere Ressourcen
hat, um einen solchen Code zu speichern oder über eine Netzwerkverbindung
auf den Code zugreifen kann.
-
Allgemein gesagt erzeugt somit die
Dienstfirma, sobald erfüllt
ist, daß sich
der Benutzer für
den Dienst qualifiziert hat (beispielsweise indem er gezahlt hat
oder geeignete Attribute hat) ein Dienstfallelement, das den Benutzer
einem Dienstfall zuordnet, für
den der Benutzer qualifiziert ist. Das Dienstfallelement kann eine
voll ausführbare
Codeversion des Dienstes sein, wie es oben mit Bezug auf 6 beschrieben ist, Anpassungsdaten,
die einen allgemeinen Dienst für
den Benutzer anpassen, oder eben nur ein Indikator, daß der Benutzer
für die
Vorteile eines Dienstfalles berechtigt ist, der ansonsten keiner Anpassung
unterworfen wird.
-
Eine Anzahl unterschiedlicher Möglichkeiten kann
von dem Dienstfallelement verwendet werden, um den Benutzer und
den Dienstfall, für
den der Benutzer qualifiziert wurde, zuzuordnen. Eine Möglichkeit
ist es, daß das
Dienstfallelement einen Identifizierer des Benutzers enthält, wobei
das Fallelement entweder selbst diesen ausführbaren Fall enthält oder
eine Referenz zu dem Letzteren enthält; in diesem Fall führt der
Positionsauslöserprozeß dazu, daß der Benutzeri dentifizierer
erzeugt wird, zum Übereinstimmen
mit dem Dienstfallelement (es ist anzumerken, falls mehrere Dienstfallelemente
für den
gleichen Benutzer gespeichert werden, können zusätzliche Informationen, wie
z. B. Auslöseposition erforderlich
sein, um zwischen den Dienstfallelementen zu unterscheiden). Eine
weitere Möglichkeit
ist es, einen Dienstfallidentifizierer in dem Dienstfallelement
aufzunehmen, wobei dieser Identifizierer auch dem Benutzer zugeordnet
ist (beispielsweise, indem er der Benutzerentität bekannt ist) und durch den
Positionsauslöserprozeß zum Übereinstimmen
mit dem Dienstfallelement erzeugt wird. Eine dritte Möglichkeit
zum Zuordnen des Dienstfallelementes zu einem Benutzer mit einem
speziellen Dienstfall ist es, das Dienstfallelement in der Benutzerentität oder einer anderen
Benutzerzugewiesenen Entität
zu speichern.
-
Bezüglich des Positionsauslöseprozesses
ist klar, daß dieser
auf viele Arten implementiert werden kann. Beispielsweise können die
Positionsbeschreiber in einem Dienstsystem gespeichert werden, das die
Dienstfallumgebung enthält,
wobei die aktuelle Position des Benutzers durch einen Positionsserver (wie
z. B. den Server 57 von 3 oder
den Server 67 von PLMN 10 von 5) oder durch die Benutzerentität 70 selbst
an das Dienstsystem geliefert wird (wobei die Entität 70 ihre
Position durch eines der Verfahren, die beispielsweise in 2 bis 5 dargestellt sind, entdeckt hat). Alternativ
könnten
die Positionsbeschreiber in einem Positionsserver 57 oder 67 gespeichert
sein, wobei die Positionsübereinstimmung
ebenfalls in dem Server bewirkt wird. Eine weitere Möglichkeit
ist es, die Positionsbeschreiber in der Benutzerentität 70 selbst
zu speichern, wobei die Letztere ihre Position durch ein Verfahren
von 2 bis 5 entdeckt und den Positionsübereinstimmungsprozesses
selbst bewirkt.
-
Spezifische beispielhafte Ausführungsbeispiele
werden nun mit Bezugnahme auf 7 bis 10 beschrieben.
-
Bei dem Ausführungsbeispiel von 7 hat die Dienstfirma ein
Dienstfallelement (SIE = service instance element) 80 in
eine Datenbank 75 eines Dienstliefersystems 40 und
einen entsprechenden Positionsbeschreiber 74 in ein Depot 73 geladen,
das dem Positionsserver 67 von PLMN 10 zugeordnet
ist. Das SIE 80 umfaßt
bei diesem Beispiel einen Benutzeridentifizierer (Benutzer-ID) und
benutzerspezifische Anpassungsdaten. Der Positionsbeschreiber 74 umfaßt auch
den Benutzer-ID, und der Positionsserver 67 des PLMN versteht,
welcher PLMN-Teilnehmer durch diesen Benutzer-ID identifiziert wird
(üblicherweise
kann der Benutzer-ID die IMSI sein, die dem Benutzer zugeordnet
ist). Das Dienstsystem 40 umfaßt außer der Datenbank 75 eine
Programmdatenbank 81, die den allgemeinen Programmcode
für die
Dienste, die durch das System geliefert werden sollen, eine Dienstausführungsumgebung 78,
einen Dienstlader 82 zum Laden des korrekten Dienstprogramms
und Anpassungsdaten zum Liefern eines angeforderten Dienstfalls
und eine Schnittstelle 41 zum Bilden einer Schnittstelle
des Dienstsystems mit einer Kommunikationsinfrastruktur (hier als
Internet 39 gezeigt) umfaßt.
-
Das Mobilgerät des Benutzers ist eine Zellular-Funkmobilentität 20,
wie diejenige, die mit Bezug auf 1 beschrieben
wurde, und ist in der Lage, über
einen Trägerdienst
mit Datenfähigkeit
des PLMN 10 und das Internet 39 mit dem Dienstsystem 40 zu
kommunizieren. Wenn die Mobilentität in einem eingeschalteten
Zustand ist, ist der Positionsserver 67 des PLMN 10 in
der Lage, die Position der mobilen Entität zu bestimmen.
-
Wenn die mobile Entität 20 durch
den Positionsserver 77 beim Betrieb als an einer Position
erfaßt
wird, die mit einem Positionsbeschreiber 74 übereinstimmt,
der dem Benutzer zugeordnet ist, wird ein Positionsübereinstimmungsauslöser (einschließlich Benutzer-ID
und möglicherweise
auch Benutzerposition) von dem Positionsserver 67 zu dem
Dienstlader 82 des Dienstsystems 40 weitergeleitet
(siehe Pfeil 85). Der Dienstlader verwendet den Benutzer-ID
(und möglicher weise
auch die Benutzerposition) zum Identifizieren des entsprechenden
SIE 80. Das SIE 80 identifiziert das Dienstprogramm,
das ausgeführt
werden soll, und der Dienstlader 82 bewirkt, daß das relevante
Programm in die Dienstausführungsumgebung
geladen wird, zusammen mit den Anpassungsdaten, die in dem SIE 80 enthalten
sind, um den Dienstfall, für
den der Benutzer vorher autorisiert wurde, zu erzeugen und laufen
zu lassen. Die Ausführung
des Dienstfalles umfaßt
normalerweise (aber nicht notwendigerweise) die Kommunikation zwischen
dem Dienstsystem und der mobilen Entität 20 des Benutzers,
beispielsweise unter Verwendung eines Trägerdienstes mit Datenfähigkeit
des PLMN 10 (siehe Pfeil 86).
-
Das Ausführungsbeispiel von 8 ist ähnlich zu demjenigen von 7, außer daß nun die Positionsbeschreiber 74 in
der mobilen Entität 20 gespeichert
sind, jeder mit einem zugeordneten Dienstfallidentifizierer (SI-ID),
und die SIEs 80, die in der Datenbank 75 gespeichert
sind, umfassen jeweils einen entsprechenden SI-ID. Eine Positionsübereinstimmung
zwischen den Positionsbeschreibern und der aktuellen Position des
Benutzers (wie sie durch den Positionsserver 67 für die Entität 20 identifiziert wird
oder auf eine andere Weise entdeckt wird) wird in der mobilen Entität 20 durchgeführt. Wenn
eine Übereinstimmung
erfaßt
wird, wird der SI-ID, der der übereinstimmenden
Position zugeordnet ist, an den Dienstlader 82 weitergeleitet
(siehe Pfeil 87), der das entsprechende SIE 80 in
der Datenbank 75 sucht und dann das Ablaufen des geeigneten
Dienstfalles überwacht.
Falls es erforderlich ist, kann das SIE 80 sowohl den Benutzer-ID
als auch die Positionen, wo der Dienstfall ausgelöst werden
darf, umfassen; der Dienstlader kann dann angeordnet sein, um die
Identität
des Benutzers und den Ursprung des Positionsstandorts des Benutzers
zu bestätigen
(und möglicherweise
sogar die Authentifizierung desselben zu erfordern) (der Dienstfall
kann beispielsweise erfordern, daß nur Positionsstandorte durch
den Positionsserver 67 vertrauenswürdig sind, in diesem Fall kann
es erforder lich sein, daß die
mobile Entität 20 digital
unterzeichnete Positionsdaten von dem Server 67 liefert).
-
Bei dem Ausführungsbeispiel von 9 werden die Positionsbeschreiber 74 erneut
in der mobilen Entität 20 gespeichert,
wo eine Positionsübereinstimmung
bewirkt wird. Nun ist das SIE 80 jedoch auch in der mobilen
Entität 20 gespeichert
und nimmt die Form eines Diensttokens an, das verwendet werden kann,
um eine Dienstfallieferung von einem Dienstsystem 40 zu
beanspruchen. Das Diensttoken ist dem Benutzer zugeordnet, da dasselbe
in der mobilen Entität 20 gespeichert
ist, und umfaßt
Daten, die den Dienst identifizieren, der durch das Dienstsystem 40 geliefert
werden soll, und alle Dienstanpassungsdaten; vorteilhafterweise
umfaßt
das Diensttoken auch Adreß-
(und Paßwort-)
Einzelheiten zum Kontaktieren des Dienstsystems. Wenn beim Betrieb eine
Positionsübereinstimmung
erfaßt
wird, leitet die mobile Entität
das Diensttoken über
einen Trägerdienst
mit Datenfähigkeit
des PLMN 10 und das Internet 39 an das Dienstsystem
weiter. An dem Dienstsystem wird das Token zu einem Authentifizierungs- und
Dienstausführungsteilsystem 83 weitergeleitet, wo
es verwendet wird, um den angeforderten Dienstfall einzuleiten und
laufen zu lassen.
-
Vorzugsweise umfaßt das Diensttoken die Identität des Benutzers
und ist durch die Dienstfirma digital unterzeichnet (wobei ein entsprechendes
Zertifikat in dem Token enthalten ist). In diesem Fall kann das
Teilsystem 83 sowohl:
- – Prüfen, daß das Diensttoken
von einer Dienstfirma stammt, für
die es eine Dienstlieferung liefern möchte (diese Prüfung umfaßt das Prüfen der Identität der unterzeichnenden
Partei mit der Zertifikationsautorität auf Standardweise); und
- – Prüfen, daß die Partei,
die das Token sendet, gleich ist wie die Partei, die in dem Token
identifiziert ist (dessen Authentizität durch die Digitalsignatur
garan tiert ist). Das Prüfen
der Identität
der sendenden Partei wird durchgeführt unter Verwendung eines
Herausforderung-/Antwortmechanismus, durch den das Dienstsystem 40 ein
Datenelement an die mobile Entität
sendet und dieselbe fragt, dasselbe unterzeichnet/verschlüsselt unter
dem privaten Schlüssel
zurückzusenden (wobei
angenommen wird, daß die
mobile Entität mit
einem Öffentlicher
Schlüssel-/Privater
Schlüssel-Paar
versehen ist, das dem Benutzer zugeordnet ist). Dies ermöglicht es
dem Dienstsystem, die Identität
des Benutzers zu prüfen
(mit der Zertifikationsautorität
des Benutzers) und somit zu prüfen,
ob der Benutzer die gleiche Partei ist, wie es in dem Token identifiziert
wurde.
-
Da der Grundherausforderung-/Antwortmechanismus
normalerweise zwischen dem System 40 und der mobilen Entität 20 ohne
Beteiligung des Benutzers durchgeführt wird, schützt der
Mechanismus selbstverständlich
nicht dagegen, daß die
mobile Entität
gestohlen wurde. Als zusätzliche
Vorsichtsmaßnahme
umfaßt
der Benutzerauthentifizierungsprozeß daher vorzugsweise, daß der Benutzer
aufgefordert wird, eine PIN-Nummer
einzugeben, wobei diese letztere dem System 40 bekannt
ist (wie z. B. indem dieselbe in dem Token aufgenommen wurde, möglicherweise
verschlüsselt
auf eine Weise, die es nur dem Dienstsystem 40 erlaubt,
dieselbe zu entschlüsseln – beispielsweise
verschlüsselt
die Dienstfirma die PIN unter Verwendung des öffentlichen Schlüssels des
Dienstsystems 40).
-
Es ist klar, daß der gleiche Authentifizierungsprozeß genauso
als Ganzes oder teilweise in dem Fall angelegt werden kann, wo das
Diensttoken durch einen voll ausführbaren Dienstfallcode ersetzt wird.
-
Bei dem Ausführungsbeispiel von 10 sind die Positionsbeschreiber 74 erneut
in der mobilen Entität 20 gespeichert,
wo eine Positionsübereinstimmung
bewirkt wird. Nun umfaßt
das SIE 80 jedoch den vollen ausführbaren Dienstfall 76,
der in der mobilen Entität 20 gespeichert
ist in der mobilen Entität
ausgeführt
werden soll, wenn eine Positionsübereinstimmung
erfaßt
wird. Es ist keine externe Interaktion mit einem vorher autorisierten
Dienstelement erforderlich. Selbstverständlich können externe Dienstinteraktionen
während
dem Verlauf der Dienstausführung
bewirkt werden (obwohl dies in 10 nicht
gezeigt ist). Wie es bereits angemerkt wurde, kann die aktuelle
Position der mobilen Entität
durch andere Einrichtungen als den Positionsserver 67 von PLMN 10 geliefert
werden, beispielsweise durch ein eingebautes GPS-System oder von
lokalen Positionsfunkstellen, und in diesem Fall ist eine Weites-Netz-Verbindbarkeit für die mobile
Entität 20 nicht erforderlich.
-
Varianten
-
Es ist klar, daß bezüglich der oben beschriebenen
Ausführungsbeispiele
viele Variantenmöglich sind,
wobei Merkmale, die in Bezug auf ein Ausführungsbeispiel beschrieben
wurden, auch für
die Verwendung mit einem anderen Ausführungsbeispiel angepaßt werden
können.
Somit können
beispielsweise die Authentifizierungsmerkmale (digitale Unterzeichnung
des SIE 80 zum Prüfen
des Ursprungs, Benutzerauthentifizierung durch einen Herausforderung-/Antwortmechanismus,
Verwendung einer PIN), die oben mit Bezugnahme auf das Ausführungsbeispiel
von 9 beschrieben wurden,
auch mit anderen Ausführungsbeispielen
verwendet werden. Wo beispielsweise das SIE durch die Dienstfirma
an ein Gerät
oder System unter anderer Steuerung verteilt wird, ist es im allgemeinen
gute Praxis, daß das
SIE durch die Dienstfirma digital unterzeichnet wird, um es dem
Enddienstliefersystem (System 40 in 7 bis 9)
ermöglicht
wird, den Ursprung des SIE 80 zu prüfen. Erneut ist das Prüfen der
Identität
des Benutzers, der die Dienstausführung anfordert, vernünf tig, unter
Verwendung eines Herausforderung-/Antwortmechanismus und/oder einer
PIN-Eingabe.
-
Wie es oben angemerkt wurde, muß die mobile
Entität 20 keine
Weites-Netz-Bereichsverbindbarkeit aufweisen. Beispielsweise könnte eine
Kommunikation mit dem Dienstsystem 40 durch eine drahtlose
Nahbereichsverbindung sein (beispielsweise eine Infrarotverbindung
oder ein Bluetooth-Funkverbindung).
In der Tat, wie es bereits mit Bezugnahme auf das Ausführungsbeispiel
von 10 angezeigt wurde,
muß die
mobile Entität 20 keine
externe Kommunikationsfähigkeit
aufweisen, außer
zum Ermöglichen
der Positionsbestimmung.
-
Die Positionsbeschreiber und Dienstfallelemente
können
durch den Benutzer, durch den Dienst, der geliefert wird oder in
jeder anderen möglichen Verteilung
gespeichert werden. Wo beispielsweise unterschiedliche Dienstsysteme 40 für unterschiedliche
Dienste von den Ausführungsbeispielen
von 7 und 8 verwendet werden, wird
die Datenbank 75 jedes Dienstsystems 40 SIEs 80 speichern,
die sich auf unterschiedliche Benutzer aber den gleichen Dienst
beziehen.
-
Ein Dienstfallelement kann angeordnet
werden, um eine spezielle Anzahl von Malen zu spezifizieren (einschließlich nur
einmal), die der zugeordnete Dienstfall ablaufen kann, wobei jedes
Ablaufen des Dienstfalles diesen Zählwert dekrementiert (oder
einen Zählwert
der Anzahl von Malen inkrementiert, die der Dienstfall abgelaufen
ist).