-
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 für
mobile Benutzer (insbesondere, wenn auch nicht ausschließlich Zellularfunkinfrastrukturen)
geeignet 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. Auf 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
Autorisierungstokens 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
gelie fert 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 letztere 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/52316
beschreibt eine Anordnung, bei der, wenn ein Mobiltelefon einen „lokalisierten
Dienstbereich" betritt
(LSA), derselbe eine Mitteilung an einen Dienstserver sendet, der
den LSA und sich selbst identifiziert. Der Dienstserver bestimmt
die Dienste, für
die der Benutzer in dem LSA qualifiziert ist und benachrichtigt
die relevanten Anwendungsserver, um die betreffenden Dienste zu
liefern. Die WO-A-98/58506 offenbart eine allgemeine Mobilkommunikationseinheit,
zu der anwendungsspezifische Grundfunktionalität und andere Softwareanwendungen
für eine
Ausführung
in der Einheit heruntergeladen werden können; die Version der Software, die
heruntergeladen wird, hängt
von dem Ort der Kommunikationseinheit ab, wie er durch die Basisstation
oder ein anderes Netzwerkelement bestimmt wird, mit dem die Einheit
kommuniziert.
-
Es
ist eine Aufgabe der vorliegenden Erfindung, ein verbessertes Verfahren
und System für
die Lieferung von Diensten an mobile Benutzer zu liefern.
-
Zusammenfassung
der Erfindung
-
Gemäß einem
Aspekt der vorliegenden Erfindung wird ein Dienstlieferverfahren
geliefert, das folgende Schritte umfasst:
- a) – Durchführen einer
Transaktion eines Benutzers, der einen Dienst oder ein Produkt kauft,
was den Benutzer als autorisiert qualifiziert, um von einem bestimmten
positionsausgelösten
Dienst zu profitieren, und daraufhin Speichern von Positionsdaten
in einem Positionsdepot, die zumindest eine Position anzeigen, wo
die Dienstlieferung ausgelöst
werden soll, und
- b) – nachfolgend
Erfassen einer Positionsübereinstimmung
zwischen der Position des Benutzers, wie sie durch die Position
einer mobilen Identität, die
dem Benutzer zugeordnet ist, angezeigt wird, und einer Position,
die durch die Positionsdaten angezeigt wird, und daraufhin Einleiten
der Lieferung des Dienstes an den Nutzer, für den sich der Benutzer qualifiziert
hat;
dadurch gekennzeichnet, dass Schritt a) auf die Benutzerqualifikation
hin das Erzeugen eines benutzerzugeordneten Falls eines ausführbaren
Programmcodes in einer Dienstfirma und das Speichern desselben in
einem Dienstdepot umfasst, kundenspezifisch für die spezifische Transaktion
einge stellt, zum Implementieren des Dienstes, für den sich der Benutzer qualifiziert
hat, wobei dieser benutzerzugeordnete Programmcode für den nachfolgenden
Schritt b) ausgeführt
wird, um diesen Dienst zu liefern.
-
Gemäß einem
weiteren Aspekt der vorliegenden Erfindung wird ein Dienstlieferverfahren
geliefert, das folgende Merkmale umfasst:
- – ein Positionsdepot;
- – ein
Dienstdepot;
- – eine
Dienstfirma;
- – ein
Qualifikationsteilsystem zum Durchführen einer Transaktion eines
Benutzers, der einen Dienst oder ein Produkt kauft, was den Benutzer
qualifiziert, von einem speziellen positionsausgelösten Dienst
zu profitieren, wobei das Qualifikationsteilsystem wirksam ist,
auf das Bestimmen hin, dass der Benutzer so qualifiziert ist, sowohl
Positionsdaten in dem Positionsdepot zu speichern, die zumindest
eine Position anzeigen, wo die Dienstlieferung ausgelöst werden
soll, und auch einen benutzerzugeordneten Fall eines ausführbaren
Programmcodes in der Dienstfirma zu erzeugen und in dem Dienstdepot
zu speichern, der für
die spezifische Transaktion kundenspezifisch eingestellt ist, zum
Implementieren des bestimmten Dienstes;
- – eine
Dienstausführungsumgebung
zum Ausführen
benutzerzugeordneter Fälle
von ausführbaren Programmcodes;
- – ein
Positionsübereinstimmungsteilsystem
zum Erfassen einer Positionsübereinstimmung
zwischen der Position des Benutzers, wie sie durch die Position
einer mobilen Identität
angezeigt wird, die dem Benutzer zuge ordnet ist, und einer Position,
die durch die Positionsdaten angezeigt ist; und
- – eine
Steueranordnung, die auf das Positionsübereinstimmungsteilsystem anspricht,
das eine Positionsübereinstimmung
erfasst, zum Einleiten der Ausführung
des benutzerzugeordneten Falles einer des ausführbaren Programmcodes zum Liefern
des speziellen Dienstes an den Benutzer.
-
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 En titä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;
-
Bester Modus
zum Ausführen
der Erfindung
-
Dienstlieferverfahren
und Systeme, die die Erfindung umfassen, werden nun mit Bezugnahme auf 6 bis 8 beschrieben.
Die spezifischen Ausführungsbeispiele
von 7 und 8 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 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 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.
-
Eine
Anzahl unterschiedlicher Möglichkeiten kann
verwendet werden, um den Benutzer und den Dienstfall, für den der
Benutzer qualifiziert wurde, zuzuordnen. Eine Möglichkeit ist es, daß das der Dienstfall
einen Identifizierer des Benutzers enthält; in diesem Fall führt der
Positionsauslöserprozeß dazu,
daß der
Benutzeridentifizierer erzeugt wird, zum Übereinstimmen mit dem Dienstfall
(es ist anzumerken, falls mehrere Dienstfälle für den gleichen Benutzer gespeichert
werden, können
zusätzliche
Informationen, wie z. B. Auslöseposition
erforderlich sein, um zwischen den Dienstfällen zu unterscheiden). Eine weitere
Möglichkeit
ist es, einen Dienstfallidentifizierer in dem Dienstfall 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 Dienstfall
erzeugt wird. Eine dritte Möglichkeit
zum Zuordnen des Dienstfalls zu einem Benutzer mit einem speziellen
Dienstfall ist es, den Dienstfall 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 und 8 beschrieben.
-
Bei
dem Ausführungsbeispiel
von 7 ist das Mobilgerät des Benutzers 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 einem 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.
-
Die
Positionsbeschreiber 74 sind in der mobilen Entität 20 gespeichert,
wo eine Positionsübereinstimmung
bewirkt wird; jeder Positionsbeschreiber weist einen Dienstfallidentifizierer
zum Identifizieren eines zugeordneten Dienstfalls auf. Der Dienstfall 80 ist
auch in der mobilen Entität 20 gespeichert
und nimmt die Form eines voll ausführbaren Diensfallcodes an.
Der Dienstfall ist dem Benutzer zugeordnet, da derselbe in der mobilen
Entität 20 gespeichert ist,
und umfaßt
vorteilhafterweise Adreß-
(und Paßwort-)
Einzelheiten zum Kontaktieren des Dienstsystems. Wenn beim Betrieb
eine Positionsübereinstimmung
erfaßt
wird, leitet die mobile Entität
den zugeordneten Dienstfall über
einen Trägerdienst
mit Datenfähigkeit
des PLMN 10 und das Internet 39 an das Dienstsystem
weiter. An dem Dienstsystem wird der Dienstfall zu einem Authentifizierungs-
und Dienstausführungsteilsystem 83 weitergeleitet,
wo derselbe abläuft.
-
Vorzugsweise
umfaßt
der Dienstfall die Identität
des Benutzers und ist durch die Dienstfirma digital unterzeichnet
(wobei ein entsprechendes Zertifikat in dem Dienstfall enthalten
ist). In diesem Fall kann das Teilsystem 83 sowohl:
- – Prüfen, daß der Dienstfall
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 den Dienstfall sendet, gleich ist wie die Partei, die in dem
Dienstfall identifiziert ist (dessen Authentizität durch die Digitalsignatur
garantiert 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 Dienstfall
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
Vorsichts maß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).
-
Der
obige Authentifizierungsprozeß kann
genauso als Ganzes oder teilweise angelegt werden.
-
Bei
dem Ausführungsbeispiel
von 8 sind die Positionsbeschreiber 74 erneut
in der mobilen Entität 20 gespeichert,
wo eine Positionsübereinstimmung
bewirkt wird. Nun umfaßt
das der Dienstfall 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 8 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
wur den, 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 7 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ß der Dienstfall
durch die Dienstfirma digital unterzeichnet wird, um es dem Enddienstliefersystem
(System 40 in 7) ermöglicht wird, den Ursprung des
Dienstfalls 80 zu prüfen.
Erneut ist das Prüfen
der Identität des
Benutzers, der die Dienstausführung
anfordert, vernünftig,
unter Verwendung eines Herausforderung-/Antwort-mechanismus und/oder
einer PIN-Eingabe.
-
Die
mobile Entität 20 muß 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 8 angezeigt wurde, muß die mobile Entität 20 keine
externe Kommunikationsfähigkeit aufweisen,
außer
zum Ermöglichen
der Positionsbestimmung.
-
Die
Positionsbeschreiber und Dienstfälle können durch
den Benutzer, durch den Dienst, der geliefert wird oder in jeder
anderen möglichen
Verteilung gespeichert werden.
-
Ein
Dienstfall 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).