-
TECHNISCHES
GEBIET
-
Die vorliegende Erfindung bezieht
sich auf Versehen von Endnutzerstationen mit Zugriff auf eine Portalstruktur.
Die Erfindung bezieht sich auch auf eine Anordnung in einer Portalstruktur
zum Handhaben von Endnutzerstationszugriff auf die Portalstruktur,
und auf ein Verfahren zum Versehen von Endnutzerstationen mit Zugriff
auf ein Portal. Insbesondere bezieht sich die Erfindung auf eine
Erfassung des Typs einer Endnutzerstation, die Zugriff auf eine
Portalstruktur anfordert, wenn die Portalstruktur in der Lage ist,
Zugriff durch verschiedene Typen von Endnutzerstationen zu unterstützen, derart,
dass der Endnutzerstation Zugriff auf das Portal erlaubt werden
kann.
-
STAND DER TECHNIK
-
Wenn auf ein Portal verwiesen wird,
ist allgemein ein Internet-Portal gemeint. Heute wird viel Anstrengung
bei Personalisierung und Kundenanpassung der Wege verbracht, auf
denen ein Endnutzer mit Zugriff zu Diensten versehen werden sollte,
ungeachtet des tatsächlichen
Standorts der Dienste oder Anwendungen. Zur gleichen Zeit gewinnt
die Nachfrage nach Zugriff auf mobile Internetdienste an Bedeutung,
d.h. die Endnutzer müssen
in der Lage sein, auf eine rasche und unkomplizierte Art und Weise Zugriff
zu Diensten von einer beliebigen Endnutzerstation zu erhalten, d.h.
auch von mobilen Vorrichtungen; es kann sich z.B. auf Senden und
Empfangen von E-Mails, Kurznachrichten, Zugriff auf WEB-basierte
Information von mobilen ebenso wie von stationären Endnutzervorrichtungen
auf eine benutzerfreundliche, schnelle und einfache Art und Weise
beziehen. Dies wird das mobile Internet genannt.
-
Browsen unter Verwendung der mobilen
Vorrichtung ist jedoch schwieriger als Browsen unter Verwendung
eines PC, da die mobile Vorrichtung im Vergleich zu dem PC begrenzte
Eingabe- und Ausgabefähigkeiten
hat; dies bedeutet somit, dass es noch schwieriger wird, mobile
Endnutzer mit einer befriedigenden Personalisierung und Verwaltung
vom Zugriff auf Dienste zu versehen. Somit gibt es eine steigende
Nachfrage im Namen von Endnutzern, stets in der Lage zu sein, auf
Anwendungen und Dienste zuzugreifen. Ein Portal ist eine derartige
Tür zu
dem Inhalt von Diensten und Anwendungen, die insbesondere maßgeschneidert
sein sollte, um auf die Endnutzerpräferenzen zu passen.
-
Beispiele vom Portalinhalt sind Informationsdienste
(auch inkludierend Anschubinhalt (push content), der sich auf eine
Internettechnik bezieht, durch die alle Information, die ein Benutzer
abonniert, dem den Benutzer automatisch bereitgestellt wird, oder Information,
von der der Dienstanbieter oder Betreiber meint, dass sie dem Benutzer
bereitgestellt werden sollte). Beispiele für Informationsdienste sind Wettervorhersagen
oder Wetterinformation im allgemeinen, kommerzielle Dienste, wie
etwa Einkaufszentren, oder allgemein eine beliebige Art von Information,
Multimediadienste, wie etwa Audio-/Video-Streaming, Spiele, Sofortnachrichten
und Newsgroups (Nachrichtengruppen), WEB-basierte Post, Zugriff
zu bestimmten Gemeinschaften durch Chatrooms (Gesprächsräume). Es
ist höchst
wünschenswert
in der Lage zu sein, anziehende grafische Benutzerschnittstellen
zum Darstellen von Anwendungen und Menüs auf PCs vorzusehen, und insbesondere
auch für WAP-befähigte Vorrichtungen,
im Fall, dass ein Portal mobil ist. Es wird auch viel Anstrengung
bei Personalisierung der Struktur und des Inhalts von persönlichen
Portalen erbracht, und um eine Möglichkeit
vorzusehen, die Interaktion und das Verhalten von einzelnen Diensten
und Anwendungen durch Einstellen persönlicher Präferenzen zu steuern. Es hat
sich jedoch herausgestellt, dass es schwierig ist, befriedigende
Zugriffsmöglichkeiten vorzusehen,
ebenso wie befriedigende Navigationseigenschaften, ungeachtet der
Art einer Vorrichtung, die durch einen Endnutzer verwendet wird.
-
Ein Portalkern ist der zentrale Teil
der Portalstruktur, der benötigt
wird, um ein Portalrahmenwerk zu entwickeln, innerhalb dessen Inhalt
und Anwendungen offengelegt und auf die durch Endnutzer auf eine
gesteuerte und vereinheitlichte Art und Weise zugegriffen werden
kann.
-
Bis jetzt werden viele Anwendungen
im Prinzip exklusiv für
die 2G-Telekommunikationsumgebung gestaltet, und sie wurden als
monolithische Blöcke
implementiert oder mit einem proprietären Dienstnetz, um die spezifischen
QoS-Anforderungen (Qualitätsstandard)
für die
jeweiligen Anwendungen zu handhaben. Dies hat zur Folge, das derartige
Anwendungen als isolierte Anwendungen befriedigend arbeiten, dass
sie aber schwierig mit anderen Anwendungen zu integrieren sind,
die auf ähnlichen Wegen
entwickelt werden. Anwendungen, die für die Internet- (Internetprotokoll)
Umgebung entwickelt werden, basierten zu einem großen Ausmaß auf festgesetzten
und offenen de facto Standards, die eine extensive Integration von
unterschiedlichen Anwendungen unterstützen. Viele derartige Standards
wurden in der 2G-Umgebung für
nicht-echtzeitkritische Anwendungen verwendet. Durch die Einführung von 3G-Netzen
(3GPP) werden zukünftige
Anwendungen jedoch eine Mischung von Telekommunikations- und Datenkommunikationsdiensten
enthalten, wobei höhere
und niedrigere Bitraten ebenso wie Echtzeit- und Nicht-Echtzeit-Verkehr
gemischt werden. Die Dienstnetze von heute sind nicht gestaltet,
derartige Mischungen zu handhaben, noch sind die existierenden IP-basierten
Anwendungen für
die speziellen Charakteristika von drahtlosen Netzen gestaltet.
Wie gesehen werden kann, gibt es viele Faktoren, die die Bereitstellung
von befriedigendem Zugriff für
Endnutzer auf Dienste/Anwendungen verkomplizieren.
-
Durch Verwendung einer generischen Textauszeichnungssprache
in einem Portal kann ein Inhalt von Anwendungen und Diensten unabhängig von
einer Endnutzerstation oder Benutzervorrichtung gespeichert werden,
und bevor der Inhalt einer Anwendung oder eines Diensts gezeigt
wird, kann der Inhalt zu einem Format transformiert werden, d.h.
der Textauszeichnungssprache, das durch die Endnutzervorrichtung
verstanden werden kann. Ein Beispiel einer derartigen generischen
Textauszeichnungssprache ist die XML (erweiterte Textauszeichnungssprache,
Extended Markup Language). Somit können durch Verwendung einer
generischen Textauszeichnungssprache verschiedene Arten von Endnutzerstationen
mit Zugriff auf das Portal versehen werden. XML wird in Extended
Markup Language (XML) 1.0 (zweite Ausgabe) beschrieben, die eine W3C-Empfehlung
vom 6. Oktober 2000 ist, die hiermit hierin durch Bezugnahme einbezogen
wird.
-
Internetportale sehen gewöhnlich einen
Vorrichtungserfassungsmechanismus zum Erfassen vor, welche Art oder
Typ einer Endnutzerstation ein Endnutzer verwendet, sodass der Benutzer,
der auf das Portal zugreift, auf die geeigneten Inhaltsseiten gelenkt
werden kann, z.B. die geeignete Textauszeichnungssprache, die durch
die Endnutzerstation verwendet wird. Eine mobile Endnutzerstation,
wie etwa eine WAP-Vorrichtung (drahtloses Anwendungsprotokoll, Wireless
Application Protocol) verwendet z.B. WML (drahtlose Textauszeichnungssprache,
Wireless Markup Language), wohingegen für eine stationäre Endnutzerstation
HTML (Hypertext-Auszeichnungssprache, Hyper Text Markup Language)
verwendet werden kann. Gleichermaßen erfordern derartige vorrichtungsunabhängige Portale,
die auf einer generischen Textauszeichnungssprache basieren, wie
etwa XML, Vorrichtungsinformation, d.h. Endnutzerstationsinformation,
um in der Lage zu sein, Inhalt für
die Endnutzerstation dynamisch zu generieren. Falls die Endnutzerstation
nicht richtig erfasst werden kann, dann wird der Benutzer gewöhnlich mit
einem Systemfehler konfrontiert, was eine schlechte Erfahrung ist
und was Benutzerfluktuation bewirken kann. Vorrichtungserfassungsverfahren
für HTTP (Hypertext-Übertragungsprotokoll,
Hyper Text Transfer Protocol), das das Zugriffsprotokoll ist, das
durch eine Endnutzerstation verwendet wird, die auf ein Portal zugreift,
werden in verschiedenen Spezifikationen spezifiziert, wie etwa z.B.
die Servlet-Sitzungs-API.
Die Erfassungsverfahren basieren allgemein auf einer Verwendung
von Vorrichtungsdatenbanken. Derartige Verfahren nutzen die Information, die
mit dem HTTP-Nachrichtenkopf übertragen
werden, um die unterliegende Vorrichtung wie folgt zu erfassen:
- 1. Den Benutzer-Agenten erhalten, der in dem HTTP-Kopf
gespeichert ist.
- 2. Versuchen, Vorrichtungsinformation (unter Verwendung einer
Datenbank) abzufragen, wobei der Benutzer-Agent als ein Schlüssel verwendet
wird.
- 3. Im Fall eines Fehlers versuchen, die akzeptierten MIME-Typen
zu lesen.
- 4. Versuchen, weitere Vorrichtungsinformation abzufragen (unter
Verwendung einer Datenbank).
- 5. Im Fall eines Fehlers abbrechen.
-
- Wenn ein Benutzer auf ein Internetportal unter Verwendung
von HTTP zugreift, ist das Portal in der Lage, unter Verwendung
der Information, die in dem HTTP-Kopf gespeichert ist, verschiedene
Details über
die Vorrichtung des Benutzers abzufragen, z.B. den Benutzer-Agenten,
der ein einzigartiger Identifikator der Vorrichtung oder des Browsers
ist, den die Vorrichtung des Benutzers verwendet.
-
Die Portal- (Präsentations-) Engine (Maschine)
kann diese Information verwenden, um Inhalt zu präsentieren,
der auf die Vorrichtung des Benutzers angepasst ist. Wenn z.B. ein
Benutzer auf das Portal unter Verwendung eines WAP-Telefons zugreift,
wird das Portal unter Verwendung von WML antworten. Falls der Benutzer
auf das Portal unter Verwendung eines HTML-Browsers zugreift, wird
das Portal unter Verwendung von HTML antworten.
-
Solange wie die Vorrichtung des Benutzers richtig
erfasst werden kann, kann das Portal geeignet reagieren. Falls die
Vorrichtung jedoch nicht erfasst werden kann, d.h. nicht erkannt
wird, kann das Portal nicht in der Lage sein, in der geeigneten
Sprache zu antworten, oder schlechter noch einen Systemfehler in
der Vorrichtung des Benutzers durch Antworten in der falschen Sprache
erzeugen.
-
WO 00/65773 zeigt ein Portal, welches
(ausschließlich)
WEB-basiert ist.
Auf das Portal kann nur durch einen einzelnen Typ von stationären Vorrichtungen
(WEB-Browsern) zugegriffen werden, die eine Strukturierte HTML-Textauszeichnungssprache verstehen.
Es ist ein gewichtiger Nachteil, dass nur auf einen speziellen Typ
von Vorrichtungen zugegriffen werden kann. Die Literaturstelle legt
keine zuverlässige
Vorrichtungserfassung offen.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Was benötigt wird, ist deshalb eine
Portalstruktur, die in der Lage ist, auf einem zuverlässigen Weg
Endnutzerstationen verschiedener Typen oder Arten mit Zugriff auf
das Portal zu versehen. Insbesondere wird eine Portalstruktur benötigt, die
eine Erfassung von Endnutzerstationen ermöglicht, derart, dass Zugriff
auch für
Endnutzerstationen erlaubt werden kann, die dem Portal nicht speziell
bekannt sind. Insbesondere wird eine zuverlässige Vorrichtungserfassung
in einer Portalstruktur benötigt,
die mobil ist und für
die das HTTP-Zugriffsprotokoll verwendet wird (Hypertext-Übertragungsprotokoll).
-
Außerdem wird eine Portalstruktur
benötigt, die
eine generische Erfassung von Endnutzerstationen in einer mobilen
Portalstruktur vorsieht, oder insbesondere eine Portalstruktur,
die eine generische Textauszeichnungssprache verwendet, ganz besonders
XML.
-
Ferner noch wird eine Portalstruktur
benötigt,
die nicht die Bereitstellung von Information in Bezug auf alle speziellen
Endnutzerstationstypen erfordert, denen Zugriff gegeben werden sollte,
bevor sie aktiviert oder in Betrieb gesetzt wird. Insbesondere wird
eine Portalstruktur benötigt,
die nicht Information über
jeden speziellen Endnutzerstationstyp unterhalten muss, dem Zugriff
auf das Portal erlaubt werden sollte. Weiter noch wird eine Portalstruktur
benötigt, die
fähig ist,
Endnutzerstationen verschiedener Typen einen unkomplizierten und
schnellen Zugriff vorzusehen.
-
Es wird auch eine Anordnung in einer
Portalstruktur für
eine Endnutzerstationserfassung benötigt, durch die ein oder mehr
der oben erwähnten
Ziele erreicht werden können.
Weiter noch wird ein Verfahren zum Versehen von Endnutzerstationen
von einer Anzahl von unterschiedlichen Typen mit Zugriff auf eine Portalstruktur
auf einem zuverlässigen
Weg benötigt,
durch das ein oder mehr der oben erwähnten Ziele erfüllt werden
können.
-
Bevor die Spezifika der vorliegenden
Erfindung angegeben werden, werden im folgenden einige Konzepte,
die in diesem Dokument verwendet werden, beschrieben oder definiert.
Ein Portal ist allgemein eine nicht-physische Entität in der
Internet-Domäne, die
als ein "elektronischer
Veröffentlichungsraum" beschrieben werden
kann, der im Besitz durch ein Individuum oder eine Organisation
ist, der/die entweder direkten Zugriff zu Information und Diensten
vorsieht, oder Verweise auf andere Entitäten im Internet oder private
Intranet-Domänen,
die autorisierten Endnutzern Information und Dienste vorsehen. Ein
Portal ist in seiner einfachsten Form eine reguläre Homepage oder Liste von
Verweisen, wohingegen es in fortgeschritteneren Formen interaktive
Dienste anbieten kann, nicht nur jenen, die konsumieren, was veröffentlicht
wird, sondern auch jenen, denen durch den Herausgeber das Recht
erteilt wird, auf dem Portal zu veröffentlichen, ebenso wie dem
Herausgeber selbst, in Bezug auf verschiedene Aspekte dazu, wie
das Portal verwendet wird.
-
Drahtlosen Endnutzern wird Zugriff
durch ein "Dienst"-Portal gegeben.
Ein derartiges Dienstportal unterscheidet sich von einem traditionellen
stationären
Internet-Portal für
PCs und Endnutzer fordern, dass personalisierte Dienste ihrem mobilen
Endgerät zugestellt
oder auf ihm dargestellt werden, mindestens als eine Option. In
diesem Dokument jedoch wird eine Portalstruktur angenommen, sowohl
ein "gewöhnliches" Portal als auch
ein "Dienst"-Portal zu bestimmen.
-
Eine Anwendung ist eine oder mehrere
kooperierende Softwareentitäten,
wobei der Funktionsschwerpunkt Benutzerinteraktion und Nützlichkeit
für den
Endnutzer ist. Eine Anwendungsplatt form ist eine definierte Kombination
von Software- und Hardwareentitäten,
die verwendet werden, um Anwendungen einer bestimmten Art zu implementieren,
die durch die Funktionalität
und Qualität
ihrer Bestandteile charakterisiert sind.
-
Mit Portalinfrastruktur sind im allgemeinen Sinne
die Software- und Hardwareentitäten
gemeint, die benötigt
werden, um ein spezielles Portal entweder zu beherbergen oder zu
erzeugen oder zu generieren. Speziell enthält sie einen Portalkern, eine IP-Infrastruktur
und Dienstbefähiger.
-
Ein Dienstbefähiger ist eine Unterstützungsfunktionalität, auf die über APIs
(Anwendungsprogrammierschnittstelle) zugegriffen wird, was den Abstraktionsgrad
anhebt und die Aufgabe von Anwendungsentwicklern vereinfacht. Ein
Portalkern ist der Kern einer Portalinfrastruktur. Mit einem Dienstnetz ist
allgemein ein IP-basiertes Netz gemeint, das aus Knoten besteht,
die Anwendungsserver, Dienstbefähigungsserver,
Anwendungsunterstützungsserver, IP-Infrastrukturserver
etc. beherbergen. Anwendungsunterstützungsserver verbinden sich
mit Dienstnetzressourcen oder anderen externen Ressourcen als Kernnetzen,
wohingegen sich Dienstbefähigungsserver
mit Ressourcen und Funktionalität
in Kernnetzen verbinden.
-
In der vorliegenden Anmeldung ist
eine Portalstruktur gedacht, einen Portalkern, eine Vielzahl von
Diensten und Anwendungen mit ihrem Inhalt und Dienstbefähigungsmittel
(Dienstbefähiger)
zu bedeuten. Allgemein kann auch die Konnektivitäts- und Datenträgerfunktionalität als inkludiert
angesehen werden.
-
Um die oben bezeichneten Probleme
zu lösen,
sieht die vorliegende Erfindung eine Portalstruktur vor, die Zugriff
durch Endnutzerstationen unter Verwendung eines Zugriffsprotokolls
für Zugriffsanforderungen
unterstützt.
Die Zugriffsanforde rungen enthalten Information über die Endnutzerstationen. Die
Information umfasst Basisinformation, die Gruppen- oder Klassenzugehörigkeit(en)
der anfordernden Endnutzerstation spezifiziert, und Typinformation,
die den Typ der anfordernden Endnutzerstation spezifiziert. Die
Portalstruktur umfasst einen Portalkern mit Portalsitzungsverwaltungsmittel,
Anforderungshandhabungsmittel (Anforderungsvermittler) und Portalspeichermittel
zum Speichern von mindestens Typinformation für mindestens einige Typen von Endnutzerstationen.
Sie umfasst ferner eine Vorrichtungserfassungsanordnung. Das Portalspeichermittel
unterstützt
eine Speicherung von Basisinformation, wie etwa Gruppen oder Klassen.
Falls der Typ einer anfordernden Endnutzerstation durch die Portalstruktur
nicht erkannt wird, dann wird festgestellt, ob dem Portal die Klasse(n)/Gruppe(n)
bekannt ist/sind. Falls ja, verwendet die Erfassungsanordnung die Klassen-/Gruppeninformation
in Bezug auf die Endnutzerstation, um Typinformation von der Endnutzerstation
anzufordern. Diese Typinformation wird, wenn abgefragt, in das Portalspeichermittel
gespeichert, und der Endnutzerstation wird Zugriff auf das Portal gegeben.
Das Zugriffsprotokoll ist insbesondere HTTP. Die Portalstruktur
ist eine vorteilhafte Implementierung basierend auf einer generische
Textauszeichnungssprache, die Zugriff durch Endnutzerstationen unabhängig von
Typ/Klasse der Endnutzerstation unterstützt. Die generische Textauszeichnungssprache
ist genauer noch XML.
-
Die Portalstruktur umfasst Wiedergabemittel zum Übersetzen
von Dienst-/Anwendungsdaten von einem Dienst/Anwendung, auf den/die
zugegriffen wird, der/die eine generische Textauszeichnungssprache
verwendet, in die Textauszeichnungssprache, die durch die zugreifende
Endnutzerstation verwendet wird. Die Klassen-/Gruppeninformation
umfasst insbesondere Information in Bezug auf die Textauszeichnungssprache,
die durch die anfordernde Endnutzerstation verwendet wird, oder
insbesonde re Information in Bezug auf Textauszeichnungssprachen,
die für
die Endnutzerstation verständlich sind.
Die Portalstruktur ist vorzugsweise mobil, was bedeutet, dass sie
Zugriff durch mobile ebenso wie stationäre Endnutzerstationen unterstützt, wie
etwa WAP-Vorrichtungen, die WML verwenden, und PCs, die HTML verwenden.
Die Typinformation umfasst insbesondere einen so genannten Benutzeragenten, der
die Endnutzerstation einzigartig identifiziert, oder genauer den
Browser, der durch die Endnutzerstation verwendet wird.
-
Eine Endnutzerstation ist insbesondere
eine Entität,
die auf das Portal zugreift. Mit jeder Endnutzerstation steht Vorrichtungsinformation
in Verbindung. Jede Endnutzerstation oder Vorrichtung gehört zu einer
Klasse (mindestens einer), die eine bestimmte Textauszeichnungssprache
verwendet, wie etwa z.B. WML, HTML, und sie umfasst auch einen Benutzeragenten,
z.B. Ericsson R380/WAP1.1, der die Vorrichtung genauer spezifiziert.
-
In einer bevorzugten Implementierung
umfasst das Portalspeichermittel eine Endgerätedatenbank. Falls die Typanzeige,
der Benutzeragent, in einer Endnutzeranforderungsnachricht erkannt
oder in dem Portalspeichermittel gefunden wird, wird die entsprechende
Typinformation durch den Anforderungsvermittler zum Speichern in
eine Endnutzerportalsitzung abgeholt, die durch das Portalsitzungsverwaltungsmittel
erstellt wird, sobald wie Zugriff erlaubt ist.
-
Falls die Typanzeige (Benutzeragent)
in einer Endnutzeranforderungsnachricht nicht erkannt oder in dem
Portalspeichermittel gefunden wird, stellt der Anforderungsvermittler
fest, ob die Klasse, wie durch die Anforderungsnachricht angezeigt,
in dem Portalspeichermittel verfügbar
ist. Dies bedeutet, dass untersucht wird, ob die Klasse oder Gruppe, oder
ob beliebige der Klassen/Gruppen (falls die Endnutzerstation mehr
als eine Klasse oder Gruppe unterstützt) durch die Portalstruktur
unterstützt
werden. Falls dies der Fall ist, gibt er Information über die Klasse/Gruppe
zu der Vorrichtungserfassungsanordnung weiter. Die Vorrichtungserfassungsanordnung präsentiert
dann der Endnutzerstation eine Konfigurationsseite, die eine Endnutzertypinformationseingabe
von der Endnutzerstation anfordert. Wenn die angeforderte Endnutzerstationstypinformation
in der Vorrichtungserfassungsanordnung empfangen wurde, wird sie
in das Portalspeichermittel gespeichert.
-
Dies wird zur Folge haben, dass das
nächste Mal,
wenn eine Endnutzerstation des gleichen Typs Zugriff auf das Portal
anfordert, der Typ tatsächlich
in dem Speichermittel gefunden wird, und Zugriff gegeben werden
kann, ohne weitere Information von der Endnutzerstation anfordern
zu müssen.
Somit wurde das Portal allgemein mit einem neuen Typ einer Endnutzerstation
aktualisiert. Dies bedeutet, dass die Portalstruktur dadurch adaptiv
oder selbstlernend ist, dass sie mehr und mehr Typen von Vorrichtungen
erkennen wird.
-
Die Klasseninformation umfasst insbesondere
Information über
die Textauszeichnungssprache, die durch die Endnutzerstation verwendet
wird. Dies erlaubt der Vorrichtungserfassungsanordnung, mit der
Endnutzerstation zu kommunizieren, was erklärt, warum die Vorrichtungserfassungsanordnung
in der Lage ist, zu kommunizieren mit und ferner Information anzufordern
von dem bisher unbekannten Endnutzerstationstyp.
-
Die Erfindung sieht auch eine Anordnung
für eine
Endnutzerstationserfassung oder Erkennung in einer Portalstruktur
umfassend Portalsitzungsverwaltungsmittel, Portalspeichermittel
und Anforderungshandhabungsmittel vor. Die Anordnung umfasst eine Endnutzerstations-
(Vorrichtungs-) Erfassungsanordnung zum Erfassen, ob Klassen- (Gruppen-)
Information in Bezug auf die Endnutzerstationsklassenzugehörigkeiten,
wie etwa die Textauszeichnungssprache, die durch die Endnutzerstation
verwendet wird, in der Portalstruktur enthalten ist, und falls ja,
Verwenden der Textauszeichnungssprache der Endnutzerstation zum
Anfordern und Abrufen weiterer Information in Bezug auf den Endnutzerstationstyp
von der Endnutzerstation, und zum Speichern derartiger Typinformation
in das Portalspeichermittel. Die Anordnung verwendet insbesondere
Information über Endnutzerstationsklassen-
(Gruppen-) Zugehörigkeit,
die in der Endnutzerstationsanforderung inkludiert ist, wie durch
das Zugriffsprotokoll unterstützt, das
insbesondere das HTTP ist, in welchem Falle derartige Information
in dem HTTP-Kopf enthalten ist. Das erfinderische Konzept ist natürlich nicht
auf das HTTP-Protokoll begrenzt, sondern es kann ein beliebiges
Protokoll verwendet werden, das Information über Klassen- oder Gruppenzugehörigkeit einer Endnutzerstation
inkludierend die verwendete Textauszeichnungssprache und spezieller
angegebene Typinformation enthält.
-
Die Portalstruktur verwendet vorzugsweise eine
generische Textauszeichnungssprache, wie etwa XML, und es wird Zugriff
durch mobile ebenso wie stationäre
Endnutzerstationen unterstützt.
-
Die Erfindung sieht auch ein Verfahren
zum Versehen einer Endnutzerstation mit Zugriff auf eine Portalstruktur
durch Erfassung von Charakteristika, z.B. Typ, einer Endnutzerstation,
die Zugriff anfordert, vor. Das Verfahren umfasst die Schritte:
Empfangen einer Endnutzerstationsanforderung in der Portalstruktur,
wobei die Anforderung Information in Bezug auf einen Typ einer Endnutzerstation
und Basisinformation in Bezug auf Klassen-/Gruppenzugehörigkeit(en)
der Endnutzerstation enthält;
Untersuchen, ob es beliebige Information über den Typ der Endnutzerstation
in dem Portal gibt, wohingegen falls ja, der Endnutzerstation erlaubt
wird, auf das Portal zuzugreifen, anderenfalls; Untersuchen, ob
es belie bige Information über
die Klasse(n)/Gruppe(n) gibt, zu der die Endnutzerstation gehört, d.h.
ob das Portal (beliebige von) die (den) Klasse(n)/Gruppe(n) , zu
der (den) die Endnutzerstation gehört, unterstützt; falls ja, Verwenden der
erkannten Klassen-/Gruppeninformation, um weitere Information in
Bezug auf den Typ der Endnutzerstation von der Endnutzerstation
abzufragen; Speichern der abgefragten Typinformation in dem Portalspeichermittel;
Erlauben der Endnutzerstation, auf das Portal zuzugreifen.
-
Vorzugsweise wird das HTTP-Protokoll
für die
Zugriffsanforderung einer Endnutzerstation verwendet, und das Portal
verwendet insbesondere eine generische Textauszeichnungssprache,
z.B. XML, und unterstützt
Zugriff durch mobile ebenso wie stationäre Endnutzerstationen, z.B.
unter Verwendung von WML bzw. HTML als Textauszeichnungssprache.
Die Klasseninformation umfasst insbesondere Information in Bezug
auf die Textauszeichnungssprache(n), die durch die Endnutzerstation
verwendet/unterstützt
wird (werden).
-
Der Schritt zum Untersuchen, ob der
Typ einer anfordernden Endnutzerstation dem Portal bekannt ist,
umfasst die Schritte: Untersuchen, ob der Typ in dem Portalspeichermittel
gespeichert ist, z.B. einer Endgerätedatenbank, und die Schritte
zum Untersuchen, ob beliebige der Klasse(n)/Gruppe(n), die das Portal
kennt, umfassen; Untersuchen, ob die Klasse/Gruppe in dem Portalspeichermittel
gespeichert ist, z.B. einer Endgerätedatenbank.
-
Der Schritt zum Abfragen weiterer
Information von der Endnutzerstation umfasst insbesondere: Abholen
der Klasse/Gruppe, umfassend Textauszeichnungsspracheninformation,
von dem Portalspeichermittel zu einer Endnutzerstations- (Vorrichtungs-)
Erfassungsanordnung; Verwendung der Textauszeichnungssprache in
der Erfassungsanordnung gemäß der Klassen-/Gruppeninforma tion,
um der Endnutzerstation eine Konfigurationsseite zu präsentieren;
Empfangen angeforderter Konfigurationsdaten von der Endnutzerstation
in der Vorrichtungserfassungsanordnung; Speichern der empfangenen Konfigurationsdaten
in das Portalspeichermittel; Erlauben der Endnutzerstationen, auf
das Portal zuzugreifen.
-
Es ist ein Vorteil der Erfindung,
dass ein generischer fehlertoleranter Vorrichtungserfassungsmechanismus
vorgesehen wird, insbesondere für Portale,
die eine generische Textauszeichnungssprache verwenden, wie etwa
XML. Wenn eine Endnutzerstation nicht erfasst werden kann, d.h.
wenn sie durch ein Portal nicht erkannt wird, kann die Vorrichtungsklasse,
oder eine der Vorrichtungsklassen, d.h. Endnutzerstationsklasse,
verwendet werden, um einem Portal zu erlauben, weitere Information über die Endnutzerstation
durch Präsentieren
dem Benutzer einer Konfigurationsseite zu erhalten. Eine Implementierung
einer derartigen Vorrichtungserfassungsanordnung oder Anwendung
als solche ist einfach, und sie beseitigt die Notwendigkeit, ein
Portalspeichermittel, insbesondere eine Endgerätedatenbank, mit allen verfügbaren Endgeräten oder
Endnutzerstationen füllen
zu müssen,
bevor ein Portal in Betrieb genommen wird. Weiter noch macht sie
es möglich, Endnutzerstationen,
die der Portalstruktur nicht bekannt sind, und zukünftigen
Endnutzerstationen Zugriff vorzusehen, solange wie die verwendeten
Zugriffsprotokolle die Bereitstellung von Klasseninformation unterstützen und
unter einer Bedingung, dass die Klasseninformation in einem Speichermittel
in oder in Verbindung mit einer Portalstruktur gespeichert wird.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die Erfindung wird im folgenden auf
eine nicht-begrenzende Art und Weise und mit Bezug auf die begleitenden
Zeichnungen weiter beschrieben, in denen:
-
1 einen Überblick
einer Portalstruktur schematisch veranschaulicht, in der das erfinderische
Konzept implementiert werden kann,
-
2 eine
konzeptionelle Unterteilung einer Präsentationsanordnung (Schicht)
in eine Wiedergabefunktionsschicht und eine Dienstfunktionsschicht veranschaulicht,
-
3 ein
Blockdiagramm ist, das den Portalkern, zu dem eine Endnutzerstation
Zugriff anfordert, mit einer Vorrichtungserfassungsanordnung gemäß der Erfindung
beschreibt,
-
4 ein
Flussdiagramm ist, das die erfinderische Prozedur beschreibt, wenn
eine Endnutzerstation auf eine Portalstruktur zugreift, und
-
5 ein
Diagramm ist, das die Interaktionen innerhalb des Portalkerns veranschaulicht,
wenn eine Endnutzerstation von einem Typ, der nicht durch das Portal
erkannt wird, Zugriff anfordert.
-
DETAILLIERTE
BESCHREIBUNG DER ERFINDUNG
-
Mit Bezug auf 1 und 2 wird
eine beispielhafte Portalstruktur auf eine ziemlich definierte Art und
Weise beschrieben. Eine derartige Portalstruktur kann in der Implementierung
des erfinderischen Konzepts verwendet werden, das mit Bezug auf 3–5 beschrieben
wird. Es sollte jedoch auch klar sein, dass die Erfindung keineswegs
darauf begrenzt ist, in einem Portal implementiert zu werden, wie
in 1 und 2 beschrieben, wobei dieser Abschnitt
der Beschreibung hauptsächlich
für eine
Beschreibung einiger beispielhafter unterliegender Konzepte und
des Funktionierens einer beispielhaften Portalstruktur als solche
inkludiert ist.
-
1 zeigt
somit ein Beispiel einer Portalstruktur 10. Sie umfasst
einen Portalkern 1, der Präsentationsfunktionalitäten, Abonnement
und Sitzungsverwaltungsfunktionalitäten handhabt, eine Anzahl von
Diensten und Anwendungen 2, umfassend z.B. persönliche Kommunikationsdienste,
persönliche
Informationsdienste und mobile E-Kommerz-Dienste. Kurz gesagt ist
es für
das Funktionieren der vorliegenden Erfindung nicht wichtig, welche Typen
von Diensten vorgesehen werden, da die Erfindung mit Versehen von
Endnutzerstationen mit Zugriff auf die Portalstruktur befasst ist,
was eine Vorbedingung dafür
ist, eine Endnutzerstation mit Zugriff auf einen Dienst/Anwendung über die
Portalstruktur zu versehen.
-
Die Portalstruktur 1 inkludiert
ferner eine Schicht 3 inkludierend eine Anzahl von Dienstbefähigungsmitteln
(Dienstbefähiger) 31–37, 38A–38D.
Die Dienstbefähiger
sind unter anderen Dingen in eine Authentifizierung und Basisdienste
involviert, wie etwa Gateways und IP-Infrastruktur. In dieser Figur werden
einige Beispiele an Dienstbefähigern
angegeben, wie etwa vereinheitlichte Mitteilungsübermittlung 31, IP-Infrastruktur 32,
AAA-Server 33, Benachrichtigungsunterstützung 34, Gebührenerfassungsunterstützung 35 und
Operations- und Wartungsunterstützung 36.
Weitere Dienstbefähiger
beziehen sich hier auf ein mobiles Positionierungssystem 37, ein
WAP-Gateway 38A, SMS-C-Gateway 38B, einen Multimedia-Proxy 38C,
mobile E-Bezahlung 38D etc. Es
sollte klar sein, dass einige dieser Dienstbefähiger zwingend erforderlich
sind, wohingegen andere optional sind.
-
Die Portalstruktur ist hier auch
als eine Konnektivitäts- oder eine (mobile)
Trägerschicht
umfassend die mobilen Basisstationen und Vermittlungsknoten, wie
etwa Knoten für
BTS (Basis-Transceiver-Station), BSC (Basisstationssteuervorrichtung), MSC
(mobile Vermittlungsstelle) etc., zu sehen. Welche die Knoten sind,
hängt davon
ab, über
welches mobile Netz Zugriff vorgesehen wird, z.B. GSM. Für GPRS oder
UMTS sind in dieser Schicht entsprechende Knoten inkludiert; z.B.
GGSN (Gateway-GPRS-Unterstützungsknoten).
Was immer das Netzwerk ist, das Netzwerk ist der Datenträger für das Portal
für einen
Zugriff von mobilen Vorrichtungen, wie etwa WAP-Vorrichtungen (drahtloses
Anmeldungsprotokoll). In 1 wird
vorausgesetzt, dass die zugreifende Endnutzerstation ein WAP-Telefon 5 umfasst.
-
Ein Beispiel in einer derartigen
Portalstruktur ist das Ericsson WISET" Portal.
-
Es wird hier vorteilhafter Weise
vorausgesetzt, dass das Portal Zugriff durch mobile Endnutzerstationen,
wie etwa WAP-Telefone 5, über ein mobiles Netzwerk unterstützt. Deshalb
müssen
Knoten oder Komponenten des relevanten mobilen Netzes in einer Mobilnetzkonnektivitäts- und
Datenträgerschicht
vorgesehen werden. In 1 wird
eine Komponente, bezeichnet als ISP-Netz, Internet-Dienstanbieter-Netz
(Internet Service Provider network), offengelegt. Dies ist eine
optionale Komponente, die inkludiert sein kann oder nicht.
-
Einige der Dienstbefähiger sind
wichtige Komponenten zum Vorsehen von mobilen Internetfunktionalitäten und
einige von ihnen können
als ein Teil der Schnittstellenkomponenten zwischen Internet und
dem mobilen Netz gesehen werden. Eine Komponente wird hier als IP-Infrastruktur 32 bezeichnet.
Ein optionaler Dienstbefähiger
umfasst die Benachrichtigungsunterstützung 34, die allgemein
eine optionale Komponente ist, die Anwendungen ermöglicht,
ausgefilterte Benachrichtigungen zu Endnutzern unter Verwendung
des SMS- (Kurznachrichtendienst) Kanals zu senden, sie kann aber
auch angepasst sein, andere Kanäle
zu inkludieren, die WAP-Technologie und 3G- (3GPP) Technologie unterstützen. Gebührenerfassungsunterstützungs befähiger 35 kann
vorgesehen sein, um flexibel Gebührenerfassungsereignisse
auszuwählen.
130Ein anderer Dienstbefähiger 36 bezieht
sich auf Operations- und Wartungsunterstützung und ist allgemein eine
zwingend erforderliche Komponente. Ein Dienstbefähiger WAP-Gateway 38A bezieht
sich auf einen optionalen Dienstbefähiger WAP-Gateway/Proxy, der
den Zugriffspunkt zwischen der drahtlosen Welt und der Internetwelt
bildet. Er unterstützt mobile
Clients, die auf den WAP-Gateway/Proxy unter Verwendung von GSM-schaltungsvermittelten Daten
oder WAP über
SMS (SMS über
MAP (mobiles Anwendungsprotokoll)) zugreifen. Der Client verwendet
einen WAP-befähigten
Browser in der mobilen Vorrichtung, um sich mit dem WEB-Server zu
verbinden, wo die gewünschte
WAP-Anwendung angesiedelt ist. Das mobile Positionierungssystem 37 ist
eine optionale Komponente, die ein Senden der Position eines Benutzers
zu der Anwendung erlaubt, die es anfordert. Der optionale Dienstbefähiger Multimedia-Proxy 38C ist
verantwortlich für
eine Sendung von Multimediadaten über GPRS oder UMTS. SMS-C (Zentrum)
Gateway 38B ist eine optionale Komponente, die für eine Sendung
oder Empfang, Speicherung und Weiterleitung von Kurznachrichten zwischen
Mobilstationen und Servern verantwortlich ist. Es werden proprietäre Protokolle
für eine
Kommunikation mit Anwendungen verwendet. Mobile E-Bezahlung 38D ist
eine Komponente, die die Basisfunktionalität für mobilen E-Kommerz anbietet
und sie ist optional. AAA-Server 33 ist eine Dienstbefähigungskomponente
in Bezug auf Authentifizierung, Authorisierung und Abrechnung. Diese
Funktionalitäten
können
auf andere Art und Weise vorgesehen werden, sie können aber
auch in einem Funktionalitätsserver
integriert sein, der z.B. verkehrsbasierte Gebührenerfassung und Periodengebührenerfassung
ermöglicht.
Eine derartige Komponente ist, ob sie entweder in verschiedene Komponenten
gesplittet ist oder ob sie eine einzelne Komponente umfasst, die
für eine
Anzahl von Funktionalitäten
gemeinsam ist, zwingend erforderlich, und in einer vorteilhaften Implementierung
wird die für
Sitzungsverwaltungsfunktionalitäten
verwendet.
-
Es sollte jedoch klar sein, dass 1 lediglich Beispiele für Dienstbefähigungsmittel
zeigt, die in einer Dienstbefähigungsschicht 3 vorgesehen
sein können.
-
Der Portalkern handhabt, wie oben
berichtet, Präsentation,
Abonnement und Sitzungsverwaltung und Dienststufen, die eine Anzahl
von internen (und externen) Anwendungsservern umfassen. Der Kern 1 umfasst
eine Präsentationsanordnung 11 (auch Präsentationsengine
oder Portalengine genannt), die mobile Portalpräsentation in mehrfachen Vorrichtungen
unter Verwendung mehrfacher Protokolle ermöglicht. Sie kann z.B. XML-angesteuert
sein (oder allgemeiner durch eine generische Textauszeichnungssprache
angesteuert werden). In einer Ausführungsform ist es ein durch
JavaTM und XML angesteuerter Präsentationsmodul,
der zu einer Multitextauszeichnungssprache fähig ist.
-
Die Präsentationsanordnung 11 umfasst
ein Wiedergabemittel, das in einer Implementierung XML-/XSLT-Technologien
verwendet um sicherzustellen, dass Information, die durch Dienste
innerhalb des Portals präsentiert
wird, auf einem standardisierten Weg ungeachtet dessen angezeigt
wird, welche Endnutzerstation ein Endnutzer verwendet, wenn er auf
die Portalstruktur zugreift. Durch die Verwendung einer generischen
Textauszeichnungssprache, z.B. XML/XSLT, kann das "Aussehen und Gefühl" ("look and feel") vom Inhalt, der
Endnutzern präsentiert wird,
kundenangepasst werden. Die schwedische Patentanmeldung "An arrangement and
a method for presentation customization in a portal structure", die eine Anmeldung
ist, die zum gleichen Datum und durch den gleichen Anmelder wie
die vorliegende Anmeldung eingereicht ist, und deren Inhalt hiermit durch
Bezugnahme hierin einbezogen ist, bezieht sich auf Benutzeranpassung
in einer Portalstruktur, wie hierin beschrieben, und befasst sich
insbesondere mit einer Kundenanpassung von "Aussehen und Gefühl". XSL wird in XSL-Transformations (XSLT) Version
1.0, W3C-Empfehlung vom 16. November 1999, und XSL-Transformations
(XSLT) Version 1.1, W3C-Arbeitsentwurf vom 12. Dezember 2000 beschrieben,
wobei die Dokumente hiermit hierin durch Bezugnahme einbezogen werden.
-
Die Funktionalitäten innerhalb des Portalkerns 1 allgemein
und der Präsentationsanordnung 11 insbesondere
werden mit Bezug auf 2 weiter beschrieben.
-
Der Portalkern 1 inkludiert
auch den Abonnementverwalter. In einer Implementierung wird Abonnementverwalter-Komponenteninformation
in einem LDAP- (leichtgewichtiges Verzeichniszugriffsprotokoll,
Lightweight Directory Access Protocol) Verzeichnis gespeichert und
wird durch einen Dienst, der Abonnementverwalter genannt wird, verwaltet.
Der Abonnementverwalter inkludiert Funktionen für den Betreiber, um Teilnehmerinformation
in der Teilnehmer- (Endgeräte-)
Datenbank zu erstellen, zu unterhalten und zu löschen. Er ermöglicht dem
Endnutzer des Systems auch, sich bei den Diensten in dem System
zu registrieren. In einer besonderen Implementierung wird ein Konzept
für Selbstregistrierung
und Selbstservice unterstützt,
um Kosten durch Minimieren der Arbeitsbelastung in einem Kundenbetreuungszentrum
zu minimieren. Information über
verfügbare
Dienste kann auch in dem oben bezeichneten Verzeichnis unterhalten
und durch den Abonnementverwalter gehandhabt werden. Wie ein neuer
Dienst in das Verzeichnis eingetragen wird, wird er unmittelbar
für ein
Abonnement durch die Endnutzer verfügbar sein. In dem Verzeichnis
können
Endnutzer derart gruppiert werden, um neue Dienste nur definierten Mengen
von Endnutzern verfügbar
zu machen. Der Abonnementverwalter 12 kann sich mit einem
existierenden Kunden betreuungssystem durch die Anwendungsprogrammierschnittstelle
(API), die er verwendet, verbinden.
-
Der Sitzungsverwalter 13 ist
ein allgemeiner Mechanismus, der durch Anwendungen und Dienste verwendet
werden kann. Er umfasst eine Schnittstelle zu einem Teilsystem zum
Verfolgen aller Besucher auf dem Portal und um die Profilinformation
der Besucher bereitzustellen. Wenn ein Endnutzer das Portal zum
Zugreifen auf eine Anwendung/einen Dienst betritt, wird eine Sitzungs-Id-Entität zugeordnet,
die für
diesen besonderen Endnutzer gespeichert wird, bis er sich von dem
Dienst abmeldet, oder wenn der Endnutzer für eine voreingestellte Zeitdauer
untätig gewesen
ist. Wenn eine teilnehmende Anwendung beginnt zu laufen, überprüft sie zuerst,
ob es eine aktive Sitzungs-Id für
einen bestimmten Benutzer gibt, und falls es eine gibt, würde sie
in der Lage sein, von dort wieder zu beginnen, wo die Sitzung unterbrochen
wurde. Sitzungsverwaltungsfunktionalitäten werden z.B. in "An Arrangement and
a Method Relating to Session Management in a Portal Structure" beschrieben, was
eine schwedische Patentanmeldung ist, die zum gleichen Datum und
durch den gleichen Anmelder wie die vorliegende Anmeldung eingereicht
wurde, deren Inhalt hiermit durch Bezugnahme hierin einbezogen wird.
-
Schließlich umfasst die Portalkernstruktur 1 zwei "interne" Anwendungsserver 14A, 14B und
einen oder mehr externe Anwendungsserver 14C. Der externe
Anwendungsserver 14C enthält Verweise auf externe Anwendungsserver,
die existierende Dienste laufen lassen. In einer Implementierung
umfasst die Dienststufe drei Klassen von Diensten, von denen eine
erste in Übereinstimmung
mit den Portalkernspezifikationen entwickelt wird, die unter Verwendung
der Portalkernumgebung implementiert sind. Eine zweite Dienstklasse
bezieht sich auf Dienste, die nicht notwendigerweise in der Portalkernumgebung
implementiert sind, wie etwa z.B. ein externes E-Mail-System, das
in einer Nicht-Portalkernumgebung läuft, angepasst, sich selbst
durch die Portalkernpräsentation
zu präsentieren.
Die dritte Dienstklasse bezieht sich auf externe Dienste, die nicht
der Portalkerndienstentwicklung oder Präsentationsarchitekturen entsprechen.
Im folgenden werden der Portalkern, und speziell die Präsentationsanordnung, die
in der Präsentationsschicht
beinhaltet ist, noch mit Bezug auf 2 gründlicher
beschrieben.
-
Die Dienststufe umfasst in einer
vorteilhaften Implementierung drei Dienstklassen. Der Dienstklassenportalkerndienst
(pcoreservice) entspricht den Spezifikationen von dem Portalkern
und wird verwendet, um die Portalkerncharakteristika wirksam einzusetzen.
In einer Implementierung werden die Dienste unter Verwendung der
J2EE IBM WEBSphere Umgebung (ein Anwendungsserver, der verwendet
wird, um programmatische Dienste zu entwickeln, die Logik, Algorithmen
etc. einbeziehen) implementiert. Derartige Dienste haben allgemein
Architekturen mit drei oder vier Stufen, die JSP (Java-Server-Seiten, Java
Server Pages) in dem Frontend, Java-Servlets und Enterprise Java
Beans (EJB) in der mittleren Schicht und verschiedene Entitäten in dem
Backend aufstellen. Die zweite Dienstklasse sind die integrierten
Portalkerndienste (integrierte pcore-Dienste), die pcore-Präsentationsdienste
wirksam einsetzen, die aber nicht notwendigerweise in der Portalkern-J2EE-Umgebung implementiert
sind, z.B. ein externes E-Mail-System,
das in einer Nicht-Portalkernumgebung läuft, aber angepasst ist, sich
selbst durch die Portalkernpräsentation
zu präsentieren. Die
dritte Dienstklasse, externe pcore-Dienste, entspricht weder der
Portalkerndienstentwicklung noch den Präsentationsarchitekturen, sondern
Dienste der dritten Dienstklasse, d.h. externen pcore-Dienste können z.B.
durch den Portalkern getriggert oder vermittelt werden.
-
In einer Implementierung gibt es
zwei Typen von Dienstoptionen, die innerhalb der Dienstschicht verfügbar sind.
Einer kann aus Diensten bestehen, die durch Broadvision (CORBATM; zum Erstellen optimierter regelbasierter
und personalisierter Dienste, die mit Kommerz und Einzelhandel verbunden
sind) vorgesehen werden und für
eine Inhaltsabgabe durch eine passende Engine optimiert werden,
die in Inhalt, Profil und Geschäftsregeln
arbeitet. Der andere Diensttyp bezieht sich auf programmatische Dienste,
die z.B. Algorithmen, Logik etc. erfordern, die nicht einfach in
einem optimierten Inhaltsabgabesystem eingebaut sind. Falls die
Dienste von einer pcore-Dienstklasse
sind, dann können
sie für
IBM WEBSphere J2EE Umgebung vorgefertigt sein, und falls sie von
einer integrierten Dienstklasse sind und in einem externen Dienstserver
laufen, können
sie auf die Portalkernpräsentation
angepasst sein.
-
Ein Dienst benötigt Spezifikationen inkludierend
Elemente in der Wiedergabefunktionalität der Präsentationsschicht ebenso wie
in Bezug auf die Dienstschichtfunktionalität, d.h. Schemata und Logik. Die
Portalkernpräsentationsarchitektur
kann, wie oben berichtet, in einer vorteilhaften Ausführungsform
die J2EE-Architektur für
die Mechanismen zum Erstellen und Einsetzen von Diensten in spezifischen Elementen
oder zum Definieren von Diensten implementieren. Die Erfindung ist
jedoch nicht auf eine Portalstruktur begrenzt, die J2EE und Broadvision verwendet,
die lediglich als Beispiele angegeben werden.
-
Die Präsentationsschicht ist konzeptionell
in zwei Stufen gesplittet, eine Wiedergabeschicht, die in dem Portalkern
selbst angesiedelt ist, und eine Schicht, die einem beliebigen Dienst
zur Verfügung steht,
der seinen Inhalt durch die Portalkernpräsentationsstruktur präsentieren
möchte.
Die Wiedergabeschicht verwendet in einer vorteilhaften Implementie rung
XML-/XSLT-Technologien. Dann durch wird auch sichergestellt, dass
Information, die durch Dienste innerhalb des Portals präsentiert
wird, auf einem standardisierten Weg ungeachtet dessen, was die
Endnutzerstation ist, d.h. ungeachtet dessen, welche Art einer Endnutzerstation
der Endnutzer verwendet, wenn er auf das Portal zugreift, angezeigt werden
kann.
-
Falls XML als eine generische Textauszeichnungssprache
verwendet wird, erzeugt ein Dienst eine Ausgabe in der Form eines
XML-Dokuments, das unter Verwendung von Strukturinformation von einer
pcore-DTD formatiert wird. Die XML-Ausgabe von dem Dienst wird dann
verwendet, um in die Präsentations-Engine der Präsentationsanordnung
einzuspeisen. Die Präsentations-Engine
verwendet pcore-SS und pcore-Gitterinformation, die mit der pcore-DTD
des XML-Dokuments in Verbindung steht, das durch den Dienst zugeführt wird,
um die gewünschte
Schnittstelle zu generieren. Dienste, die XML nicht aus einer pcore-DTD
erzeugen, sind insbesondere in der Lage, sich selbst durch die Präsentationsdienste
zu präsentieren.
-
Wie zuvor berichtet, ist die Portalstruktur
vorteilhafter Weise in der Lage, unterschiedliche Dienste, wie etwa
WAP-Telefone, und Breitbandvorrichtungen, wie etwa PCs, zu handhaben.
Mit einer Vorrichtung ist tatsächlich
der Browser gemeint, der durch die Vorrichtung verwendet wird. Allgemein
ist es der gleiche wie die Vorrichtung für ein WAP-Telefon, aber ein
PC kann verschiedene Browser verwenden. Eine Portalkernstrukturplattform
und die Logik in ihr sind insbesondere vollständig von der Präsentationsschichtfunktionalität getrennt,
was es sehr einfach macht, Unterstützung für alle unterschiedlichen Typen
von Clients zu implementieren, sogar Stimmen- und Sprachsynthesizer.
Durch Verwendung von z.B. XML/XSL ist es sehr einfach, Unterstützung für z.B. einen
neuen Typ einer WAP-Anzeigegröße zu implementieren.
Es ist auch möglich,
den Wiedergabeprozess auf verschiedene WEB-Vorrichtungen, existierende
und zukünftige
in der Hand gehaltene Vorrichtungen, Sprachbrowsen und interaktives
TV anzupassen.
-
Oben wurde ein Beispiel einer Portalstruktur beschrieben,
zu dem das erfinderische Konzept implementiert werden kann. Die
Erfindung als solche ist jedoch natürlich nicht darauf begrenzt,
in einem derartigen Portal implementiert zu werden, sondern sie nimmt
an, dass eine Portalstruktur hergestellt ist, die in der Lage ist,
Endnutzer, d.h. (Endnutzerstationen) oder Entitäten, die auf das Portal zugreifen,
verschiedener Arten mit Zugriff zu versehen. Für jeden Endnutzer wird durch
das Portal eine Sitzung erstellt und jede Sitzung enthält endnutzerspezifische
Daten. Ein Dienst/Anwendung kann extern oder intern sein. In diesem
Zusammenhang wird eine interne Anwendung oder ein Dienst als eine
Anwendung oder ein Dienst definiert, die/der die Sitzungsverwaltung
des Portals verwendet, wohingegen ein externe Anwendungsdienst genommen
wird, eine Anwendung oder einen Dienst zu bedeuten, die/der eine
externe Sitzungsverwaltung verwendet, was bedeutet, dass sie/er
die Sitzungsverwaltung selbst vorsehen kann, oder sie/er durch eine
dritte Seite sitzungsverwaltet sein kann.
-
Um auf einen Dienst/Anwendung zuzugreifen,
muss jedoch zuerst Zugriff auf die Portalstruktur selbst vorgesehen
werden. Das erfinderische Konzept wird nun mit Bezug auf 3–5 detaillierter
beschrieben. Um Zugriffsanforderungen durch verschiedene Arten von
Endnutzerstationen (Vorrichtungen) zu handhaben, zeigt 3 einen Portalkern 1 mit
einer Vorrichtungserfassungsanordnung, dem Vorrichtungsdetektor 53,
für eine
Implementierung des erfinderischen Konzepts, wenn eine Endnutzerstation 6 Zugriff
auf das Portal anfordert. Wenn Endnutzerstation 6, die
z.B. eine WAP-Vorrichtung oder ein PC, der einen Browser verwendet,
sein kann, Zugriff auf das Portal wünscht, sendet sie eine Zugriffsanforderung,
die in dem Portalkern-Anforderungsvermittler 16 empfangen
wird. Es wird vorausgesetzt, dass ein Zugriffsprotokoll verwendet
wird, dass die Einbeziehung von Basisinformation in Bezug auf Klassen-
oder Gruppenzugehörigkeit(en)
der Endnutzerstation unterstützt,
ebenso wie Information über
den Typ der Endnutzerstation, d.h. spezifischere Information. Bei
Empfang der Anforderung, ID, in dem Anforderungsvermittler 16,
ruft er die Endgerätedatenbank 52 unter
Verwendung einer Anzeige des Typs, um herauszufinden, ob der Typ
durch die Endgerätedatenbank 52 erkannt
wird, IID. Falls das Zugriffsprotokoll,
das verwendet wird, HTTP ist, kann der Ruf eine Anforderung umfassen,
den Benutzeragenten zu erhalten, und falls der Benutzeragent durch
die Endgerätedatenbank
erkannt wird, d.h. in der Endgerätedatenbank
enthalten ist, bedeutet dies, dass die Typinformation in Bezug auf
die Endnutzerstation in der Endgerätedatenbank enthalten ist.
Falls erkannt, wird somit die Typinformation aus der Endgerätedatenbank 52 durch
den Anforderungsvermittler 16 abgefragt, IIID1,
der dann die Information zu dem Portalsitzungsverwalter 13 weiterleitet,
IIID2, der Erstellung und Speicherung einer
Endnutzerportalsitzung vorsieht.
-
Falls jedoch die Typanzeigeinformation
oder der Benutzeragent nicht durch die Endgerätedatenbank 52 erkannt
werden, wird dies durch den Anforderungsvermittler 16 festgestellt,
der dann die Endgerätedatenbank
aufruft, um herauszufinden, ob die Klassen- oder Gruppenzugehörigkeit
der Endgerätedatenbank
bekannt ist, d.h. ob beliebige der Klassen (oder der Klasse), die
durch die Endnutzerstation unterstützt wird, in der Endgerätedatenbank
enthalten ist, IVD. Falls ja, wird die Klasseninformation
durch den Anforderungsvermittler 16 abgefragt, der die Klasseninformation
zu der Vorrichtungserfassungsanordnung 53 weiterleitet,
VD. Da die Klasseninformation gemäß der Erfindung
Information über
die Textauszeichnungssprache enthält, die durch die Endnutzerstation 6 verwendet
oder ver standen wird, ist es für
die Vorrichtungserfassungsanordnung 53 möglich, mit
der Endnutzerstation 6 zu kommunizieren.
-
Die Vorrichtungserfassungsanordnung 53 fordert
dann weitere Information in Bezug auf den Typ der Endnutzerstation
von der Endnutzerstation an, VID. Dies kann
z.B. durch Präsentieren
einer Konfigurationsseite zu der Endnutzerstation geschehen. Der
Endnutzer gibt dann die angeforderten Daten in die Endnutzerstation
ein und die angeforderten Daten werden nachfolgend zu der Vorrichtungserfassungsanordnung
zurückgegeben,
VIID. Die Vorrichtungserfassungsanordnung 53 leitet
dann die Typdaten, oder allgemeiner die Endnutzerstationstypdaten, zu
der Endgerätedatenbank 52 weiter,
VIIID, wo die Typdaten gespeichert werden,
derart, dass sie gefunden werden können, falls die gleiche oder
falls eine andere Endnutzerstation des gleichen Typs Zugriff auf
das Portal wünscht.
Dies bedeutet, dass das Portal adaptiv aktualisiert wird, um Information
darüber zu
enthalten, derart, dass es in der Lage sein wird, mehr und mehr
Typen von Endnutzerstationen zu erkennen. Somit muss es nicht mit
Typinformation über jede
Endnutzerstationen, die auf dem Markt verfügbar ist, direkt von Beginn
an versehen werden, sondern ist anpassbar, solange wie es die allgemeinere Basisinformation
in Bezug auf die Endnutzerstationen enthält. Somit ist es nun für den Endnutzer
möglich,
in das Portal einzutreten, was in der Figur durch die gestrichelten
Pfeile veranschaulicht wird. Dies bedeutet, dass eine Portalsitzung
erstellt wird, IX1, IX2,
die Anforderung zu der Dienstanwendung weitergeleitet wird, IX3, wie durch die Endnutzerstation angefordert,
die insbesondere XML-Daten generiert, oder allgemeiner Daten in
einer generischen Textauszeichnungssprache, welche Daten dann zu dem
Portalanforderungsvermittler für
eine Wiedergabe in die Textauszeichnungssprache zurückgegeben werden,
IX4, die durch die Endnutzerstation verwendet
wird, IX5. Anschließend werden die Daten zu der Endnutzerstation 6 in
der geeigneten Sprache gesendet, IX6.
-
Es kann das Konzept einer vereinheitlichten Sitzungsverwaltung
implementiert werden, wie in der Patentanmeldung "An Arrangement an
a Method Relating to Session Management in a Portal Structure" offengelegt, die
hierin durch Verweis einbezogen wurde. Um eine kontinuierliche Navigation
innerhalb des Portals ungeachtet dessen, ob Dienste oder Anwendungen,
auf die zugegriffen wird, extern oder intern sind, vorzusehen, kann
ferner das Konzept zum Einführen
von Metaverweisen in die Dienst- oder Anwendungsdaten in einer generischen
Textauszeichnungssprache implementiert werden, wie in der gemeinsam
anhängigen
Patentanmeldung "An
Arrangement and a Method Relating to Access of Applications/Services" offengelegt, die
zum gleichen Datum und durch den gleichen Anmelder wie die vorliegende
Erfindung eingereicht wurde und deren Inhalt hiermit durch Bezugnahme
hierin einbezogen wird.
-
Die Prozedur gemäß einer Ausführungsform der
vorliegenden Erfindung wird nun mit Bezug auf das Flussdiagramm
von 4 erläutert. Wenn
eine Zugriffsanforderung, z.B. in dem HTTP-Protokoll, von einer Endnutzerstation
in dem Portalanforderungsvermittler empfangen wird, 100,
ruft der Anforderungsvermittler die Endgerätedatenbank unter Verwendung
des Benutzeragenten in der HTTP-Anforderung auf, um den Benutzeragenten
in der Endgerätedatenbank
zu finden, d.h. den Endnutzerstationstyp, 101.
-
Falls der Benutzeragent in der Endgerätedatenbank
erkannt wird, d.h. falls er in der Endgerätedatenbank gespeichert ist, 102,
wird eine Endnutzerportalsitzung durch den Sitzungsverwalter auf
eine konventionelle Art und Weise erstellt und gespeichert, 109.
-
Falls jedoch der Benutzeragent nicht
erkannt wird oder in der Endgerätedatenbank
enthalten ist, 102, wird dies durch den Anforderungsvermittler
erfasst, der dann die Endgerätedatenbank
unter Verwendung von Information über die Endnutzerklassenzugehörigkeit(en)
aufruft, um die Vorrichtungsklasse(n) abzufragen, die durch die
Endnutzerstation unterstützt
wird (werden), 103. Falls keine der Endnutzerklasse(n)
(oder die Klasse) erkannt wird, d.h. in der Endgerätedatenbank
enthalten ist, 104, ist ein Zugriff nicht möglich, 104A.
Falls andererseits eine Endnutzerklasse erkannt wird, d.h. sie in
der Endgerätedatenbank
enthalten ist, fragt der Anforderungsvermittler die entsprechende
Klasseninformation aus der Endgerätedatenbank ab und gibt sie
zu der Vorrichtungserfassungsanordnung weiter, 105.
-
Da die Klasseninformation Information
darüber
enthält,
welche Textauszeichnungssprache die Endnutzerstation verwendet oder
versteht, wird diese Sprache durch die Vorrichtungserfassungsanordnung
verwendet, um Typdaten anzufordern, d.h. weitere spezifische Information
von der Endnutzerstation, 106. Ein Weg dies zu tun ist,
der Endnutzerstation eine Konfigurationsseite vorzulegen. Die Endnutzerstation
sieht dann die angeforderten Daten vor, d.h. durch eine Konfiguration
der Endnutzerstation durch den Endnutzer, und die angeforderten
Daten werden zu der Vorrichtungserfassungsanordnung gesendet, 107.
Die Vorrichtungserfassungsanordnung sieht dann die angeforderten
Endnutzerstationstypdaten zu der Endgerätedatenbank zum Speichern darin vor, 108.
Anschließend,
vgl. Schritt 109 oben, wird eine Endnutzerportalsitzung
erstellt und durch das Sitzungsverwaltungsmittel auf eine konventionelle Art
und Weise gespeichert. Somit wurde eine Endnutzerstation eines unbekannten
Typs (durch das Portal nicht erkannt) mit Zugriff auf das Portal
versehen, und Zugriff wird ebenso anderen Endnutzerstationen des
gleichen Typs ermöglicht,
aber dann ohne der Notwendigkeit einer Benutzerinteraktion. Das Portal
wurde adaptiv, oder generisch, aktualisiert.
-
Die Vorrichtungserfassungsanordnung
insbesondere ist eine aktive Komponente, die innerhalb des Portalkerns
läuft.
Das erste Mal wird, wenn eine Endnutzerstation auf die Portalstruktur
zugreift, falls nicht erkannt, die Vorrichtungserfassungsanordnung aufgerufen,
um weitere Information über
die Endnutzerstation abzufragen.
-
Nachstehend wird eine spezielle Implementierung
auf eine detaillierte Art und Weise angegeben. Damit die Vorrichtungserfassungsanordnung funktional
ist, müssen
in diesem Fall die folgenden Operationen in dem Portal verfügbar sein.
- A. UserAgent = httpRequest.getAgent()
- B. DeviceClasses dcs = httpRequest.getDeviceClasses()
- C. Boolean b = terminalDatabase.supportsDeviceClass(DeviceClass
dc)
-
Operationen A, B können unter
Verwendung der HTTP-Protokollinformation, oder der entsprechenden
Information, falls ein anderes Protokoll verwendet wird, implementiert
werden. Operation C kann unter Verwendung von Operation B und einer (beliebigen)
Datenbank implementiert werden.
-
Wenn ein Endnutzer auf das Portal über HTTP
in einer bestimmten Implementierung zugreift, werden die folgenden
Aktionen unternommen:
- 1. Die Funktion httpRequest.getAgent()
wird aufgerufen, um den Benutzeragenten abzufragen.
- 2. Der Benutzeragent wird als ein Schlüssel zu einer Endgerätedatenbank
verwendet. Falls der Benutzeragent gefunden wird, wird die Vorrichtungsinformation
zurückgegeben.
Anderenfalls:
- 3. Die Funktion httpRequest.getDeviceClasses() wird aufgerufen,
um die Vorrichtungsklassen abzufragen, die durch die Endnutzerstation
(die Vorrichtung) unterstützt
werden.
- 4. Falls eine der Vorrichtungsklassen in der Endgerätedatenbank
bekannt ist, d.h.
terminalDatabase.supportsDeviceClass(dc)
= = true ist, wird die Vorrichtungsdetektoranwendung aufgerufen,
wobei diese Klasse als Argument gegeben wird.
- 5. Die Vorrichtungserfassungsanordnung präsentiert dem Benutzer eine
Vorrichtungskonfigurationsseite. Dies ist möglich, da falls die Vorrichtungsklasse
bekannt ist, es möglich
ist, eine Seite in der Textauszeichnungssprache zu generieren, die
für die
Endnutzerstation (die Vorrichtung) verständlich ist.
- 6. Der Benutzer konfiguriert seine Vorrichtung (Endnutzerstation)
und sichert die Daten. Die gesicherten Daten werden dann zu der
Endgerätedatenbank
weitergeleitet und in ihr gespeichert.
- 7. Der Benutzer kann nun das Portal betreten.
-
Die Interaktionen zwischen dem Portal,
d.h. dem Anforderungsvermittler, der Vorrichtungserfassungsanordnung
und Endgerätedatenbank
werden auch in dem Interaktionsdiagramm von 5 veranschaulicht.
-
httpRequest.getAgent(), httpRequest.getDeviceClasses(),
wie oben berichtet, können
unter Verwendung der Information implementiert werden, die durch
das HTTP-Protokoll zugeführt
wird.
-
terminalDatabase.supportsDeviceClass(DeviceClass
dc) kann unter Verwendung der vorherigen Operationen und einer beliebigen
Datenbank implementiert werden.
-
Es sollte klar sein, dass die Erfindung
nicht auf die Verwendung von HTTP als ein Zugriffsprotokoll begrenzt
ist, sondern das erfinderische Konzept für ein beliebiges Zugriffsprotokoll
implementiert werden kann, das Information über Endnutzerstationsklassenzugehörigkeit(en)
und Endnutzerstationstyp vorsieht. Es ist auch eine Anforderung,
dass eine gewisse Art eines Speichermittels vorgesehen wird, das eine
Speicherung von Endnutzerstationsbasisinformation (Klassen-/Gruppeninformation)
und Typinformation unterstützt.
Auch in anderer Hinsicht ist die Erfindung nicht auf die speziell
veranschaulichten Ausführungsformen
begrenzt, sondern sie kann auf einer Anzahl von Wegen innerhalb
des Bereichs der angefügten
Ansprüche
variiert werden.
-
ZUSAMMENFASSUNG
-
Die vorliegende Erfindung bezieht
sich auf eine Portalstruktur, die Zugriff durch Endnutzerstationen
(6) unterstützt,
die ein Zugriffsprotokoll für
Zugriffsanforderungen verwenden, die Basisinformation, die Gruppe(n)
oder Klasse(n) spezifiziert, zu der (denen) eine anfordernde Endnutzerstation
(61) gehört,
und Typinformation, die den Typ der anfordernden Endnutzerstation
spezifiziert, enthalten. Die Portalstruktur umfasst einen Portalkern
und Portalspeichermittel (52) zum Speichern von mindestens
Typinformation für
mindestens einige Typ(en) von Endnutzerstationen. Sie umfasst ferner
eine Vorrichtungserfassungsanordnung (53), und das Portalspeichermittel
(52) unterstützt
eine Speicherung von Basisinformation, wie etwa Klassenzugehörigkeiten
von Endnutzerstationen. Falls der Typ einer Endnutzerstation (6),
die Zugriff anfordert, durch die Portalstruktur nicht erkannt wird,
und falls festgestellt wird, dass eine Klasse/Gruppe, zu der die
Endnutzerstation gehört,
dem Portal bekannt ist, fordert die Vorrichtungserfassungsanordnung
(53) unter Verwendung der Klassen-/Gruppeninformation in Bezug auf die
Endnutzerstation Typinformation von der Endnutzerstation (6)
an, die, wenn abgefragt, in das Portalspeichermittel (52)
gespeichert wird, derart, dass die Endnutzerstation (6)
in der Lage ist, auf das Portal zuzugreifen.