DE10055684A1 - Computersystem sowie Verfahren zur Erstellung von personalisierten Datenausgaben - Google Patents

Abstract

Die Erfindung betrifft ein Computersystem sowie ein Verfahren zur Erstellung von personenbezogenen Datenausgaben, welche insbesondere genutzt werden können, um Anfragen, wie beispielsweise über das Internet-Protokoll (HTTP), anzunehmen, diese Anfrage mit Anweisungen zur Abarbeitung zu assoziieren, die Abarbeitung gemäß den Anweisungen durchzuführen und das Ergebnis dem anfragenden Benutzer bzw. Programm synchron oder zu einem späteren Zeitpunkt zu übermitteln, wobei das Format der Ausgabe an die Möglichkeiten des vom Benutzer verwendeten Endgeräts angepaßt wird. DOLLAR A Mit der Erfindung werden eine zukunftsweisende Architektur und ein Produkt zur Verfügung gestellt, mit deren Hilfe ein Anwender adaptive und entwicklungsfähige A2A-(Any-2-Any)Lösungen für den e-commerce herstellen kann. Das Verfahren wandelt jede Information aus beliebiger Quelle in kundenbezogene Informationen um und versendet sie an jedwedes Endgerät, gleich, ob es sich dabei um internetbasierte, mobile oder verkabelte Gerätetypen handelt (z. B. PDAs, WAP-devices, Set-top-Boxes, Digital Assistants, PCs etc.).

Description

Die Erfindung betrifft ein Computersystem sowie ein Verfahren zur Erstellung von personalisierten Datenausgaben, welche insbesondere genutzt werden können, um Anfragen (Requests), beispielsweise über das Internet-Protokoll [HTTP], anzunehmen, diese Anfrage mit Anweisungen zur Abarbeitung zu assoziieren, die Abarbeitung gemäß den Anweisungen durchzuführen und das Ergebnis (Response) dem anfragenden Benutzer/Programm synchron oder asynchron (zu einem späteren Zeitpunkt) zu übermitteln, wobei das Format der Ausgabe an die Möglichkeiten des vom Benutzer verwendeten Endgeräts angepaßt wird.

Die Erfindung bezieht sich auf ein an ein Netzwerk angeschlossenes, verteiltes oder einzelnes Computer­ system sowie auf ein darauf ausgeführtes Computer­ programm, das in der Lage ist, auf Anfrage eines durch einen Benutzer kontrollierten oder autonomen Computer­ programms, welches auf einem Computersystem des Benutzers ausgeführt wird (wobei das Computersystem an dasselbe Netzwerk angeschlossen ist), durch Inter­ pretation und Abarbeitung von in einer Steuersprache verfaßten Anweisungen eine personalisierte Ausgabe zu erzeugen, wobei es zur Laufzeit auf Daten aus lokaler (innerhalb des Computersystem gespeichert) und/oder entfernter (außerhalb des Computersystems, also auf einem anderen Computersystem gespeichert) Quelle zugreift und diese Daten individuell (auf die Inter­ essen/Bedürfnisse des Benutzers bezogen) zusammenstellt und die so erzeugte Ausgabe in einem zu dem Computer­ system des Benutzers (beziehungsweise zu den dort ausgeführten Programmen) kompatiblen Format zurückgibt und/oder die Ausgabe des Ergebnisses auf ein an das Computersystem des Benutzers angeschlossenes Endgerät bewirkt.

Gedacht ist die Erfindung speziell für die Verwendung in den Anwendungsbereichen des Marktes, allgemein aus­ gedrückt, der 'digitalen Konvergenz'. Hier werden Systeme benötigt, die den heutigen Regeln für eine erfolgreiche Umsetzung von Angeboten und Dienst­ leistungen auf digitaler Basis gehorchen. Diese Regeln sind insbesondere gekennzeichnet durch eine enorme Geschwindigkeit in der Entwicklung der beteiligten Technologien bzw. Produkte sowie durch eine zunehmende Komplexität der Integration verschiedenster techno­ logische Komponenten bzw. Produkte verschiedener Her­ steller, die oft inkompatibel zueinander sind.

Das schnellebige Konsumverhalten der 'Generation X' trägt ebenfalls dazu bei, daß Anbieter immer schneller und immer besser reagieren können müssen, um sich mit adäquaten Angeboten am Markt behaupten zu können.

Zum heutigen Zeitpunkt gibt es keine System, Technologie, Produkt oder Verfahren, die in verein­ heitlichter Form, mit hoher Integrationstiefe und standardisierten Schnittstellen zu anderen Systemen eine endgeräteunabhängige, personalisierbare und format- sowie quellenunabhängige Verarbeitung von Daten/Informationen skalierbar, stabil und hoch­ verfügbar in einer Architektur/Technologie vereint bieten.

Daher kann man in diesen Marktsegmenten auf der operativ-technischen Ebene der Geschäftstätigkeit fünf Bereiche identifizieren, die Anbieter bzw. Systemhäuser mehr oder weniger intensiv (je nach Geschäftsfeld und Art der zu erstellenden Dienstleistung/Anwendung) und kompetent unter Verwendung von mehreren Technologien bzw. Produkte verschiedener Hersteller abdecken müssen, um in der Umsetzung ihrer Vorhaben technisch und wirtschaftlich erfolgreich zu sein. Jeder dieser Bereiche birgt in sich mehrere Problemfelder, die durch den Einsatz der Erfindung gelöst werden. Hier ein Abriß der Bereiche:

Als erstes wäre das Gebiet der Informations- und Datenhaltung sowie die Vielzahl der Formate zu nennen. Das Sammeln, Filtern, Sortieren von Daten, die Vereinheitlichung von verschiedenen Datenformaten, Erzeugen von Metadaten in einheitlichen Formaten, Ablage in geeigneter Datenhaltung (Datenbank) sind die hierbei zu lösenden Probleme. Das ist nötig, um für die höheren, verarbeitenden Schichten und Anwendungen eine Entkopplung von den Formaten der Daten zu bewirken. Als Hauptproblem erweist sich hierbei, daß viele jeweils verschiedene Formate für Text-, Bild-, Video- und Klangdaten nebeneinander existieren. Es gibt nur wenige und nur teilweise akzeptierte bzw. eingesetzte Standards für Metadaten. Das hat einen hohen Aufwand für die Bereitstellung der Daten zur Ausgabe auf verschiedenen Endgeräten zur Folge. Oft gibt es pro Endgerät bzw. Medium eigene Datenverarbeitungsprozesse.

Ein zweites Problemfeld ist die Anwendungs- bzw. funktionale Integration. Die Verbindung verschiedener Anwendungen aus ggf. verschiedenen Umgebungen zu einer Anwendung stellt sich in den meisten Fällen als äußerst schwierig heraus. Idealerweise arbeiten diese Anwen­ dungen auf Basis von Daten, die durch eine Informations- bzw. Datenintegration vereinheitlicht worden sind.

Die hierbei auftretenden Probleme sind die folgenden: Verschiedene Anwendungen haben unterschiedliche Vor­ stellungen über die spezifische Art der Kommunikation. Verschiedene Schnittstellen müssen vereinheitlicht, abstrahiert oder 'gebrückt' werden. Überwiegend ver­ fügen die Anwendungen jeweils über eine eigene Datenhaltung, die nur sehr aufwendig synchronisiert werden kann.

Als nächstes wäre das Gebiet der Integration von Komponenten in das Netzwerk zu nennen. Hier liegt der Fokus auf der Integration der netzspezifischen Hard- und Softwarekomponenten mit den Anforderungen der Anwendungsschicht an das physikalische System. Schwer­ punkte dieser Tätigkeit sind z. B. Einrichtung und Kon­ figuration von verteilten Systemen, Lastverteilung, Monitoring, Konfiguration und Tuning. Hierbei müssen die einzelnen Aktivitäten jeweils mit den Anforderungen der Anwendungsschicht abgestimmt werden. Auch hierbei treten Probleme auf. Obwohl die Interoperabilität netz­ spezifischer Hard- und Softwarekomponenten weitgehend standardisiert und der Betrieb einer solchen Infra­ struktur wenig problematisch ist, gibt es im Zusam­ menwirken mit den darauf ausgeführten Anwendungen immer wieder Stabilitäts- und Skalierungsprobleme, da viele Anwendungen nur bedingt oder auf nicht korrekte Weise die Möglichkeiten verteilter Systeme nutzen.

Interoperabilität zu verschiedenen Endgeräten ist ein weiterer Punkt, der zu den Problemfeldern zu rechnen ist. Dieser Bereich fokussiert auf Produktionsprozesse, die in Zusammenhang mit der Daten- und Informations­ integration diese so nutzen können, daß eine möglichst hohe Wiederverwendbarkeit im Hinblick auf verschiedene Anforderungen an benötigte Formate der zu bedienende Endgeräte gewährleistet ist. Zu den Problemen dabei gehört, daß die Verfahren und Vorgehensweise in diesem Bereich noch weitgehend unstandardisiert sind. Hier wird in der Regel improvisiert und es werden Insel­ lösungen geschaffen, welche hohe Folgekosten bei einer späteren Umstellung mit sich ziehen. Oft wird auch pro zu bedienendem Medium/Endgerät ein eigenes Angebot oder eine eigene Anwendung geschaffen.

Auch die Integration von Hardware-, Software- und Netz­ komponenten zur Bereitstellung einer Infrastruktur sowie einer kompletten Lösung für eine gegebene Anwendung ist bisher nicht befriedigend gelöst. Oft finden sich hier Hilfen in Form vorgefertigter Komponenten, die nach entsprechender Konfiguration zusammengeschaltet werden können. Problematisch erweist sich hierbei die Zusammenführung der Aktivitäten, weil sie eine 'multifaktorielle Matrix' von Problemfeldern schaffen, die schon viele Projekte hat scheitern lassen. Dies ist die komplexeste Integrationstätigkeit und stellt hohe Anforderungen an verschiedenste Qualifikationsprofile bzw. Ausbildung, da es immer noch zu wenige Standards und/oder darauf basierende Mittel (Technologien und/oder Produkte) gibt, die die hier notwendigen Aktivitäten vereinfachen und standardisieren.

Die Aufgabe der Erfindung besteht daher in der Überwindung der genannten Mängel bei den herkömmlichen Einrichtungen und Verfahren, indem die digitale Kommunikation streng an den Anforderungen des Nutzers ausgerichtet wird. Insbesondere beinhaltet das die personenbezogene Auswahl der Inhalte und die personenbezogene und geräteunabhängige Ausgabe der Inhalte.

Diese Aufgabe wird erfindungsgemäß gelöst durch die Merkmale im kennzeichnenden Teil der Ansprüche 1, 4 und 14 im Zusammenwirken mit den Merkmalen im Oberbegriff. Zweckmäßige Ausgestaltungen der Erfindung sind in den Unteransprüchen enthalten.

Ein besonderer Vorteil der Erfindung liegt darin, daß das Computersystem zur Erstellung von personalisierten Datenausgaben aus einem an ein Netzwerk angeschlossenen Computersystem sowie auf dem Computersystem befind­ lichen Datenbanken und einen auf dem Computersystem ausgeführten Computerprogramm besteht, wobei das Computersystem vereinheitlichende Schnittstellen zur Kommunikation mit Peripheriegeräten zur Verfügung stellt und bei Anfrage eines Nutzers oder eines anderen, autonomen Computerprogramms auf innerhalb des Systems lokal gespeicherte Informationen und/oder außerhalb des lokalen Systems entfernt gespeicherte Informationen zugreift, die so gewonnenen Informationen zur Laufzeit durch Interpretation von in einer Steuersprache verankerten Anweisungen und unter Nutzung der auf dem Computersystems befindlichen Datenbanken individuell auf den Nutzer bezogen zusammenstellt und das Ergebnis in einer zu dem Endgerät des Nutzers kompatiblen Form ausgibt oder die Ausgabe durch den Nutzer auf einem von ihm gewählten Endgerät realisiert. Zur Erstellung der personalisierten Datenausgaben nutzt man vorteilhafterweise ein Verfahren, nach welchem die Datenausgaben auf selektierten Endgeräten erfolgen der­ art, daß in einem ersten Schritt ein erstes Modul eines Computerprogramms, das Zugriffs-Modul 14, eine an das Computerprogramm gerichtete Anfrage interpretiert und für die weitere Bearbeitung der Anfrage nötige Daten in eine erste Datenstruktur einträgt, in einem zweiten Schritt ein zweites Modul des Computerprogramms, das Ausgabeerzeugungs-Modul 18, aus einer Datenbank 19 zu den in der im ersten Schritt erzeugten ersten Datenstruktur abgelegten Daten gehörige zweite Datenstrukturen ermittelt, in einem dritten Schritt vom Ausgabeerzeugungs-Modul 18 diese zweiten Daten­ strukturen geparst, die dabei ermittelten Elemente analysiert werden und vom Ausgabeerzeugungs-Modul 18 und/oder einem dritten Modul des Computerprogramms, dem Personalisierungs-Modul 15, eine Ergebnisdatenmenge erzeugt wird, in einem vierten Schritt von einem dritten Modul des Computerprogramms, dem Inhaltserfassungs-Modul 16, die durch die Ergebnisdatenmenge definierten Informationen erfaßt werden, in einem fünften Schritt diese erfaßten Informationen in ein Format gewandelt wird, welches eine Darstellung der personalisierten Ausgabe auf im ersten Schritt ermittelten Endgeräten 10 ermöglicht und in einem sechsten Schritt die Ausgabe der personalisierten Informationen erfolgt.

Für die Nutzung des Verfahrens bietet es sich an, daß ein Anbieter auf einem an ein Netzwerk angeschlossenem Computersystem ein auf eine vom Anbieter erstellte Datenstrukturen enthaltende Datenbank zugreifendes Computerprogramm zur Verfügung stellt, Anfragen von Nutzern an dieses Computerprogramms interpretiert und für die weitere Bearbeitung der Anfrage nötige Anfragedaten speichert, in einem weiteren Schritt aus der Datenbank eine durch die Anfragedaten bestimmte Datenstruktur aufruft, parst, die dabei ermittelten Elemente analysiert und aus lokalen und/oder entfernten Quellen durch die Analyseergebnisse festgelegte Informationen erfaßt, wobei diese Informationen durch die Anfragedaten und die Datenstruktur personalisiert wurden, anschließend diese erfaßten Informationen in durch die Anfragedaten festgelegte, mit den Endgeräten des Nutzers kompatible Ausgabeformate wandelt und die Ausgabe der Informationen veranlaßt.

Durch die Erfindung werden die Formate für die Datenhaltung der Metadaten von Informationen und Daten vereinheitlicht. Ein einziger Prozeß dient der Ausgabe von Informationen und Daten auf verschiedenen Endgerä­ ten. In die Erfindung ist eine Datenbank für die Datenhaltung von Informationen bzw. Daten und/oder ihrer Metadaten integriert. Weiterhin wird durch die Erfindung vereinheitlichende Importschnittstellen und Formate ([XML], [XMLRPC], [SOAP] basiert) für Infor­ mationen, Daten und Metadaten aus verschiedenen Quellen und verschiedenen Formaten geschaffen. Des weiteren ist ein Dienstmodul für eine automatische Formatkonversion zur Laufzeit integriert, der im Ausführungsbeispiel näher beschrieben wird.

Ein weiteres Modul (s. u.) steuert den automatischen und vereinheitlichten Zugriff auf verschiedene Anwen­ dungen, Informationen oder Daten über verschiedene Protokolle zur Laufzeit. Damit gelingt eine Lösung für die Anwendungs- und funktionale Integration. Die Synchronisation getrennter Datenhaltungen verschiedener Anwendungen wird durch die Erfindung gelöst, indem in eine abstrahierende Metaschicht, die in einer 'virtuellen' Datenbank gehalten wird und auf die wiederum von anderen Dienstmodulen zugegriffen werden kann, abgebildet wird.

Hinsichtlich der Netzwerk-Integration realisiert die Erfindung durch eine eigene Softwarearchitektur (eigenes Objektmodel) und konsistente Verwendung von [CORBA] hohe Skalierbarkeit, Stabilität sowie Höchst­ verfügbarkeit. [SNMP]-Integration in allen Dienst­ modulen erlaubt die Überwachung und Konfiguration des Systems durch beliebige, [SNMP]-fähige Netzwerküber­ wachungssoftware anderer Hersteller. Es existiert ein eigenes Protokoll und eigene Mechanismen zur auto­ matischen Synchronisation der Aktivitäten aller Dienst­ module, die auf einem verteilten Computersystem aus­ geführt werden. Außerdem sind Dienstmodule für ver­ schiedene Zugangsprotokolle (z. B. [HTTP], [WAP], [SOAP]) in das System integriert.

Die Erfindung umfaßt eine zentrale Steuersprache (Ausgabenbeschreibungs-Sprache), deren Anweisungen durch entsprechende Dienstmodule (s. u.) in verschie­ dene Ausgabeformate umgesetzt werden kann. Dadurch wird die Interoperabilität zu den unterschiedlichen End­ geräten gewährleistet. Die vereinheitlichten Formate für die Datenhaltung der Metadaten von Informationen bzw. Daten spielen auch für die Interoperabilität zu den unterschiedlichen Endgeräten eine bedeutende Rolle. Ein Dienstmodul für eine automatische Formatkonversion (s. u.) zur Laufzeit führt die dazu notwendigen Operationen aus.

Die Probleme der Systemintegration erfahren eine Lösung durch eine höchstmögliche Integration und die Unterstützung aller erforderlichen Schritte durch eine eigene Systemarchitektur sowie das erfindungsgemäße Verfahren in ihrem gemeinsamen Zusammenwirken. Weitere Vorteile ergeben sich aus der Kapselung der einzelnen Phasen in dem Verfahren sowie aus der Abstraktion durch hohe Integrationstiefe, da damit geringere Anforderungen an das Personal verbunden sind. Die schnellere und damit auch billigere Umsetzung von Anwendungen und Angeboten ist somit gewährleistet. Ein Angebot (Anwendung) kann von verschiedenen Endgeräten benutzt werden.

Die Erfindung soll nachstehend anhand von einem zumindest teilweise in den Figuren dargestellten Ausführungsbeispiel näher erläutert werden.

Es zeigen:

Fig. 1 Darstellung des Computersystems und des Verfahrens als Blockschaltbild;

Fig. 2 Übersicht über die Kommunikation zwischen den am Verfahren beteiligten Modulen;

Fig. 3 Darstellung der Laufzeitumgebung des Verfahrens;

Fig. 4 Darstellung des Ablaufs des Verfahrens und der darin involvierten Module.

Die als Ausführungsbeispiel dienende Realisierung der Erfindung bezieht sich auf ein an ein Netzwerk 11 angeschlossenes, verteiltes 1A oder einzelnes 1B, Computersystem sowie auf ein darauf ausgeführtes Computerprogramm 2, das in der Lage ist, auf Anfrage eines durch einen Benutzer kontrollierten 3 oder autonomen 5 Computerprogramms, welches auf einem Computersystem des Benutzers 4, 10 ausgeführt wird (wobei das Computersystem an dasselbe Netzwerk 11 angeschlossen ist) durch Interpretation und Abarbeitung von in einer Steuersprache 8 verfaßten Anweisungen 9 eine personalisierte Ausgabe zu erzeugen, wobei es zur Laufzeit auf Daten 5 aus lokaler (innerhalb des Computersystem 1A, 1B gespeichert) und/oder entfernter (außerhalb des Computersystems 1A, 1B, also auf einem anderen Computersystem 6 gespeichert) Quelle 7 zugreift und diese Daten individuell (auf die Interessen/­ Bedürfnisse des Benutzers bezogen) zusammenstellt und die so erzeugte Ausgabe in einem zu dem Computersystem 4, 10 des Benutzers (beziehungsweise zu den dort ausgeführten Programmen 3, 5) kompatiblen Format zurückgibt und/oder die Ausgabe des Ergebnisses auf ein an das Computersystem des Benutzers angeschlossenes Endgerät 10 bewirkt.

Es handelt sich dabei um ein System, das auf Anfrage digitale Daten/Informationen (die aus verschiedenen Quellen in verschiedenen Formaten über verschieden Protokolle akquiriert werden können) gezielt, personalisiert in eine Ausgabe transformiert, deren Format an das zugreifende Programm/Endgerät angepaßt ist.

Genauer handelt sich um ein verteiltes Computersystem nebst Programmen (in dieser Gesamtheit betrachtet und der Einfachheit halber im folgenden 'System' genannt), welches Anfragen (Requests), beispielsweise über das Internet-Protokoll [HTTP], annimmt, diese Anfrage mit Anweisungen zur Abarbeitung assoziiert, die Abarbeitung gemäß den Anweisungen durchführt und das Ergebnis (Response) dem anfragenden Benutzer/Programm synchron oder asynchron (zu einem späteren Zeitpunkt) über­ mittelt.

Das System ist generisch im Hinblick auf seinen kon­ kreten Einsatz bzw. Verwendung durch einen Betreiber. Es kann in den Bereichen eBusiness, eCommerce, mCommerce oder ähnlichen Anwendungsbereichen benutzt werden.

Das System wendet ein Konzept der phasenweisen Bearbei­ tung der Anfrage an, wobei Phasen sich als logisch/­ semantisch sinnvoll abgrenzbare Teilbearbeitungs­ schritte der gesamten Bearbeitung einer Anfrage definieren. Die einzelnen Phasen werden dann von einzelnen Programmen (wobei kein bis mehrere Programme zur Abarbeitung einer Phase beitragen können) abgearbeitet.

Für die Verwendung des Systems im 'klassischen' Internet-Umfeld (ähnlich dem Einsatz eines Webservers) lassen sich zum Beispiel folgende Phasen identi­ fizieren:

• - Zugriff auf das System
• - Personalisierung (Ermittlung des in Frage kommenden Inhaltes für die Ausgabe)
• - Datenerfassung/-abholung (Erzeugen von Referenzen auf Inhalte und/oder deren Transfer)
• - Ausgabe (Zusammenstellung der Inhalte/Referenzen sowie Erzeugung des Ausgabeformats)
• - Übermittlung des Ergebnisses

Dieses logische Phasenkonzept wird physikalisch in dem Entwurf des Systems umgesetzt, indem eine Zuordnung von ein bis mehreren Aufgaben zu einer Phase erfolgt. Dafür wird ein Objektmodell verwendet, dessen Umsetzung/­ Implementation

• - die von allen Programmen benötigte Funktionalität in einem Basisobjekt implementiert,
• - von den zur Abarbeitung der spezifische Aufgaben einer Phase benötigte Funktionalität in einem Phasenobjekt (welches das Basisobjekt beinhaltet) implementiert,
• - die konkrete Funktionalität (Algorithmen) eines Programms in einer Ableitung des Phasenobjekts implementiert.

Letztgenannte Programme werden im folgenden Dienstmodule genannt.

Alle Dienstmodule beziehen ihr Wissen um ihre Konfiguration sowie der zur Laufzeit zu verarbeitenden Daten/Informationen aus einer Datenbank, die Beschrei­ bungen (Metadaten) selbiger Daten/Informationen vorhält und pro Computersystem auf dessen Festplatte oder, über eine bestimmtes Kommunikationsprotokoll (z. B. [ODBC]) erreichbar, auf entfernten Computersystemen existiert.

Es existieren ein bis mehrere Dienstmodule für bestimmte Aufgaben (z. B. Datenerfassung/-abholung: Pro Protokoll gibt es eine Implementation).

Alle für die Umsetzung des Verfahrens gebrauchten Komponenten (z. B. die Dienstmodule) sind unter der Verwendung der Standards für [CORBA], [XML] und [DOM] in [C]/[C++] implementiert.

Das System läßt sich in zwei Bereiche einteilen: Das ist zum einen die 'horizontale' Laufzeitumgebung, die die Rahmenfunktionalität (Datenbankzugriff, Netzwerk­ kommunikation, etc.) bietet, die von allen Dienst­ modulen benötigt werden, zum anderen die Dienstmodule selbst, die jeweils eine 'vertikale', spezifische Funktionalität implementieren.

Die Laufzeitumgebung besteht aus Hard- sowie Software (Programmen) in folgender Zusammenstellung (Fig. 3).

Cluster 1A (CL), Computersystem 1B (CS)

Das sind ein oder auch mehrere Computersysteme, die miteinander vernetzt sind.

Hardware (beispielsweise Systeme auf der Basis einer Intel Pentium CPU)

• - Computersysteme inclusive Bauteile für eine Vernetzung.

Programme/Software (nicht Bestandteil von DIS)

• - Netzwerkfähiges Betriebssystem, siehe [UNIX, LINUX]
• - Datenbanksoftware, siehe [SQL, ODBC]
• - [CORBA] standard-konforme ORB Implemenation.

Controller 12 (CO)

Der Controller ist ein Programm zur Kontrolle des Laufzeitverhaltens von Dienstmodulen. Dieses Programm ist außerdem für die Koordinierung der Computersysteme eines clusters zuständig.

Der Controller-Prozeß überwacht das Funktionieren aller Dienstmodule, die in seinem Maschinenbereich (node) ausgeführt werden. Ferner kann der Controller-Prozeß die Dienstmodule durch Aufruf entsprechender Methoden der durch die Dienstmodule zur Verfügung gestellten Object Level Interfaces wie folgt kontrollieren:

• - Stop,
• - Suspend,
• - Resume,
• - Priority,
• - Configure,
• - Restart.

Ein Master-Controller (der Controller Prozeß eines clusters, der zuerst die Ausführungsbereitschaft erreicht hat) kommuniziert mit den anderen Controller- Prozessen und sammelt Informationen über die in anderen Maschinen ausgeführten Dienstmodule für Überwachungs­ zwecke. Die Kommunikation zwischen den Controller- Prozessen findet mit Hilfe eines Steuerprotokolls über einen socket statt.

Ein Controller-Prozess implementiert [SNMP] und [XMLRPC]/[SOAP] Dienste. [SNMP] konforme Netzwerk­ überwachungssoftware dritter Hersteller ist daher in der Lage, das System zu überwachen. Via an den Controller-Prozess gerichtete [XMLRPC]/[SOAP] Anfragen können auf Konfigurationsdaten, Statusinformationen, Datenbanken und das Dateisystem des Systems zugegriffen werden. Diese Dienste bieten die Schnittstellen zur Überwachung und Konfigurations des Systems durch den Betreiber.

Auf jeder node eines clusters wird genau ein Controller- Prozeß ausgeführt.

Trader 13 (TR)

[CORBA] Trading Service ist ein Programm zur Vermitt­ lung von Referenzen auf andere Programme unter Berück­ sichtigung der von dem diese Vermittlung anfordernden Programme gewünschten Eigenschaften.

Der Trader-Prozess verwaltet Objekt-Referenzen (Referenzen auf Dienstmodule, IOR) der node, auf der er aktiv ist.

Anfragen eines Dienstmoduls für Dienste eines anderen werden zunächst an den Trader-Prozess gerichtet, der auf der selben node wie das anfragende Dienstmodul aktiv ist. Ist ein Trader-Prozeß nicht in der Lage, eine passende Referenz an das anfragende Dienstmodul zu erzeugen, befragt er Trader-Prozesse auf anderen nodes des clusters.

Diese Inter-Trader Kommunikation ('trader federation') ist Bestandteil der Spezifikation der [OMG] für diesen Dienst.

Auf jeder node eines clusters wird genau ein Trader- Prozeß ausgeführt.

Die Dienstmodule werden entsprechend ihrer Funktio­ nalität in verschiedene Kategorien eingeteilt. Diese Kategorien spiegeln sich auf der Implementationsebene als einheitliche Schnittstelle für Dienstmodule der­ selben Kategorie wieder. Die gemeinsamen Eigenschaften der Dienstmodule einer Kategorie sind in einer einzigen Klasse zusammengefaßt, die als Basis für die jeweils spezifische Implementationen dient.

Zugriff-Modul 14 (AM)

Dienstmodule für den Zugriff nehmen Anfragen an das System entgegen. Diese Module existieren jeweils einmal pro gewünschtem Zugangsprotokoll (z. B. [HTTP]).

Personalisierungs-Modul 15 (PM)

Diese Dienstmodule wählen den verfügbaren Inhalt ent­ sprechend den Voreinstellungen/Funktionen des Benutzers/Endgerätes aus.

Personalisierungsmodule implementieren verschiedene Methoden, in Abhängigkeit der bekannten oder vermuteten Interessen eines Benutzers oder eines an seiner Stelle handelnden Programmes, passende Inhalte für die Erzeugung der Ausgabe zu ermitteln.

Datenerfassungs-/-abholungs-Modul 16 (CAM)

Diese Dienstmodule erfassen Inhalt aus verschiedenen Quellen. Implementationen dieser Modulkategorie existieren pro Protokoll. Die Module ermöglichen die Einbindung von Daten/Informationen in die Ausgabe, wobei die Herkunft der Daten/Informationen im Sinne des Transportprotokolls unerheblich ist.

Formatkonvertierungs-Modul 17 (CCM)

Dienstmodule zur Formatkonvertierung konvertieren Daten aus einem Format in ein anderes.

Beispielsweise liegt eine Komponente, die zur Erzeugung des Gesamtergebnisses benötigt wird, nur als [GIF] Bilddatei vor. Aus der Datenstruktur sd geht aber hervor, das das zugreifende Endgerät lediglich das [JPG] Format unterstützt. In diesem Falle wird eine automatische Konvertierung des Formats der Bilddatei in das von dem Endgerät unterstützte Format vorgenommen.

Renderer 18 (RM)

Dienstmodule zur eigentlichen Erzeugung der eigent­ lichen Ausgabe. Diese Module sind im weitesten Sinne Steuersprachen-Prozessoren/Interpreter, da sie ein [XML] Konstrukt (beispielsweise XRTL) einlesen und die darin vorhandenen Elemente als Anweisungen zur Ausführung bestimmter Aktionen interpretieren.

Ihre Aufgabe ist es, die Elemente (in diesem Kontext als Platzhalter verstanden) durch Inhalte (Daten/­ Informationen) oder Referenzen auf sie zu ersetzen und dann die Ausgabe in dem benötigten Format zu erzeugen.

Sie implementieren die Funktionalität, die beispiels­ weise benötigt wird, um ein XRTL template zu analysieren und dort enthaltene Anweisungen auszuführen.

Ein XRTL template kann Ausdrücke in einer Programmiersprache enthalten. Beispielsweise verwendet unsere Implementation einen in die Basisklasse integrierten [SCHEME]-Interpreter.

Die erzeugbaren Ausgabeformate sind z. B. [HTML], [WML], [PDF] oder [MPEG].

Datenbank 19 (DBM)

Mit diesem Dienstmodule kann auf Datenbanken für Lese-/­ Schreib-/Aktualisierungszwecke zugegriffen werden. Durch die Verwendung der [ODBC] Schnittstelle wird Kompatibilität und Unterstützung zu/von nahezu allen derzeit auf dem Markt befindlichen kommerziellen Datenbankprodukten abgedeckt.

Es kapselt Datenbank-Funktionalitäten zur einfacheren Verwendung durch andere Dienstmodule.

Dateisystem 20 (FSM)

Mit diesem Dienstmodul kann auf das Dateisystem des Computers zum Lesen, Schreiben und Aktualisieren sowie zum Erstellen und Auflisten von Verzeichnissen zugegriffen werden.

Es kapselt diese betriebssystemnahen Funktionalitäten zur einfacheren Verwendung durch andere Dienstmodule.

Logging-Modul 21 (LM)

Diese Dienstmodule protokollieren Informationen über die Aktivitäten andere Module durch Füllen der Datei­ system-Protokolle oder Datenbank-Protokolle.

Es gibt zwei Ebenen des Loggings. Systemlogging zeichnet Vorgänge während der Abarbeitung einer Anfrage auf und benutzt dafür die von dem Betriebssystem vorgesehene Schnittstelle/Bibliotheksfunktion (in der Regel syslog). Die andere Ebene ist das Aufzeichnen von Benutzeraktivitäten, wodurch eine Wiedererkennung mög­ lich wird. Dieses ist anwendungsabhängig.

Ausgabe-Modul 22 (DM)

Dienstmodule für die Ausgabe geben das Ergebnis der Anfrage an das System zurück.

In einigen Fällen kann auf Implementationsebene ein Ausgabe-Dienstmodul und ein Zugriff-Dienstmodul in einem einzigem Modul kombiniert werden. Das [HTTP] Protokoll ist ein solcher Fall, da die Netzwerkverbindung über einen bidirektionalen und synchronen Kommunikationsmechanismus (socket) erfolgt.

Einschalt- oder Anlaufphase, Betriebsbereitschaft

Nach Start (booten) des/der Computersysteme werden die Komponenten der Laufzeitumgebung (Controller 12, Trader 13, Datenbank 19, [CORBA] ORB) gestartet.

Nach dem Start des Controllers 12 erhält dieser vom [CORBA] ORB eine Referenz zu dem in seiner node laufenden Trader 13. Später wird diese Trader-Referenz an alle lokal verfügbar werdenden Dienstmodule übergeben. Bei Ausfall/Wegnahme/Hinzufügung einer node in einem cluster benachrichtigt der Master Controller alle anderen Controller im cluster über den Vorgang und synchronisiert damit das Gesamtsystem.

Anschließend werden die Dienstmodule gestartet. Ein Dienstmodul erhält beim Start vom Controller eine Referenz auf den Trader 13 und registriert sich selbst beim lokalen Trader. Zu den Registrierungsdaten gehören die z. B. Dienstklasse und Attribute (Diensttyp, Dienstqualität bezüglich Anzahl und Eigenschaften).

Auf jeder node in einem cluster 1A (CL) läuft ein Controller 12 (CO), ein Trader 13 (TR) und ein bis mehrere Instanzen der verschiedenen Dienstmodule (AM 14, RM 18, DM 22, PM 15, CAM 16, CCM 17, DBM 19, FSM 20, LM 21).

Ein Controller 12 (ermittelt durch Vergleich des Zeitpunktes des Startens, der erste betriebsbereite) übernimmt als Master Controller die Leitungsfunktion und steuert und überwacht den Status der Dienstmodule durch Abfrage von Statusdaten, die für andere Über­ wachungssoftware via [SNMP] zugänglich im Speicher vorgehalten werden.

Die Kommunikation zwischen den Dienstmodulen erfolgt mittels den Objektreferenzen aus dem Trader 13.

Dienstmodule nicht auf allen nodes laufen. Ist ein Dienst nicht auf einer bestimmten Maschine verfügbar, wird zum Austausch von IORs zwischen Tradern 13 ein natives Standard-CORBA-Protokoll eingesetzt, was die Dienste maschinenübergreifend verfügbar macht.

Das System ist jetzt betriebsbereit.

Das Verfahren (die Abarbeitung der einzelnen Aufgaben der Phasen) ist eine Verkettung von Aufrufen von mehreren Dienstmodulen (Fig. 4).

Zur Kommunikation der Dienstmodule untereinander dient eine für die Dauer der gesamten Abarbeitung existierende Datenstruktur, die von jedem Dienstmodul gelesen und geschrieben werden kann. Kontextrelevante Zustandsdaten können von einem Dienstmodul in diese Datenstruktur geschrieben und von einem anderen gelesen werden, welches so auf einen Zustand reagieren kann. Auf diese Art und Weise werden die für die Aufrecht­ erhaltung des Gesamtkontexts nötigen Zustandsinfor­ mation/-daten erhalten.

Zusätzlich können die Dienstmodule zu verarbeitende Daten in Form strukturierter Daten (z. B. [XML] Dokumente aus Dateien oder [DOM] Datenstrukturen, deren datentechnisch äquivalente Repräsentation im Speicher) annehmen und diese nach bestimmten Regeln (wie z. B. in [XSL] Dokumenten beschrieben, auch XSL stylesheets genannt) in ein anderes strukturiertes Format (z. B. [XML]) transformieren (z. B. durch die Verwendung von [XSLT] Prozessoren).

Zugriff

Bei einem Zugriff auf das System (Request wird von AM 14 entgegengenommen) erzeugt ein solches Modul eine Datenstruktur (sd), die für den weiteren Ablauf der Anfrage von anderen Dienstmodulen benutzt wird, um ihre jeweilige Teilaufgabe an der Abarbeitung der gesamten Anfrage wahrzunehmen.

Wesentliche Bestandteile dieser Datenstruktur sind im Falle eines Zugriffs via [HTTP] z. B. alle [HTTP] header, welches u. A. (je nach Art der Nutzung) Infor­ mationen über den Benutzer und das von ihm verwendete Programm/Endgerät enthält. Dies ist von Bedeutung, da so für andere, später im Verlaufe der Bearbeitung der Anfrage agierende Dienstmodule, die von dem zugrei­ fenden Programm unterstützten Datenformate bekannt sind.

Ausgabenerzeugung

Die Erzeugung der Ausgaben ist Aufgabe des Render- Moduls 18 (RM). Der Prozeß der Ausgabenerzeugung wird mittels einer eigenentwickelten Steuersprache (XRTL) durchgeführt.

Es existiert eine Implementation eines RMs 18 pro zu erzeugendem Ausgabeformat ([HTML], [WML], etc.). XRTL Anweisungen werde je nach Implementation (= gewünsch­ tes Ausgabeformat) anders umgesetzt.

Ein über einen Zugriff auf die sd identifiziertes template 26 (TS) wird geparst und in Form einer [DOM]- Datenstruktur im Speicher abgelegt.

Dann erzeugt das Dienstmodul die Ausgabe, indem es

• - die [DOM]-Datenstruktur analysiert und dann für jede dort enthaltene Anweisung folgenden Zyklus durch­ läuft (wobei die Datenstruktur (oder eine Kopie) nach jedem Durchlauf modifiziert wird):
• - Klassifikation der Anweisung: Handelt es sich um eine statische oder dynamische Komponente?
• - für eine dynamische Komponente (einen Regelausdruck) wird eine Subroutine aufgerufen und ihr als Argument der Regelausdruck übergeben. Diese Subroutine
• - ruft je nach Ergebnis der Evaluierung des Regelausdrucks ein oder mehrere PM 15 (siehe Personalisierung) auf, die die in Frage kom­ menden Inhaltselemente (unter Verwendung von Metadaten aus der Datenbank 19 (DBM) oder dem Dateisystem 20 (FSM)) zurückgeben bzw. filtern
• - gibt die so ermittelte Ergebnisliste in Form einer Liste von URLs zurück an das Hauptprogramm.
• - für eine statische Komponente (eine Referenz in Form einer [URL]) ist keine weitere Bearbeitung notwendig.
• - die im vorherigen Schritt ermittelten URLs werden nach Protokoll geordnet und parallel gemeinsam mit den abhängig vom Endgerät benötigten Datenformaten an die für die jeweiligen Protokolle zuständigen CAM 16 (siehe Datenerfassungs-/-abholungs-Modul) übergeben, die
• - die gewünschten Daten aus lokaler (19 DBM, 20 FSM) oder entfernter Quelle 7 beschaffen,
• - gegebenenfalls eine Formatkonvertierung (17 CCM) vornehmen und
• - die korrekt formatierten Daten and das Hauptprogramm zurückgeben
• - welches schließlich durch Kombination dieser Daten die Ausgabe erzeugt, indem es eine Transformation der bis jetzt formatneutralen [DOM]-Datenstruktur in das gewünschte Ausgabeformat vornimmt.

Personalisierung

Stößt das RM 18 beim Parsen des templates 26 auf ein Element, das einen Regelausdruck repräsentiert, wird der Interpreter (hier ein integrierter Scheme- Interpreter) mit dem Regelausdruck als Argument aufgerufen.

Beispiel 1 Regelbasierte Personalisierung

Alle sich im Zugriff des Scheme-Interpreter befind­ lichen, statische (aus der Konfiguration des RM 18 stammende) sowie dynamische, zur Laufzeit entstehende Datenstrukturen können Bestandteil einer Regel sein und somit durch geeignete Formulierung der Regelausdrücke so benutzt werden, das ein Evaluierung der Regel­ ausdrücke zu passenden Ergebnissen führt.

Beispiel 2 Personalisierung unter Verwendung 'neuronaler Netze'

Für jedes Information (als Komponente einer zu erzeugenden Ausgabe verstanden) existiert ein neuronales Netz, dessen 'Wissen' einer vorgenommene Kategorisierung (siehe Anhang 3, Kategoriesystem) des Elements entspricht. Für jeden Benutzer existiert ebenfalls ein neuronales Netz, dessen 'Wissen' dem Verhalten des Benutzers insofern entspricht, als das vorgenommene Interaktionen zum Lernen des Musters der jeweiligen Information führt. Bei Ausführung eines PM 15 von diesem Typ wird ein Resonanztest ('wie gut passt das Muster einer Information zu den Mustern in dem neuronalen Netz des Benutzers') durchgeführt und das Ergebnis als Liste zurückgegeben. Für Zusatz­ informationen siehe Anhänge 2 sowie 3.

Je nach Art der verwendeten Personalisierungsmethode werden Benutzerprofile in der Datenbank 23 automatisch angelegt und gemäß Benutzeraktivität aktualisert.

Je nach Verwendung des Systems kann zur Personalisierung auch die optische Präsentation des Ergebnisses in einer durch den Benutzer gewünschten Form (Farbwahl, Layout, etc.) gehören.

Je nach Verwendung des Systems kann zur Personali­ sierung auch eine Zuordnung von verschiedenen Infor­ mations-/Datenarten (Themen) zu verschiedenen Endgeräten in einer durch den Benutzer gewünschten Form gehören.

Datenerfassung/-abholung

Die Ausführung dieser Dienstmodule (CAM 16) wird von dem für die Erstellung der Ausgabe verantwortlichen Dienstmodul (RM 18) ausgelöst, sobald dieses entsprechende Anweisungen in der Steuersprachendatei vorfindet. Grundsätzlich werden diese Module nach dem [URL] Schema identifiziert und angesprochen.

Beispiele

• - file:///path/to/file: aktiviert die Ausführung des Moduls für das [FILE://] Protokoll (Dateisystem­ zugriff) und erzeugt eine Referenz auf eine Datei namens file oder transferiert diese Datei.
• - http:///host/path/to/file_or_program: aktiviert die Ausführung des Moduls für das [HTTP://] Protokoll und transferiert Daten/Informationen von dem Rechner host.
• - sql:///sqlstatement: aktiviert die Ausführung des Moduls für das [SQL://] Protokoll (lokaler [SQL] Datenbankzugriff) und erzeugt eine Referenz auf die Daten, die die Ausführung von sqlstatement in der lokalen Datenbank erzeugt.
• - sql:///user:password@host/database/sqlstatement aktiviert die Ausführung des Moduls für das [SQL://] Protokoll und erzeugt eine Referenz auf die Daten, die die Ausführung von sqlstatement in der Datenbank database auf dem Rechner host erzeugt und transferiert sie.
• - ajp://host:port/path/servlet: aktiviert die Ausführung des Moduls für das [AJP://] Protokoll und transferiert die Daten, die die Ausführung des [SERVLET] servlet auf dem Rechner host (der seinen Dienst auf [PORT] Nummer port bereitstellt) erzeugt.

Je nach Fähigkeit des Programms/Endgerätes des Benutzers zur Darstellung bestimmter Formate wird automatisch eine Formatkonvertierung vorgenommen.

Ausgabe/Übermittlung

Die so erzeugte Ausgabe (z. B. HTML) wird an den client zurückgegeben.

Zusammenfassend kann man die wesentlichen Merkmale der Erfindung folgendermaßen charakterisieren:

• - Steuersprache für die komplette dynamische Erzeugung von Ausgaben
• - die Fähigkeit der Steuersprache, Platzhalter in Form von Regelausdrücken durch Auswertung der Regeln zur Laufzeit zu ersetzen (Regelausdrücke als 'dynamisches switch statement')
• - die Fähigkeit der Steuersprache, im Rahmen der Auswertung eines Regelausdrucks ein spezifisches Personalisierungs-Modul 15 aufzurufen. Feststel­ lung der Methode der Personalisierung zur Laufzeit
• - Methode der Personalisierung durch Verwendung neuronaler Netze zur Laufzeit, deren Muster auf Verarbeitung der im Rahmen eines Kategoriesystems vorgenommen Klassifikation von Inhalten berechnet wurden (Hier: . . . . pro element/user ein NN)
• - Das Zusammenspiel/die Integration von RM 18, PM 15, Regelinterpreter als 'Framework' für die Einbindung von Personalisierungs-Methoden belie­ biger Art
• - Das Zusammenspiel/die Integration von RM 18, PM 15, Regelinterpreter als 'Framework' für die Erzeugung von Ausgaben beliebiger Art

Mit der Erfindung werden eine zukunftsweisende Architektur und ein Produkt zur Verfügung gestellt, mit deren Hilfe ein Anwender adaptive und entwicklungsfähige A2A- (Any-2-Any) Lösungen für den e­ commerce herstellen kann. Das Verfahren wandelt jede Information aus beliebiger Quelle in kundenbezogene Informationen um und versendet sie an jedwedes Endgerät, gleich, ob es sich dabei um internet­ basierte, mobile oder verkabelte Gerätetypen handelt (z. B. PDA's, WAP-devices, Set-top-Boxes, Digital Assistants, PC's, etc.).

Durch sich entwickelnde Kundenanforderungen sowie durch die erweiterten Möglichkeiten, die durch die Vernetzung geboten werden, wird es für die Wirtschaft zu einem Muß, Lösungen für die Bewältigung der zahlreichen existierenden Schnittstellen und Formate zu finden. Einzellösungen bieten diese Flexibilität nicht, die der Handel benötigt, um sich an die schnell ändernden Kundenanforderungen im Service-on-Demand anzupassen. Der Kunde der Informationsgesellschaft verlangt Zugriff zu allen relevanten Informationen - zu jeder Zeit, an jedem Ort, mit jedem Gerät. Die Erfindung bietet diese Vorteile.

Neue Gerätegenerationen schaffen das Verlangen nach innovativen A2A-Diensten für den Endnutzer nach der Maxime: Zugriff zu jeder Zeit, an jedem Ort, mit jedem Gerät. Die erfindungsgemäße Lösung maximiert durch ihre zukunftsweisende Architektur den Wert des Internet und bietet dem Kunden und dem Anwender beachtliche Möglichkeiten, ihren Umsatz zu steigern, indem ihnen durch die Erfindung die Möglichkeit gegeben wird, den Zeit-Markt-Faktor zu verbessern und den vollen Vorteil des Netzwerks als Multiplikator zu nutzen. Die Erfindung löst die Probleme, die durch die zahlreichen Arten von Informationsquellen entstehen, und erlaubt ein geräteunabhängiges Arbeiten, so daß die Vertriebskanäle vervielfacht und die Kundenanforderungen genau und zeitlich nah erfaßt werden können. Die Vereinigung der vielfältigen Möglichkeiten, die das Internet für den Handel bietet, ist ein wesentlicher Vorteil der Erfindung.

Kundenbezogene Informationen werden ein bestimmender Faktor für das gewinnorientierte e-business sein. Besonders Anbieter von Business-to-Business (B2B) und Business-to-Commerce (B2C)-Lösungen versuchen, schnell neue Verkaufswege zu erkennen. Um dies zu erreichen, ist ein Kunden-Profil und die Personalisierung erforderlich. Das bewirkt darüber hinaus eine engere Kundenbindung. Anbieter, die in der Lage sind, die Aktivitäten im Internet auf personenbezogene Daten abzubilden, könne bessere Kundenbeziehungen aufbauen, diese festigen und so einen Kundenstamm etablieren. Durch den Einsatz der Erfindung können Anbieter diese Kundenstämme durch spezifische Portale bedienen und Dienste mit eng fokussierten, personenbezogenen Daten und Informationen zur Verfügung stellen.

Die Geschwindigkeit, mit der Informationen, Dienste und Waren kundenbezogen angeboten werden können, ist die größte Herausforderung für die Anbieter. Die wichtigsten Probleme können dabei wie folgt zusammengefaßt werden:

• - Bei der Geschwindigkeit der heutigen Entwicklungszyklen für Applikationen erweisen sich herkömmliche Programmier- und Entwicklungs-Tools und -Architekturen als unzureichend, um mit den Veränderungen der Kundenbedürfnisse und der Technologien Schritt zu halten.
• - Kosten für Wartung steigen und die Zahl der divergierender Software-Technologien steigt.
• - Kunden erkennen diese Schwierigkeiten nicht an und wechseln den Anbieter, wenn ihre Bedürfnisse nicht befriedigt werden.

Um diese Probleme zu lösen und einen Stamm von loyalen Kunden zu schaffen, ist eine neue Software-Struktur und integrierte Dienste-Technologien nötig.

Mit Hilfe der Erfindung wird die Erstellung von B2B, B2C und A2A-Lösungen unterstützt, wobei das Haupt­ augenmerk auf die Bereitstellung von personenbezogenen, individuellen Inhalten gelegt wird. Das soll dazu beitragen, einen Stamm von loyalen Kunden zu schaffen und den Ertrag zu vergrößern.

Durch den Einsatz der Erfindung werden Dienste wie z. B. Informationsbeschaffung jeder Art und aus beliebiger Quelle, die intelligente Zusammenstellung und Dar­ stellung von individuell kundenbezogenem Inhalt unter­ stützt, ebenso die Versendung dieser Inhalte auf beliebige Endgeräte unabhängig vom Medientyp (Web page, Video-Stream, WAP, e-mail, . . .). Die Erfindung stellt sicher, daß dem Kunden dynamisch ausgewählter, personenbezogener Inhalt übermittelt wird. Dabei erfolgt gleichzeitig eine Formatwandlung, die die Inhalte darstellbar macht auf beliebigen Endgeräten wie mobilen WAP-Endgeräten, Set Top Boxes oder PDA's.

Das Verfahren bietet dem Anwender der Erfindung den Vorteil, daß wertvolle Entwicklungszeit und -kosten eingespart, kostspielige Überarbeitungen und Anpas­ sungen der Software vermieden werden. Indem diese modulare Struktur zur Verfügung steht, wird dem Anwender erlaubt, seine eigenen e-Business-Anwendungen zu entwickeln und/oder vorhandene Applikationen wirksam zur Geltung bringen und transparent in wichtige Internet-Portale oder in e-Services zu integrieren.

Die Anwendung erprobter Prinzipien und die Reduktion der Komplexität bindet bestehende innovative Technologien und entstehende Industrie-Standards in die Architektur der Erfindung ein. Das Verfahren vereinfacht e-Business-Entwicklungen enorm durch geringeren Programmieraufwand und eliminiert die Notwendigkeit bestehende Investitionen in die Informationstechnologie aufzugeben, wenn neue Technologien, Geschäftsmöglichkeiten oder Kundenanforderungen auftauchen.

Die Anwender werden die Vorteile schnell erkennen, die in Zeitgewinn bei Innovationen und schnellem Markteinstieg sowie Mittelrücklauf liegen, wenn sie die komplexen und schwierigen Aufgaben der Integration von e-Business-Lösungen mit der Erfindung durchführen. Da gegenwärtig keine vergleichbare Lösung angeboten wird, hat der Anwender dieses Verfahrens den großen Vorteil des Markteinführers mit einem Vorsprung an Know how.

Wirtschaftlich betrachtet sind daher angesichts der kurzen und vielen Produktionszyklen neben der technischen Flexibilität eines verwendeten Systems auch die Gesamtkosten für ein System und dessen Einsatz bzw. Betrieb incl. Personalkosten interessant. Je höher die Integration/Kapselung eines Systems, desto schneller und damit billiger kann umgesetzt werden.

Der Markt und damit indirekt die Einsatzbereiche für die Erfindung läßt sich grob dreiteilen in Hersteller, Verteiler und Anbieter, wobei je nach Firma/Konzern Überlappungen vorkommen können.

Erstens: Anbieter, deren Geschäft gegründet ist auf der Bereitstellung von speziellen Inhalten, Internet- Hosting für die Allgemeinheit, und neue Lieferkanäle. Beispielsweise Medienkonzerne (TV, Print, etc.) oder Nachrichtenagenturen.

Zweitens: Verteiler von Informationen und online- Service-Provider, deren Geschäftsmodell auf personali­ sierte Inhalte gerichtet ist, um damit eine engere Bindung der Kunden an die Firma, den Bekanntheitsgrad der Marke und den Umsatz zu erhöhen. Beispielsweise Firmen mit einer Tätigkeit in den Bereichen EAI, B2B, ASP oder B2C.

Drittens: Firmen mit einer Tätigkeit im Bereich des B2C.

Dabei steht die Entwicklung dieser Modelle erst am Anfang; der Bedarf für den Einsatz einer flexiblen Lösung, wie sie durch die Erfindung bereitgestellt wird, wird in der nächsten Zukunft sprunghaft ansteigen.

Zur Lösung dieser anstehenden Aufgaben bietet die Erfindung den Anwendern in den drei genannten Bereichen eine vorteilhafte Möglichkeit, um schnell auf die sich ändernden Geschäftsbedingungen zu reagieren und qualitativ hochwertige, personenbezogene Inhalte auf ihren Websites anzubieten. Das führt zur Erhöhung der Besucherzahlen auf den Websites, zur Etablierung eines Kundenstammes und letztendlich zur Umsatzsteigerung. Das Wachstum der Firmen, welche die Erfindung einsetzen, wird so an das Wachstum des Internet gekoppelt. Durch die Flexibilität und Formatunabhängigkeit der Erfindung lassen sich stets die wichtigen und zeitgemäßen e-business-Technologien einbinden. Für die Anwender wird Training und Support auf allen Ebenen gewährleistet.

Die Erfindung ist nicht beschränkt auf die hier darge­ stellten Ausführungsbeispiele. Vielmehr ist es möglich, durch Kombination und Modifikation der genannten Mittel und Merkmale weitere Ausführungsvarianten zu realisie­ ren, ohne den Rahmen der Erfindung zu verlassen.

Anhang 1 XRTL/XRTL DTD

XRTL (XML based Rendering Template Language) ist eine für das erfindungsgemäße Verfahren entwickelte XML- Sprache.

Der Dokumentenzeichensatz für XML und XRTL ist der Universal Character Set nach dem ISO/IEC-10646 ([ISO10646]) Standard. Derzeit ist dieser Zeichensatz identisch mit Unicode 2.0 ([UNICODE]). XRTL wird zukünftige Änderungen und Verbesserungen an den [XML]- und [ISO10646]-Spezifikationen berücksichtigen. Im vorliegenden Dokument sind die Bezeichnungen ISO10646 und Unicode austauschbar und bedeuten denselben Dokumentenzeichensatz.

Die Steuersprache (XRTL) ist in folgender DTD definiert:

Anhang 2 Regeln und deren Verwendung

Die XRTL Tags rule und ruleset enthalten Regeln in Form einer Programmiersprache, deren Interpreter Teil der Basisklasse aller Dienstmodule ist; also auch des davon abgeleiteteten Render Moduls. In der vorliegenden Implementation ist ein modifizierter Scheme-Interpreter Bestandteil der Basisklasse.

Die Modifikationen am Scheme-Interpreter und seine Integration in die Basisklasse erlauben dem Interpreter Zugriff auf Speicher/Variablen des kapselnden Render- Moduls. Dadurch können Regeln dynamische (erst zur Laufzeit entstehende) Größen in der Formulierung ent­ halten sowie der Interpreter diese zur Laufzeit ermit­ teln und sie dann in der Evaluierung der Regelausdrücke benutzen.

Taxonomie der Regeln

Genau genommen sind alle erstellten Regeln gleich­ wertig. Eine Regel ist lediglich ein Ausdruck in einer (modifizierten) Scheme-Version. Logisch betrachtet werden jedoch drei verschiedene Regeltypen unterstützt.

Matching-Regeln

Matching-Regeln werden von einem regelbasierten Matching-System verwendet. Matching-Regeln können entweder an eine besondere Instanz eines Matching- Moduls angehängt werden und gelten dann für alle Matches mit diesem Matching-Modul ("globale Matching- Regeln") oder sie können an ein besonderes Element oder eine Location angehängt werden und gelten dann nur, wenn das Element oder die Location zum Matching-Vorgang gehört ("lokale Matching-Regeln").

Vom Ausdruck her sind Matching-Regeln einfach. Als Input erhalten sie die aktuelle Kontextbeschreibung sowie alle mit dem aktuellen element und der Location verbundenen Werte im Matchingvorgang zum Zeitpunkt ihrer Auswertung Ihr Rückgabewert ist eine Fließkommazahl zwischen 0 und 1.

Bei der Konstruktion von Matching-Regeln beschränken wir uns auf die folgende Form:

wobei <predicate< ein normaler Vergleichsoperator oder ein Match-Operator für reguläre Ausdrücke ist. <value< ist entweder ein Ausdruck zum Herausfinden einer Variable aus der Kontextbeschreibung bzw. die element und location-Datensätze oder ein Literalwert. <result< ist eine Fließkommazahl zwischen 0 und 1. Wird ein Literal "t" anstelle der Klausel (<predicate< <value< <value<) verwendet, ist dies eine "catch-all" oder "else"-Klausel. Es kann davon nur eine geben und die Klausel muss am Ende stehen.

Template-Regeln

Template-Regeln befinden sich in den XRTL <ruleset<- Tags und werden während des Renderings ausgewertet. Dabei werden Template-Regeln wie alle Regeln in einem XRTL-Dokument definiert, die nicht einem <content<-Tag stehen. Ihr Zweck besteht darin, daß sie dynamische Änderungen ans XRTL-element-Parametern wie Usage, Location etc. ermöglichen.

Der generische Template-Regelausdruck ist etwas kom­ plexer als eine Matching-Regel: Ihr Input ist die aktuelle Kontextbeschreibung zusammen mit einer Dar­ stellung des XRTL-Parse-Baums, so dass zwischen Regeln in verschiedenen Elementen Interdependenzen entstehen können. Der typische Output ist ein String, der in der üblichen Syntax für den Inhalt des Felds formatiert ist, in dem die Regeln sich befinden.

Template-Regeln sind erheblich komplexer als Matching- Regeln, weil sie zum einen verschachtelte Bedingungen enthalten können, zum anderen weil der Typ ihrer Rückgabewerte beliebig sein kann. Insgesamt sieht die Form folgendermaßen aus:

wobei <predicate< und <value< wie bei Matching-Regeln definiert sind. <result< kann ein beliebiger String sein und <t-rule< bezieht sich auf einen verschach­ telten Bedingungsausdruck, der dieselbe Form hat wie eine Basis-Template-Regel. Theoretisch kann die Ver­ schachtelung beliebig tief sein. Aufgrund einiger systemspezifischer Begrenzungen kann es jedoch nötig sein, eine maximalen Verschachtelungsgrad festzulegen.

Inhaltsregeln

Inhaltsregeln sind Scheme-Ausdrücke in XRTL <ruleset<- Tags innerhalb von <content<-Tags. Ihre Aufgabe besteht darin, die Matching Engine zu initialisieren und zu steuern, so dass diese den Inhalt auswählt, wobei auch spezielle Inhaltsfelder erfasst werden können, und anzeigt.

Der Input für eine Inhaltsregel ist ebenso definiert wie der Input für eine generische Template-Regel. Ihr Output ist eine Liste von Elementen, und wahlweise eine Liste von Feldnamen, die aus diesen elements extrahiert werden.

Wir beschränken uns vorläufig auf die nichtkonditionale Form der Inhaltsregeln. Ihre allgemeine Form sieht wie folgt aus:

wobei ein <field-descriptor< der Name eines Datenfelds ist, das im Output erscheint, ein <matcher-id< der Name des verfügbaren Matching-Modules ist, <max-matches< eine Integerzahl ist, die die maximale Zahl der zurückgegebenen Matches angibt, <criterium< der Name einer SQL-Datenbankspalte in der elements-Tabelle, und <value< der Wert, den die Spalte in <criterium< haben sollte.

Anhang 3 Kategoriesystem des neuronalen Personali­ sierungsmoduls

Das Kategoriesystem orientiert sich grob an der Struktur des Domain Name Systems (DNS). Kategorien sind Bündel von Pfaden durch in Hierarchien angeordnete Begriffe, vom Allgemeinen zum Spezifischen. Kate­ gorisiert werden content element sowie locations.

Die technische Repräsentation einer Kategorie ist eine Menge von Zahlen, die wiederum Indices in hierarchische Begriffstabellen darstellen. Von dieser Repräsentation ausgehend können andere, auf spezifische Matching- und Vergleichsalgorithmen zugeschnittene Repräsentationen erstellt werden. Das Ziel hinter dieser Vorgehensweise ist eine Entkopplung von Kategoriesemantik und -ver­ arbeitung.

Ein Beispiel aus der Praxis

Wir nutzen eine vier-Ebenen-Variante des oben umris­ senen Systems zur Kategorisierung von Websiteinhalten im Rahmen eines Bannerschaltungssystems. Ebene 1 unterscheidet kommerzielle, non-profit, und private Websites; Ebene 2 sortiert diese nach der Art ihres Angebots in produkt- informtions- bzw. service­ orientierte Sites. Ebene 3 erlaubt eine grobe Ein­ stufung des Angebots in eine oder mehrere von 25 Kate­ gorien (z. B. Transportwesen, Sport, Kommunikation, Kunst . . .), und Ebene 4 schließlich beschreibt das Thema des Angebots in Form eines konkreten Themen­ bereiches (z. B. Formel-1, Mobiltelefonie, Arbeits­ recht).

Site- und content element-Kategorisierungen bestehen nun aus einem oder mehreren Pfad(en) durch diese Hierarchie. Eine Fanwebsite zum Thema McLaren-Mercedes- Rennwagentechnik liesse sich zum Beispiel als

Privat→Information→Sport→Formel-1

und

Privat→Information→Automobil→Ingenieurswesen

kategorisieren. Die entstehende Gesamtkategorie ist das kartesische Produkt über alle angegebenen Pfade. Die oben kategorisierte Site wäre also auch ein 100%iger Treffer für die Kategorie

Privat→Infonnation→Automobil→Formel-1.

Für Matching-Zwecke kann je nach Bedarf diese Gesamtkategorie auf verschiedene Arten interpretiert werden. Für neuronales Matching sind in unserem Beispielsystem die oberen drei Ebenen orthogonal kodiert, die vierte Ebene hingegen nach semantischer Nähe überlappend. Für regelbasierte Vergleiche werden die gleichen Daten für einfache Gleichheitstests ohne semantischen Wert genutzt.

Anhang 4

Erweiterungen des Scheme-Interpreters

Liste der Schlüsselwörter für sd

Name of parameter
Reference to
SD	SituationDescription
OT	Any OptionTable in SituationDescription
RS	RequestSource of SituationDescription
LOC	Location in RequestSource of SituationDescription
SRC	source in RequestSource of SituationDescription
RD	request_description of SituationDescription
DESC	description in request_description of SituationDescription
RDT	request_deliverytype in request_description of SituationDescription
RA	request_arrivaltime of SituationDescription
RT	request_target in request_description of SituationDescription
RI	request_id of SituationDescription
RP	request_priority of SituationDescription
RCT	request_contenttype in request_description of SituationDescription

Begriffe und Abkürzungen

AM	Access module
CAM	Content acquisition module
CCM	Content conversion module
client	Im Kontext dieses Dokuments die Bezeichnung für die Kombination aus Computersystem und Programm, welches autonom oder durch den Benutzer gesteuert Anfragen an server Dienste richtet.
cluster	Vebund aus mehreren Computersystemen.
content element	'Inhaltselement', Abstraktion für Komponenten einer Ausgabe
DBM	Database module
DM	Delivery module
DTD	'Document Type Definition' für SGML/[XML]
FSM	Filesystem module
IOR	'stringified [CORBA] object reference', eine Referenz in Zeichenkettenform auf ein Softwareprogramm/-modul, mit dessen Hilfe es von anderen Programmen/Modulen aufgerufen werden kann.
LM	Logging module
node	'Knoten', Ein einzelnes Computersystem aus dem Verbund eines cluster.
Object Level Interface	Ein Satz von Methoden (Funktionen) eines Objektes (Softwareprogramm oder -modul), die das Objekt exportiert, um so von anderen Programmen/Modulen aufgerufen werden können.
ORB	[CORBA] Object Request Broker
PM	Personalization module

Request	Von einem durch ein Benutzer kontrolliertes oder autonomen Programm an ein anderes Computersystem/Programm gerichtete Anfrage
RM	Render module
sd	'situation_description': Eine Datenstruktur, die alle für die Verarbeitung der aktuellen Anfrage relevanten Information vorhält.
server	Im Kontext dieses Dokuments die Bezeichnung für die Kombination aus Computersystem und Programm, welches Anfragen eines client animmt, bearbeitet und das Ergebnis übermittelt.
SGML	Standardised Generalised Markup Language (definiert in [ISO8879]), eine Allzwecksprache für domänenspezifische Auszeichnungssprachen.
template	Eine Dokumentenvorlage (z. B. XRTL-Template, eine Datei, die Anweisungen in Form von XRTL Tags enthält)
Trader	[CORBA] Trading Service
XRTL	Siehe oben Anhang 1

Referenzen

[C], [C++]	Programmiersprachen
[CORBA]	Siehe http://www.corba.org/ und http://www.corba.org/standards.htm.
[DOM]	Siehe http://www.w3.org/DOM/.
[GIF], [JPG]	Formate für das Ablegen von Bilddaten in Dateien.
[HTML]	Siehe http://www.w3.org/MarkUp/
[HTTP]	Siehe http://www.w3.org/Protocols/.
[MPEG]	Siehe http://www.mpeg.org/.
[ODBC], [IODBC]	Siehe http://www.microsoft.com/data/odbc/default.htm und http://www.iodbc.org/index.htm.
[OMG]	Siehe http://www.omg.org/.
[PDF]	Siehe http://www.adobe.com/products/acrobat/readermain.html.
[SCHEME]	Siehe http://www.swiss.ai.mit.edu/projects/scheme/index.html
[SERVLET]	Siehe http://java.sun.com/products/servlet/?frontpage-javaplatform.
[SNMP]	Siehe http://www.snmp.com/protocol/.
[SOAP]	Siehe http://www.w3.org/TR/2000/ NOTE-SOAP-20000508/.
[SQL]	Siehe http://www.sql.org/.
[UNIX], [LINUX]	Multiuser/Multitasking Betriebssysteme. Beispiele für freie und kommerzielle Produkte sind Linux, Solaris oder IRIX.
[URL]	Siehe http://www.w3.org/Addressing/.

[WAP], [WML], [WBMP]	Siehe http://www.wapforum.org/.
[XML]	Siehe http://www.w3.org/XML/
[XMLRPC]	Siehe http://www.xmlrpc.com/spec.
[XSL]	Siehe http://www.w3.org/Style/XSL/.
[XSLT]	Siehe http://www.w3.org/TR/1999/PR-xslt-19991008.

Bezugszeichenliste

1

A verteiltes Computersystem, cluster (CL)

1

B einzelnes Computersystem (CS)

2

Computerprogramm zur Steuerung des Verfahrens

3

vom Nutzer kontrolliertes Computerprogramm

4

vom Nutzer eingesetztes Computersystem

5

autonomes Computerprogramm

6

externes Computersystem, auf welches das Verfahren zur Datengewinnung zugreift

7

externe Datenquelle

8

Steuersprache

9

Anweisungen der Steuersprache

10

An das Computersystem des Nutzers angeschlossenes Endgerät

11

Netzwerk zur Datenübertragung

12

Controller (CO)

13

Trader (TR)

14

Zugriffs-Modul (AM)

15

Personalisierungs-Modul (PM)

16

Inhaltserfassungs-Modul (CAM)

17

Formatkonvertierungs-Modul (CCM)

18

Ausgabeerzeugungs-Modul, Renderer (RM)

19

Interne Datenbank (DBM)

20

Dateisystem (FSM)

21

Logging-Modul (LM)

22

Ausgabe-Modul (DM)

23

Benutzerprofile (UP)

24

Templates (TS)

25

Daten/Informationen/Metadaten

Claims (14)

1. Computersystem zur Erstellung von personalisierten Datenausgaben, dadurch gekennzeichnet, daß es aus einem an ein Netzwerk angeschlossenen Computersystem sowie auf dem Computersystem befindlichen Datenbanken und einen auf dem Computersystem ausgeführten Computerprogramm be­ steht, wobei das Computersystem vereinheitlichende Schnittstellen zur Kommunikation mit Peripherie­ geräten zur Verfügung stellt und bei Anfrage eines Nutzers oder eines anderen, autonomen Computer­ programms auf innerhalb des Systems lokal gespeicherte Informationen und/oder außerhalb des lokalen Systems entfernt gespeicherte Informationen zugreift, die so gewonnenen Informationen zur Laufzeit durch Interpretation von in einer Steuersprache verankerten Anweisungen und unter Nutzung der auf dem Computersystems befindlichen Datenbanken individuell auf den Nutzer bezogen zusammenstellt und das Ergebnis in einer zu dem Endgerät des Nutzers kompatiblen Form ausgibt oder die Ausgabe durch den Nutzer auf einem von ihm gewählten Endgerät realisiert.

2. Computersystem nach Anspruch 1, dadurch gekennzeichnet, daß das Netzwerk ein Kabelnetz und/oder ein Funknetz ist

3. Computersystem nach Anspruch 1, dadurch gekennzeichnet, daß die Peripheriegeräte

• - Computer und/oder
• - Funktelefone und/oder
• - Settop-Boxen

sind.

4. Verfahren zur Erstellung von personalisierten Datenausgaben, dadurch gekennzeichnet, daß
die Datenausgaben auf selektierten Endgeräten erfol­ gen derart, daß in einem ersten Schritt ein erstes Modul eines Computerprogramms, das Zugriffs-Modul (14), eine an das Computerprogramm gerichtete Anfrage interpretiert und für die weitere Bearbeitung der Anfrage nötige Daten in eine erste Datenstruktur einträgt,
in einem zweiten Schritt ein zweites Modul des Computerprogramms, das Ausgabeerzeugungs-Modul (18), aus einer Datenbank (19) zu den in der im ersten Schritt erzeugten ersten Datenstruktur abgelegten Daten gehörige zweite Datenstrukturen ermittelt,
in einem dritten Schritt vom Ausgabeerzeugungs-Modul (18) diese zweiten Datenstrukturen geparst, die dabei ermittelten Elemente analysiert werden und vom Ausgabeerzeugungs-Modul (18) und/oder einem dritten Modul des Computerprogramms, dem Personalisierungs- Modul (15), eine Ergebnisdatenmenge erzeugt wird,
in einem vierten Schritt von einem dritten Modul des Computerprogramms, dem Inhaltserfassungs-Modul (16), die durch die Ergebnisdatenmenge definierten Informationen erfaßt werden,
in einem fünften Schritt diese erfaßten Informationen in ein Format gewandelt wird, welches eine Darstellung der personalisierten Ausgabe auf im ersten Schritt ermittelten Endgeräten (10) ermöglicht und
in einem sechsten Schritt die Ausgabe der personalisierten Informationen erfolgt.

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß die im ersten Schritt ermittelten, in die erste Datenstruktur eingetragenen Daten

• - textbasierten Internet-Protokollen und/oder
• - IMAP-Headern und/oder
• - POP3-Headern

entnommen werden.

6. Verfahren nach einem der Ansprüche 4 oder 5, dadurch gekennzeichnet, daß die im ersten Schritt ermittelten, in die erste Datenstruktur eingetragenen Daten Informationen über

• - den Nutzer des Verfahrens und/oder
• - von diesem Nutzer verwendete Programme und/oder
• - von diesem Nutzer verwendete Geräte

enthalten.

7. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß für jedes zu erzeugende Format der personalisierten Ausgabe ein eigenes Ausgabeerzeugungs-Modul (18) existiert.

8. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß die zweiten Datenstrukturen speichertechnische Entsprechungen der eingelesenen Templates sind.

9. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß die im dritten Schritt erzeugte Ergebnisdatenmenge in einer Baum-Datenstruktur gespeichert wird.

10. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß die im dritten Schritt analysierten Elemente in statische und dynamische Elemente unterteilt werden.

11. Verfahren nach einem der Ansprüche 4 oder 10, dadurch gekennzeichnet, daß für ein statisches Element zur Erzeugung der Ergebnisdatenmenge nur das Ausgabeerzeugungs-Modul (18) aufgerufen wird.

12. Verfahren nach einem der Ansprüche 4 oder 10, dadurch gekennzeichnet, daß für ein dynamisches Element vom Ausgabeerzeugungs- Modul (18) zur Erzeugung der Ergebnisdatenmenge zusätzlich ein Interpreter und anschließend ein Personalisierungs-Modul (15) aufgerufen werden.

13. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß im vierten Schritt Informationen aus eigenen, lokalen Quellen und/oder aus fremden, entfernten Quellen erfaßt werden.

14. Methode zur Ausgabe personalisierter Inhalte auf verschiedenen Endgeräten, dadurch gekennzeichnet, daß ein Anbieter auf einem an ein Netzwerk an­ geschlossenem Computersystem ein auf eine vom Anbieter erstellte Datenstrukturen enthaltende Datenbank zugreifendes Computerprogramm zur Verfügung stellt, Anfragen von Nutzern an dieses Computerprogramms interpretiert und für die weitere Bearbeitung der Anfrage nötige Anfragedaten speichert, in einem weiteren Schritt aus der Datenbank eine durch die Anfragedaten bestimmte Datenstruktur aufruft, parst, die dabei ermittelten Elemente analysiert und aus lokalen und/oder ent­ fernten Quellen durch die Analyseergebnisse fest­ gelegte Informationen erfaßt, wobei diese Informationen durch die Anfragedaten und die Datenstruktur personalisiert wurden, anschließend diese erfaßten Informationen in durch die Anfragedaten festgelegte, mit den Endgeräten des Nutzers kompatible Ausgabeformate wandelt und die Ausgabe der Informationen veranlaßt.