DE60102972T2

DE60102972T2 - Positionsabhängiges Nutzerinterface

Info

Publication number: DE60102972T2
Application number: DE60102972T
Authority: DE
Inventors: Colin Frenchay L'Anson; Rycharde Jeffery Clifton Hawkes; James Thomas Edward Clifton McDonnell; John Deryk Combe Down Waters; Lawrence Malmesbury Wilcock
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 2000-03-29
Filing date: 2001-02-14
Publication date: 2005-03-31
Anticipated expiration: 2021-02-15
Also published as: JP2001325175A; EP1139681B1; US20020054150A1; GB0007474D0; US6760046B2; EP1139681A1; DE60102972D1

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf eine ortsabhängige Benutzerschnittstelle, die z. B. dem Benutzer einer mobilen Entität vorgelegt wird, die über eine Zellularfunkinfrastruktur eine Internet-Verbindbarkeit aufweist.
Hintergrund der Erfindung
Die bevorzugten Ausführungsbeispiele der Erfindung, die im folgenden beschrieben werden, sind zur Verwendung durch mobile Vorrichtungen (sowie weitere Vorrichtungen) beabsichtigt, die über eine Mobilfunkinfrastruktur eine Internet-Verbindbarkeit aufweisen, wobei die Vorrichtungen ihren Ort durch Verfahren bestimmen, die dieser Infrastruktur zugeordnet sind. Deshalb ist unten Bezug nehmend auf die 1 bis 6 ein kurzer Überblick über eine typische Mobilfunkinfrastruktur und verschiedene Anordnungen einer Ortsbestimmung gegeben, um ein Verständnis der vorliegenden Erfindung zu erleichtern.
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 Dienstanfor derung 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 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 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 Sen den 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 im Vorangegangenen die Bereitstellung von Ortsdaten durch die Mobilfunkinfrastruktur an die mobile Entität als ein Dienst behandelt wurde, der über einen datenfähigen Trägerkanal bewirkt wird, ist zu erwarten, daß, da Ortsdaten als ein grundlegendes Element von Mobilfunkinfrastruktur-Diensten betrachtet werden, in den relevanten Mobilfunkstandards dafür gesorgt wird, daß Ortsdaten über einen Signalisierungskanal an die mobile Entität geleitet werden.
Die vorliegende Erfindung betrifft ein Anpassen einer Benutzerschnittstelle, wie z. B. einer Browser-Schnittstelle, die auf einer mobilen Vorrichtung vorgelegt wird, an die gegenwärtige Situation des Benutzers. Diesbezüglich ist gut bekannt, daß ein Benutzer nicht nur seinen eigenen Homepage-Entwurf spezifizieren kann, der jedesmal aufgerufen wird, wenn er seinen Web-Browser startet, sondern ebenso, daß ein Benutzer seine bevorzugte Schnittstelle zu einem bestimmten Dienstanbieter spezifizieren kann.
Es ist aus der EP-A-0801342 bekannt, eine Benutzerschnittstellenumgebung eines tragbaren Datenprozessors gemäß dem geographischen Ort des letzteren auszuwählen. Bei einem Ausführungsbeispiel, das zur Verwendung in einem Kranken haus beabsichtigt ist, ist die Benutzerschnittstellenumgebung des tragbaren Datenprozessors daran angepaßt, sich in dem Zimmer eines Patienten zu befinden, indem Icons bzw. Bildsymbole zum Aufrufen der EKG-Historie des Patienten vorgesehen sind. Die US-A-5552806 offenbart eine Vorrichtung, die ihren Betriebsumgebungsort erfaßt und Aufgaben-Icons gemäß einer vorherigen Verwendung an diesem Ort anzeigt.
Eine Aufgabe der vorliegenden Erfindung besteht darin, ein verbessertes Verfahren zum Anpassen einer Benutzerschnittstelle an die gegenwärtige Situation des Benutzers zu schaffen.
Zusammenfassung der Erfindung
Gemäß der vorliegenden Erfindung wird ein Verfahren zum Anpassen einer Benutzerschnittstelle auf einer Vorrichtung, die durch einen Benutzer verwendet wird, an den gegenwärtigen Ort bereitgestellt, wobei das Verfahren folgende Schritte aufweist:

– Speichern benutzerspezifischer Schnittstellenspezifizierungsdaten, die zumindest einen ersten und einen zweiten Benutzerschnittstellendatensatz aufweisen, die geeignet für jeweilige geographische Bereiche sind und zur Verwendung beim Implementieren einer Netz-Browser-Benutzerschnittstelle, die auf der Vorrichtung läuft, zum Browsen in einem Netz beabsichtigt sind, wobei jeder Benutzerschnittstellendatensatz einen jeweiligen Satz von Gegenständen definiert, über die Informationen auf der Netz-Browser-Benutzerschnittstelle vorgelegt werden sollen, und
– Bestimmen, welcher Benutzerschnittstellendatensatz der Schnittstellenspezifizierungsdaten des Benutzers für den gegenwärtigen Ort dieser Vorrichtung geeignet ist, und
– Verwenden dieses Benutzerschnittstellendatensatzes, um die Benutzerschnittstelle zu implementieren;

Beispielhaft könnte der erste Datensatz zur Verwendung beim Implementieren einer Netz-Browser-Benutzerschnittstelle in einem Heimbereich eines Benutzers beabsichtigt sein, während der zweite Datensatz zur Verwendung beim Implementieren einer Netz-Browser-Benutzerschnittstelle in anderen Bereichen beabsichtigt sein könnte; in diesem Fall würde der Schritt des Bestimmens, welcher Schnittstellendatensatz für den gegenwärtigen Ort einer Benutzervorrichtung geeignet ist, ein Bestimmen des gegenwärtigen Orts der Benutzervorrichtung und ein Vergleichen desselben mit dem Heimbereich des Benutzers beinhalten.
Vorzugsweise ist jeder Gegenstand in dem Satz von Gegenständen, die jedem Datensatz zugeordnet sind, durch eines der folgenden Elemente definiert:

– ein spezifisches Datenobjekt;
– eine spezifische Datenobjektreferenz;
– ein generisches Thema, auf das hin eine Suche nach Objekten durchgeführt werden kann, die in der Benutzerschnittstelle enthalten sein sollen, die unter Ver wendung des betreffenden Datensatzes implementiert ist.

Kurze Beschreibung der Zeichnungen
Ein Verfahren und ein Dienstsystem, beide die vorliegende Erfindung ausführend, zum Anpassen der Benutzerschnittstelle einer Vorrichtung an die gegenwärtige Situation des Benutzers, werden nun mittels nichteinschränkenden Beispiels Bezug nehmend auf die beigefügten 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 verschiedene unterschiedliche Routen darstellt, durch die Ortsinformationen an ein Dienstsystem geliefert werden können;
7 ist ein Diagramm, das darstellt, wie ein Benutzer Heim- und Weg-Browser-Homepages zur Speicherung an seinem Internetzugangsanbieterort spezifizieren kann;
8 ist ein Diagramm, dem aus 7 ähnelnd, stellt jedoch die Bereitstellung der geeigneten Browser-Homepage an einen mobilen Benutzer dar, der über ein PLMN mit dem Internet verbunden ist;
9 ist ein Diagramm, das die Schritte darstellt, die beim Bedienen der geeigneten Homepage zurück zu der anfordernden mobilen Vorrichtung aus 8 beinhaltet sind;
10 ist ein Diagramm, dem aus 8 ähnelnd, stellt jedoch die Bereitstellung von Homepages des Benutzers durch das IAP-Dienstsystem an ein Gateway des PLMN dar, wobei letzteres das Heim-PLMN des Benutzers ist und das Gateway zum Leiten der korrekten Homepage an die mobile Vorrichtung verantwortlich ist;
11 ist ein Diagramm, dem aus 10 ähnelnd, stellt jedoch die Bereitstellung von Homepages des Benutzers an das Gateway eines besuchten PLMN dar; und
12 ist ein Diagramm, dem aus 8 ähnelnd, stellt jedoch die Wiedergewinnung, durch das IAP-Dienstsystem, von Informationselementen dar, die für den Ort des Benutzers relevant sind, wobei diese Elemente in der Homepage, die für den Benutzer bereitgestellt wird, enthalten sind.
Bester Modus zum Ausführen der Erfindung
In der folgenden Beschreibung in Bezug auf die 7 bis 12 sind das PLMN 10 und seine Mittel zum Bereitstellen datenfähiger Trägerdienste für einen Internetzugang aus Klarheitsgründen nicht detailliert gezeigt; die Form des PLMN sowie davon, wie datenfähige Dienste bereitgestellt werden, sind z. B. so, wie oben in Bezug auf die 1 bis 6 beschrieben wurde. Ferner treffen die oben in Bezug auf die mobile Entität 20 und Ortsserver erläuterten Verallgemeinerungen gleichermaßen auf diese Elemente zu, wie sie Bestandteile der unten beschriebenen Ausführungsbeispiele der Erfindung sind.
7 zeigt ein Dienstsystem 72 eines Internetzugangsanbieters IAP, der einen Einwählzugang zu dem Internet 30 für Benutzer bereitstellt, die über ein PSTN 71 von z. B. einem Heim-PC 70 zugreifen. In 7 ist der PC 70 dargestellt, um über das PLMN 71, das IAP-Dienstsystem 72 und das Internet 39 (siehe gepunktete Linie 100) mit einem Server 40 verbunden zu sein. Die Bereitstellung eines Internetzugangs wird auf eine standardmäßige Weise gesteuert – z. B. prüft ein Zugriffssteuerblock 75, wenn ein Benutzer den PC 70 verwendet, um sich in eine Schnittstelle 73 (eine Modembank) des Dienstsystems 72 einzuwählen, die empfangenen Details (üblicherweise Benutzereingabe-Benutzername/Paßwort oder ID der anrufenden Leitung) des Benutzers gegenüber den Details, die für diesen Benutzer in einer Benutzerprofildatenbank 76 gehalten werden. Unter der Annahme, daß diese Prüfung bestanden wird, wird dem Benutzer über eine Schnittstelle 74 Zugang zu dem Internet 39 erteilt.
Im allgemeinen liefert der IAP einen Satz von Web-Seiten zum Anbieten von Diensten für den Benutzer. Wenn ein Benutzer, der durch das IAP-Dienstsystem verbunden ist, einen Zugriff auf eine dieser Seiten anfordert, wird diese Anforderung im Inneren des Dienstsystems durch ein Filter 77 aufgegriffen und direkt zu dem Webserverabschnitt des Dienstsystems (siehe gepunktete Linie 101) umgeleitet. Der Webserverabschnitt des Systems 72 weist einen Speicher 80 von Web-Dateien (HTML-Dateien, Stilblatt-Dateien, Bilddateien und Skriptdateien, wie z. B. CGI- und ASP-Dateien) auf, sowie eine Serverschnittstelle 78 und eine Skriptausführungsumgebung 79. Die Serverschnittstelle 78 empfängt HTTP-Anforderungen, greift auf die relevante Datei in dem Speicher 80 zu und gibt entweder diese Datei direkt an die anfordernden Entität in einer HTTP-Antwort zurück oder leitet, wenn die Datei serverseitige Skripts enthält, dies an die Ausführungsumgebung 79, die die Skripts ausführt und das Ergebnis an die Serverschnittstelle 78 zum Senden an die anfordernde Entität zurückgibt. In 7 stellt ein Element 81 die „Homepage"-Datei des IAP dar.
Der verantwortliche IAP des Dienstsystems 72 bietet dem Benutzer des PC 70 die Gelegenheit, eine Benutzer-Homepage zur Speicherung in dem Speicher 80 zu spezifizieren. Dies ist eine private Homepage, die für den Benutzer beabsichtigt ist, und keine öffentliche Homepage, die für einen Zugriff durch Dritte beabsichtigt ist (obwohl der Benutzer die private Homepage als eine öffentliche betreiben könnte). Die private Homepage ist Benutzername/Paßwort-geschützt, jedoch durch den Benutzer sowohl über das PSTN 71 als auch über das Internet 71 zugänglich; ein Paßwortschutz wird auf eine standardmäßige Art und Weise erzielt, die Fachleuten auf diesem Gebiet bekannt ist. Der Aufbau (Spezifizierung) der privaten Homepage wird durch eine oder mehrere Skriptdateien 82 bewirkt, die durch den IAP zu diesem Zweck vorgesehen sind und von der Homepage 80 des IAP zugänglich sind. Die resultierende private Homepage wird als solche in dem Speicher 80 gespeichert (oder mögli cherweise als ein Satz definierender Parameter in dem Profil des Benutzers, das in einem Speicher 76 gehalten wird).
Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ermöglichen es die Skripts 82 dem Benutzer, zwei Versionen seiner privaten Homepage zu speichern, nämlich eine private „Heim"-Homepage 83, die zur Benutzung beabsichtigt ist, wenn sich der Benutzer in einem Heim-Bereich befindet, und eine private „Weg"-Homepage 84, die zur Verwendung beabsichtigt ist, wenn sich der Benutzer weg von seinem Heim-Bereich befindet. Die „Heim"-Version 83 kann z. B. Verbindungen bzw. Links zu Geschäft-Websites und Ereignis-Websites für Geschäfte und Ereignisse umfassen, die für den Heim-Bereich des Benutzers örtlich sind; die „Weg"-Version 84 kann z. B. Verbindungen bzw. Links zu Karten-Websites, Reise-Websites, Geldwechsel-Websites usw. umfassen. Bei dem vorliegenden Beispiel wird angenommen, daß alle Informationen, die für die Heim- und die Weg-Version benötigt werden, bekannt sind und direkt in der Heim- und der Weg-Datei 83, 84 beinhaltet sind, wobei diesen letzteren unterschiedliche Namen gegeben werden; wie jedoch im folgenden ersichtlich ist, ist es möglich, dem Typ nach auch Informationen zu spezifizieren, die nicht zuvor eingesetzt werden können, sondern dann, wenn sie benötigt werden, abgerufen werden müssen, wie z. B. detaillierte bereichsspezifische Informationen.
Wieder leitet der Benutzer bei dem vorliegenden Beispiel keine Ortsparameter, die definieren, was der Benutzer mit seinem Heim-Bereich meint, an das Dienstsystem 72 – dies ist so, da, wie dies ersichtlich wird, er die zugreifende Vorrichtung ist, die diese Entscheidung trifft. Bei anderen Ausführungsbeispielen jedoch ist es das Dienstsystem, das bestimmt, wann sich eine zugreifende Vorrichtung in dem Heim-Bereich befindet, wobei diese Bestimmung auf der Basis einer Heim-Bereich-Definition, die durch den Benutzer geliefert wird, getroffen wird.
8 stellt den Benutzer dar, der Zugang zu seiner privaten Homepage von einer mobilen Entität 20 über einen datenfähigen Trägerdienst aus PLMN 10, Gateway 35, Internet 39 und der Schnittstelle 74 des IAP-Dienstsystems 72 des Benutzers (siehe gepunktete Linie 102) anfordert. Die Anforderung wird durch ein Programm erzeugt, das in einem Datenhandhabungsteilsystem der mobilen Entität 20 läuft. Dieses Programm dient, wie unten detaillierter beschrieben wird, um durch einen Dateinamen eine oder eine weitere der privaten Homepage-Versionen anzufordern, wobei diese Dateinamen zuvor durch den Benutzer während einer Aufbauphase für das Programm eingegeben wurden. Ebenso zuvor aufgezeichnet wird die Zell-ID der PLMN-Zelle, die dem Heim-Bereich des Benutzers entspricht (dies kann dadurch, daß der Benutzer während der Aufbauphase des Programms anzeigen muß, wann der Benutzer „zu Hause" ist, erfaßt werden – wobei das Programm angeordnet ist, um daraufhin die gegenwärtige Zell-ID zu erfassen, wie durch das Funkteilsystem der mobilen Entität 20 erfaßt wird).
9 stellt die Schritte dar, die beim Anfordern und Liefern der geeigneten privaten Homepage an den Benutzer der mobilen Entität 20 beinhaltet sind. Der Benutzer kann das Programm voreinstellen, um direkt zu einer automatischen Bestimmung der geeigneten privaten Homepage-Version zu leiten (Schritt 87), oder kann dafür sorgen, daß das Programm zuerst eine Auswahlseite anzeigt (Schritt 86). In diesem letzteren Fall kann der Benutzer eine ortsbasierte automatische Seitenauswahl wählen oder kann entweder die „Heim"- oder die „Weg"-Seitenversion, wie dies erforderlich ist, spezifizieren, wodurch die ortsbasierte Bestimmung, durch Schritt 87 ausgeführt, umgangen wird. Wenn der Benutzer die automatische Seitenauswahl wählt oder wenn dies voreingestellt war, wird Schritt 87 ausgeführt, in dem das Programm die gegenwärtige Zell-ID, wie diese durch das Funkteilsystem der mobilen Entität 20 bereitgestellt wird, mit der gespeicherten Zell-ID vergleicht, die dem Heim-Bereich des Benutzers entspricht; wenn die Zell-IDs über einstimmen, soll die private Heim-Homepage angefordert werden, andernfalls wird die private „Weg"-Homepage angefordert. Das tatsächliche Senden der Anforderung nach der geeigneten Homepage, wie in Schritt 86 spezifiziert oder in Schritt 87 bestimmt wird, wird in Schritt 88 durch ein Senden des relevanten Dateinamens an das IAP-Dienstsystem, gemeinsam mit Benutzername/Paßwort-Informationen (oder möglichen anderen Informationen, die für eine Zugangsberechtigung zu der privaten Homepage des Benutzers erforderlich sein könnten), bewirkt. Die Schritte 86, 87 und 88 werden alle in der mobilen Entität 20 ausgeführt. Die Anforderung wird durch das IAP-Dienstsystem 72 empfangen, das die geeignete private Homepage zurückgibt. Die private Homepage-Datei wird durch die mobile Entität empfangen und angezeigt (Schritt 89). Es ist zu erkennen, daß das obige Verfahren unter Verwendung von WAP mit geeigneten Skripts implementiert sein kann.
Obwohl im Vorangegangenen die automatische Bestimmung dessen, welche Version der privaten Homepage bereitgestellt werden sollte, in der mobilen Entität auf der Basis der Zell-ID bewirkt wurde, existiert eine Anzahl weiterer Möglichkeiten sowohl in bezug auf den Parameter, der zum Beurteilen des Orts verwendet werden soll, als auch bezüglich dessen, wo die Bestimmung durchgeführt wird. So könnte statt einer Verwendung der Zell-ID als Ortsindikator ein genaueres Maß unter Verwendung einer der Techniken durchgeführt werden, die in dem Einleitungsteil der vorliegenden Beschreibung beschrieben sind; lokale Informationen könnten z. B. durch einen Ortsserver bereitgestellt werden, der dem PLMN 10 zugeordnet ist (vgl. Ortsserver 67 aus 5). Wenn relativ genaue Ortsinformationen verfügbar sind, kann der Heimbereich eines Benutzers als ein Bereich eines bestimmten Radius, um einem spezifizierten Ort zentriert, spezifiziert sein, wie z. B. das physische Zuhause des Benutzers (wieder kann dieser Ort durch ein geeignetes Auslösen der mobilen Entität, um ihren Ort zu bestimmen, erfaßt werden, während diese an dem Heimort ist, z. B. durch ein Senden einer Anforderung an einen Ortsserver). In bezug darauf, wo diese Versionsbestimmung durchgeführt wird, könnte dieselbe an dem IAP-Dienstsystem 72 auf der Basis des Orts der mobilen Entität bewirkt werden, der demselben durch die Entität selbst berichtet wird, oder wie dies von einem Ortsserver erhalten wird (mit der spezifischen oder vorherigen Berechtigung des Benutzers). Ferner kann, wie unten in Bezug auf das Ausführungsbeispiel aus 10 zu sehen sein wird, die Versionsbestimmung durch eine Zwischenentität, wie z. B. ein Gateway 35, durchgeführt werden. Wenn die Versionsbestimmung nicht in der Benutzervorrichtung (Entität 20) bewirkt wird, fordert die letztere einfach ihre private Homepage an, wie durch einen einzelnen Namen identifiziert wird; die Datei, auf die durch diesen Namen gezeigt wird, ist im allgemeinen eine Skriptdatei zum Hervorbringen einer Versionsbestimmung und Seitenlieferung (alternativ könnte das empfangende System angeordnet sein, um den Dateinamen zu erkennen und eine geeignete Handlung auszulösen).
Natürlich ist ein Zugriff durch den Benutzer auf seine private Homepage nicht auf den Fall eingeschränkt, in dem der Benutzer eine mobile Entität und ein PLMN verwendet; so könnte der Benutzer unter Verwendung eines PC, der mit dem PSTN 71 verbunden ist, zugreifen. In diesem letzteren Fall könnte die Entscheidung bezüglich dessen, ob er sich in seinem Heim-Bereich befindet, in dem Dienstsystem 72 einfach auf der Basis der ID der anrufenden Leitung durchgeführt werden, wobei angenommen wird, daß, wenn die ID der anrufenden Leitung nicht der normalen, Heim, Anruf-ID entspricht, die private „Weg"-Homepage geeignet ist. Ausgereiftere Strategien sind natürlich möglich. Es ist zu erkennen, daß, wenn eine Versionsbestimmung durch das Dienstsystem 72 ausgeführt wird und nicht durch das Zugreifen auf die Vorrichtung selbst, es unter Umständen nötig ist, den „Heim"-Bereich des Benutzers auf mehrere unterschiedliche Weisen zu definieren, wobei jede für einen unterschiedlichen Typ von Zugangsnetz (PSTN, PLMN) geeignet ist, da der gegenwärtige Ort der zugreifenden Vorrichtung so bestimmt werden kann, wie es für dieses Netz spezifisch ist.
Während in dem Vorangegangenen nur zwei Versionen der privaten Homepage des Benutzers verwendet wurden (eine „Heim"-Version und eine „Weg"-Version), ist zu erkennen, daß mehr als zwei Versionen verwendet werden können, wobei jede derselben einem bestimmten Bereich zugeordnet ist. Eine Unterscheidung könnte z. B. zwischen „weg" im Ausland und „weg" im Heimatland des Benutzers gemacht werden. Ferner kann die Versionsbestimmung durch weitere Parameter zusätzlich zu dem Ort beeinflußt werden, wie z. B. insbesondere den Typ der Vorrichtung, die zum Zugriff auf die private Homepage verwendet wird, und die Fähigkeiten des Zugangsnetzes – wobei so eine sehr viel umfangreichere Homepage für PC-Typ-Vorrichtungen bereitgestellt werden kann, die einen Internetzugang über ein Betriebs-LAN, verglichen mit WAP-Mobiltelefonen, haben. Tatsächlich können private Homepage-Versionen vorgesehen sein, die geeignet für Sprach-Browser und weitere nichtvisuelle Schnittstellenvorrichtungen sind (die Verwendung derartiger nichtvisueller Schnittstellen ist natürlich nicht auf Fälle eingeschränkt, in denen es lediglich eine Option unter visuellen Schnittstellen gibt – alle Versionen der privaten Homepage könnten nichtvisuelle Schnittstellen implementieren, selbst wenn die zugreifende Vorrichtung eine Visuellschnittstellenfähigkeit hätte).
Bezug nehmend auf 10 hat der Benutzer bei diesem Ausführungsbeispiel sein Benutzerprofil spezifiziert, das in dem HLR 31 des PLMN 10 (dem Heim-PLMN des Benutzers) gehalten wird, daß der Benutzer ortsbasierte private Homepages aufweist, die durch das IAP-Dienstsystem 72 gehalten werden. Nun werden, wenn der Benutzer einen Internetzugang von der mobilen Entität 20 anfordert, die Details des Benutzers und des Dienstsystems 72 aus dem Profil des Benutzers extrahiert und an das Gateway 35 (siehe Pfeil 103) geleitet. Das Gateway 35 kann nun präemptiv wirken, um die Versionen der privaten Homepage des Benutzers von dem Dienstsystem zu laden (siehe Anforderungspfeil 104 und Antwortpfeil 105). Daraufhin, daß der Benutzer eine Anforderung nach seiner privaten Homepage (gepunktete Linie 106) stellt, fängt das Gateway die Anforderung ein und antwortet selbst. In dem Beispiel aus 10 wird die Bestimmung, welche Version zu verwenden ist, durch das Gateway 35 ausgeführt, wobei es berechtigt ist, den Ort der mobilen Entität von dem Ortsserver 67 anzufordern (und die Heim-Bereich-Details, die zuvor entweder von dem Dienstsystem 72 oder dem HLR 31 an den Server 35 geliefert wurden). Das Gateway 35 muß nicht präemptiv handeln, um die Homepage-Version abzuholen, und könnte warten, bis dies von der privaten Homepage des Benutzers angefordert wird, und dann bestimmen, welche Version benötigt wird, bevor dieselbe von dem Dienstsystem 72 angefordert wird.
11 stellt den Fall dar, daß der Benutzer über ein besuchtes PLMN 10V und nicht durch das Heim-PLMN 10H des Benutzers zugreift. Wie bei dem Ausführungsbeispiel aus 10 umfaßt das Profil des Benutzers, das durch das HLR 31 des Privat-PLMN 10H gehalten wird, die Details des Privat-Homepage-Version-Dienstes. Daraufhin, daß der Benutzer auf das besuchte PLMN 10V zugreift, wird das Profil des Benutzers von dem Heim-PLMN des Benutzers erhalten (z. B. unter Verwendung eines Protokolls, das dem CAMEL-Protokoll ähnelt, das durch ETSI für GSM-Netze spezifiziert ist) und an das relevante VLR 32 des besuchten PLMN weitergeleitet. Die Sache fährt nun auf eine ähnliche Art und Weise wie diejenige fort, die für 10 beschrieben wurde, wobei das Gateway 35V des besuchten Netzes die Privat-Homepage-Version von dem Dienstsystem (Pfeile 108, 109) abruft, wobei von dem Ortsserver 67 der Ort der mobilen Entität 20 erhalten wird, wenn letztere ihre private Homepage anfordert (gepunktete Linie 110), und die geeignete Homepage-Version zurückgegeben wird.
Wenn der Benutzer seine private Homepage über ein IAP-Dienstsystem anfordert, das nicht sein Heim-IAP-System 72 ist, das jedoch eine Kooperationsvereinbarung mit letzterem hat, kann eine Anordnung, die derjenigen ähnelt, die für das PLMN 10 in 10 beschrieben wurde, verwendet werden, damit das besuchte Dienstsystem an der Versionsbestimmung teilnehmen kann. Dies wird unter Verwendung des RADIUS-Protokolls erzielt, durch das kooperierende IAPs Berechtigungs- und Abrechnungsdaten austauschen (siehe RFCs 2138 und 2139 der Internet Engineering Task Force (Internet-Arbeitsgruppe)). Insbesondere sendet das System 72, wenn das besuchte Dienstsystem das System 72 kontaktiert, um die Berechtigung des Benutzers zu prüfen, die Privat-Homepage-Version-Informationen an das besuchte Dienstsystem zur Verwendung durch letzteres (das besuchte System wurde programmiert, um geeignet zu arbeiten, um den Versionsbestimmungsdienst bereitzustellen).
Es ist ebenso anzumerken, daß die Privat-Homepage-Version-Daten des Benutzers nicht in dem IAP-Dienstsystem des Benutzers gespeichert sein müssen und z. B. durch das Gateway 35 oder ein weiteres Dienstsystem (wie z. B. das System 40) unabhängig von dem IAP-System 72 gehalten werden könnten.
Wie oben erwähnt wurde, können die Privat-Homepage-Versionen Informationen enthalten, die nicht geeignet im vorhinein spezifiziert werden können, sondern abgerufen werden müssen, wenn dies erforderlich ist (da diese Informationen z. B. solche sind, die spezifisch für den gegenwärtigen Ort des Benutzers sind). 12 stellt eine derartige Situation dar, in der der Benutzer spezifiziert hat, daß die „Weg"-Version der privaten Homepage eine Liste der besten Restaurants und einen Theaterführer für den Ort enthalten sollte, an dem sich der Benutzer befindet. Derartige Listen können im allgemeinen als „Spezialist-Lokal-Ressource-Listen" (SLRL) bezeichnet werden und es gibt im allgemeinen eine Anzahl von Websites, die derartige Listen für jede wesentliche Stadt enthalten; diese Websites sind in 12 als Server 122 dargestellt. SLRL-Sites bzw. -Orte 122 sind üblicherweise selbst in weiteren allgemeineren Orten aufgelistet, die hier als „Lokal-Ressource-Verzeichnisse" (LRD; LRD = Local Ressource Directory) bezeichnet werden und in 12 als Server 121 dargestellt sind. Diese LRD-Orte wiederum sind im allgemeinen in anderen Orten aufgelistet, wobei ein derartiger Ort – ein Verzeichnis lokaler Verzeichnisse (DoLD; DoLD = Directory of Local Directories) – in 12 bei 120 gezeigt ist.
Der Benutzer identifiziert, welche Listen von Interesse sind, durch ein Spezifizieren von SLRL-Kategorie-Typen gegenüber dem Dienstsystem während des Laufens der Seiten-Aufbau-Skripts 82.
Bei dem vorliegenden Beispiel wird angenommen, daß die Versionsbestimmung in dem Dienstsystem 72 ansprechend darauf durchgeführt wird, daß die mobile Entität 20 eine Anforderung nach der privaten Homepage des Benutzers sendet (siehe gepunktete Linie 114). Diese Anforderung umfaßt als eine Abfrage-Zeichenfolge der Anforderungs-URL den Ort des Benutzers, wie z. B. durch einen Ortsserver des PLMN 10 bestimmt wird. Beim Bestimmen der Ortsdaten bestimmt das Dienstsystem 72, daß die „Weg"-Homepage-Version des Benutzers erforderlich ist, und daß es deshalb nötig ist, die URLs der SLRL-Websites 122 für die besten lokalen Restaurants und die lokalen Theaterführer zu erhalten. Die erforderlichen Informationen werden durch ein anfängliches Kontaktieren des DoLD-Servers 120 (Linie 115) erhalten, um den URL des LRD-Orts 121 wiederzugewinnen, der relevant für den gegenwärtigen Ort des Benutzers ist (wobei dieser letztere an den Server 120 geleitet wird). Danach wird der geeignete LRD-Ort 123 kontaktiert (Linie 116) und ihm werden die Kategorie-Typen der erforderlichen Spezialist-Lokal-Ressource-Listen weitergeleitet; das LRD spricht mit den URLs der relevanten SLRL-Orte 122 an (wobei diese Orte in 12 schraffiert gezeigt sind). Diese URLs werden dann in die private „Weg"-Homepage-Version eingebaut, die an die mobile Entität 20 gesendet wird.
Es ist außer der Tatsache, daß URLs relevanter lokaler Orte enthalten sind, auch möglich, spezifische Objekte von Informationen einzuschließen, die im allgemeinen durch den Benutzer während eines Seitenaufbaus identifiziert werden (wie z. B. die Telefonnummer des nächsten lokalen Krankenhauses). Es ist natürlich im allgemeinen, um es zu ermöglichen, daß derartige Informationen unter all den Daten, die über das Internet verfügbar sind, extrahiert werden können, nötig, daß der Benutzer während der Aufbauphase eine Quelle identifiziert, an der die Informationen zu finden sind. So kann der Benutzer ein XML-Dokument identifizieren, das es aufgrund seiner Strukturierung von Informationen ermöglicht, daß die relevanten Daten automatisch extrahiert werden können.
Die Aufgabe eines Abrufens eines oder mehrerer ortsabhängiger Elemente (wobei ein Element entweder ein spezifisches Datenobjekt lokaler Informationen oder eine Hyperlink zu einer Ressource aufweist, die Ortsinformationen enthält) für den Datensatz, der als für den gegenwärtigen Vorrichtungsort geeignet bestimmt wird, kann auch durch eine Zwischenentität ausgeführt werden, die dem Ort zugeordnet ist, an dem sich die Vorrichtung befindet, wobei die relevanten Schnittstellenspezifizierungsdaten von dem Ort, an dem diese gespeichert sind, an diese Entität geleitet werden.
Es wird darauf verwiesen, daß, obwohl die Bestimmung dessen, welche private Homepage-Version verwendet werden sollte, und der Vorgang des Bereitstellens eines ortsspezifischen Inhalts in einer privaten Homepage-Version es beide erforderlich machen, daß der Ort der Benutzervorrichtung (z. B. Entität 20) bekannt ist, diese beiden Vorgänge größtenteils unabhängig sind – so ist dies, während die gleichen Ortsdaten für beide verwendet werden könnten, nicht erforderlich.
Es ist zu erkennen, daß viele Varianten zu den oben beschriebenen Ausführungsbeispielen der Erfindung möglich sind.

Claims

Ein Verfahren zum Anpassen einer Benutzerschnittstelle auf einer Vorrichtung (20; 70), die durch einen Benutzer verwendet wird, an den gegenwärtigen Ort, mit folgenden Schritten: Speichern benutzerspezifischer Schnittstellenspezifizierungsdaten, die zumindest einen ersten und einen zweiten Benutzerschnittstellendatensatz (83, 84) aufweisen, die geeignet für jeweilige geographische Bereiche sind und zur Verwendung beim Implementieren einer Netz-Browser-Benutzerschnittstelle, die auf der Vorrichtung (20, 70) läuft, zum Browsen in einem Netz (39) beabsichtigt sind, wobei jeder Benutzerschnittstellendatensatz (83, 84) einen jeweiligen Satz von Gegenständen definiert, über die Informationen auf der Netz-Browser-Benutzerschnittstelle vorgelegt werden sollen, Bestimmen, welcher Benutzerschnittstellendatensatz (83, 84) der Schnittstellenspezifizierungsdaten des Benutzers für den gegenwärtigen Ort dieser Vorrichtung geeignet ist, und Verwenden dieses Benutzerschnittstellendatensatzes (83, 84), um die Benutzerschnittstelle zu implementieren, wobei die Schnittstellenspezifizierungsdaten zumindest teilweise durch den Benutzer spezifiziert werden und in einem Dienstsystem (72) gespeichert werden, das mit einem für einen Benutzer zugänglichen Netz (39) verbunden ist, wobei der Benutzerschnittstellendatensatz, der für den gegenwärtigen Ort geeignet ist, anspre chend auf eine Anforderung von der Vorrichtung (20, 70) an dieselbe übertragen wird.
Ein Verfahren gemäß Anspruch 1, bei dem jeder Gegenstand in dem Satz von Gegenständen, die jedem Datensatz (83, 84) zugeordnet sind, durch eines der folgenden Elemente definiert ist: ein spezifisches Datenobjekt; eine spezifische Datenobjektreferenz; ein generisches Thema, auf das hin eine Suche nach Objekten durchgeführt werden kann, die in der Benutzerschnittstelle enthalten sein sollen, die unter Verwendung des betreffenden Datensatzes implementiert ist.
Ein Verfahren gemäß Anspruch 1 oder 2, bei dem der erste Datensatz (83) zur Verwendung beim Implementieren einer Netz-Browser-Benutzerschnittstelle in einem Privatbereich eines Benutzers beabsichtigt ist und der zweite Datensatz (84) zur Verwendung beim Implementieren einer Netz-Browser-Benutzerschnittstelle in anderen Bereichen beabsichtigt ist, wobei der Schritt des Bestimmens, welcher Schnittstellendatensatz für den gegenwärtigen Ort einer Benutzervorrichtung (20; 70) geeignet ist, ein Bestimmen des gegenwärtigen Ortes der Benutzervorrichtung und ein Vergleichen desselben mit dem Privatbereich des Benutzers beinhaltet.
Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem die Bestimmung, welcher Datensatz (83, 84) zu verwenden ist, zusätzlich zu einem Durchführen einer ortsabhängigen Bestimmung eine Bestimmung basierend auf dem Typ der betreffenden Vorrichtung (20; 70) beinhaltet.
Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem die ortsabhängige Bestimmung, welcher Datensatz zu verwenden ist, in einem der folgenden Elemente durchgeführt wird: der betreffenden Vorrichtung (20; 70); dem System (72), das die Schnittstellenspezifierungsdaten speichert; einer Zwischenentität (35) zwischen der Vorrichtung (20) und dem System (72).
Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem die Benutzerschnittstellenspezifizierungsdaten die Form einer jeweiligen Webseitendatei (83, 84) für jeden Datensatz annehmen.
Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem die Benutzerschnittstellenspezifizierungsdaten Daten aufweisen, die in einem Benutzerprofil (76) gehalten werden, das durch das System (72) gespeichert ist.
Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem zumindest ein Datensatz (84) die Beinhaltung eines oder mehrerer Elemente spezifiziert, die generisch identifiziert, jedoch beabsichtigt ist, um spezifisch für den Ort der Benutzervorrichtung (20; 70) durchgeführt zu werden, wobei das Verfahren die weiteren Teilschritte, wenn der zumindest eine Datensatz (84) bestimmt wird, um der geeignete Datensatz zu sein, eines Holens einer spezifischen Version des oder jedes des einen oder der mehreren Elemente, die von dem gegenwärtigen Ort der Vorrichtung (20; 70) abhängt, und eines Einschließens der oder jeder derartigen geholten Version in den geeigneten Datensatz umfaßt, wobei die spezifische Version oder die Versionen durch das System (72) oder durch eine Zwischenentität (35) geholt werden, die dem Ort zugeordnet ist, an dem sich die Vorrichtung (20; 70) befindet und an den die relevanten Schnittstellenspezifizierungsdaten von dem System (72) geleitet werden.
Ein Verfahren gemäß Anspruch 8, bei dem das Element eines der folgenden Elemente aufweist: ein spezifisches Datenobjekt lokaler Informationen; eine Hyperlink zu einer Ressource, die lokale Informationen enthält.
Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem jeder Datensatz (83, 84), einzeln genommen, sich auf eine Netz-Browser-Benutzerschnittstelle eines der folgenden Typen bezieht: eine graphische Benutzerschnittstelle für einen Web-Browser; eine Audio-Schnittstelle für einen Web-Browser.
Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem das Netz (39) das Internet aufweist und das System, das die Schnittstellenspezifizierungsdaten speichert, einen internetzugänglichen Datenspeicher (76) aufweist, auf den ein Benutzer einen Einwahlzugriff zu den Zwecken eines Spezifizierens und/oder Modifizierens der Schnittstellenspezifizierungsdaten hat, wobei auf die Schnittstellenspezifizierungsdaten über das Internet (39) durch eine Benutzervorrichtung (20; 70) entweder über eine Einwahlverbindung oder über das Internet (39) zugegriffen wird, um den Datensatz (83; 84), der für den gegenwärtigen Ort der Benutzervorrichtung (20; 70) geeignet ist, die einen Zugriff bewirkt, bereitzustellen.
Ein Verfahren gemäß Anspruch 11, bei dem die Benutzervorrichtung ein Mobiltelephon (20) ist, das einen Zugriff über eine Mobilfunkinfrastruktur (10) und das Internet (39) bewirkt.
Ein Verfahren gemäß Anspruch 1, bei dem das System, das die Schnittstellenspezifizierungsdaten speichert, ein Dienstsystem (72) eines Internet-Zugriffsanbieters ist.