DE19913509A1

DE19913509A1 - Verfahren zum Suchen und Identifizieren relevanter Dokumente

Info

Publication number: DE19913509A1
Application number: DE19913509A
Authority: DE
Inventors: Michael Weiss
Original assignee: Mitel Corp
Current assignee: Microsemi Semiconductor ULC
Priority date: 1998-03-25
Filing date: 1999-03-25
Publication date: 1999-09-30
Also published as: CA2265292C; GB2335761B; CA2265292A1; GB2335761A; GB9806392D0

Abstract

Es wird ein Verfahren zum Durchsuchen elektronisch gespeicherter Dokumente offenbart, das eine soziale Filterung zwischen zusammenarbeitenden Agenten verwendet, um das Anwenderverhalten zu verfolgen und um die Suche zu Dokumenten und zu Informationen zu leiten. In einem Anwenderprofil werden Hintergrundinformationen über jeden Anwender aufgezeichnet. Die Anwenderprofile werden aus einer Trainingsmenge von Seiten oder durch Betrachtung des Anwenderverhaltens gelernt. Das Verfahren erhöht die Anzahl der Suchergebnisse, die vom Anwender wegen einer "Peer-Wirkung" wahrscheinlich als sehr relevant wahrgenommen werden. Damit ist die Verwendung der Besten-Suche für das Web möglich, die eine höhere Leistungsfähigkeit hat als die Tiefen-Suche oder die Breiten-Suche, die in früheren Lösungsversuchen verwendet wurde.

Description

Die Erfindung betrifft ein Verfahren zum Suchen und Identi fizieren relevanter Dokumente und insbesondere eine agenten basierte Web-Suchmaschine, die schlüsselwortbasierte Such vorgänge unter Verwendung eines Anwenderprofils verbessert, um die Suche weiter auf für den Anwender interessante Doku mente zu beschränken. Hierbei wird ein Netz zusammenarbei tender Agenten verwendet, die Informationen anhand des Browsing-Verhaltens anderer, ähnlicher Anwender verfolgen und nutzen.

Frühere Versuche zum Auffinden von Informationen im World Wide Web (WWW) haben automatisierte Suchprogramme (Suchmaschinen) wie etwa WAIS oder Web Crawler (M. Koster, World Wide Web Wanderers, Spiders and Robots; http:// web.nexor.co.uk/mak/doc/robots/robots.html) umfaßt, um Webseiten und Informationen, die für den Anwender nützlich sind, zu lokalisieren. Bei diesen automatisierten Suchma schinen besteht das Problem, daß sie zu viele Suchergebnisse zurückleiten, indem häufig Dokumente mit geringer oder niedriger Relevanz enthalten sind, was die Nützlichkeit der Suche für den Anwender reduziert. Diese typischen Versuche betrachten keinerlei Maß für das Anwenderinteresse bei der Ausführung der Suche. Diese früheren Versuche verwenden ein Nutzenmaß, das lediglich auf den Such-Schlüsselwörtern basiert, die vom Anwender eingegeben werden. Folglich geben diese Such-Versuche sämtliche Dokumente an, die die Suchaus drücke enthalten, einschließlich der Dokumente, die zu Gegenstandsbereichen gehören, die mit dem Interessenbereich des Anwenders nicht in Beziehung stehen. Häufig sind jedoch Hintergrundinformationen verfügbar, die für die Suche ver wendet werden können. Diese früheren Versuche verwenden diese wertvollen Hintergrundinformationen nicht, um Doku mente zu eliminieren, die für den Anwender nicht relevant sind. Daher ist die Zufriedenheit des Anwenders mit diesen früheren Suchmaschinen gering.

Lieberman beschreibt in "Letizia: An Agent that Assists in Web Browsing" International Joint Conference on Artificial Intelligence, 1995, einen Lösungsweg, der einen einzelnen Agenten verwendet, um das Browsing des World Wide Web des Anwenders zu unterstützen. In dem Lösungsweg von Lieberman verfolgt der Agent das Anwenderverhalten und versucht, Dokumente von Interesse durch selbständiges Auswerten von Verbindungen von der momentanen Position des Anwenders vorherzusehen. Dieser Versuch gerät mit Suchzielen des Browsing-Verhaltens des Anwenders in Konflikt und macht unverlangte Empfehlungen bezüglich "interessierender" Doku mente. Einer der Nachteile dieses früheren Lösungswegs besteht darin, daß er sich auf das Verhalten des einzelnen Anwenders konzentriert, ohne andere Informationen zu be trachten, die einem gemeinsamen Interesse in den Dokumenten und Informationen entnommen werden können.

Es ist eine vernünftige Annahme, daß Dokumente und Informa tionen, die für eine Person in einer Gemeinschaft von Inter esse sind, wahrscheinlich auch für andere Personen von Interesse sind. Wertvolle Informationen, die aus dem Browsing-Verhalten anderer Anwender erhalten werden, können für die Fokussierung der Suche verwendet werden. Daher kann ein Lösungsweg genutzt werden, der Informationen bezüglich des Browsing-Verhaltens anderer, dem Anwender "ähnlicher" Anwender verfolgt und verwendet, um den Suchprozeß zur Ermittlung relevanter Dokumente zu erleichtern.

Ferner würde ein Suchmechanismus, der durch Verwenden eines Netzes zusammenarbeitender Agenten für die Verfolgung des Browsing-Verhaltens und für die Führung von Suchoperationen verbessert ist, die Effektivität der Suche verbessern.

Aufgabe der Erfindung ist es, ein Verfahren zum Suchen und Identifizieren relevanter Dokumente zu schaffen, das eine soziale Filterung zwischen zusammenarbeitenden Agenten verwendet, um das Anwenderverhalten zu verfolgen und um die Suche nach Dokumenten und Informationen, die in elektroni scher Form gespeichert sind, zu leiten.

Diese Aufgabe wird entsprechend Anspruch 1 gelöst.

Hierbei werden Hintergrundinformationen über jeden Anwender in einem Anwenderprofil aufgezeichnet. Anwenderprofile werden aus einer Übungsmenge von Seiten oder aus der Beob achtung des Anwenderverhaltens gelernt.

Hierdurch wird die Anzahl der Suchergebnisse erhöht, die vom Anwender wegen einer "Peer-Wirkung" wahrscheinlich als sehr relevant wahrgenommen werden. Dies ermöglicht die Verwendung der Besten-Durchsuchung des Web, die eine bessere Leistung als die Tiefen-Durchsuchung oder die Breiten-Durchsuchung, die bei früheren Versuchen verwendet wurden, besitzt. Dieser Versuch ist außerdem hochgradig skalierbar, da jeder Agent im Vergleich zu anderen bekannten sozialen Filterungsversu chen (z. B. Maes, P. "Agence that Reduce Work and Informa tion Overload", Communications of the ACM, Juli 1994) nur eine kleine Untermenge von Anwendern und Dokumenten verwal tet.

Hierbei wird eine agentenbasierte Web-Suchmaschine geschaf fen, in der Agenten verwendet werden, um Anwender zu unter stützen und Informationen mitzuteilen, um effiziente Such operationen zu erleichtern. Die Daten, die zwischen den Agenten ausgetauscht werden, betreffen Anwenderprofile über einzelne Anwender im Web sowie Webseiten-Profile in bezug auf Besonderheiten verschiedener Webseiten.

Es werden Informationen, die über das Browsing-Verhalten von Anwendern, die dem Informationen suchenden Anwender "ähnlich" sind, gesammelt, indem ein als soziale Filterung bekannter Prozeß verfolgt und verwendet wird. Das Konzept der sozialen Filterung ist von Maes (auf den oben Bezug genommen wurde) und von Lashkari, Y, u. a. "Collaborative Interface Agents", Conference of the American Association of Artificial Intelligence, 1994, beschrieben worden. Die soziale Filterung gründet in ihrer grundlegenden, nicht modifizierten Form ihre Korrelationen nicht auf den Inhalt von Informationen, sondern lediglich auf Korrelationen zwischen den Anwendern oder Betrachtern derartiger Informa tionen. Die soziale Filterung verwendet Informationen über die soziale Umgebung eines Anwenders als Leitfaden für die Lokalisierung relevanter Dokumente und Informationen.

Bei der Implementierung der sozialen Filterung werden Infor mationen über die Interessen der einzelnen Anwender gesam melt. Dann werden während der Suchphase Informationen hin sichtlich der Relevanz gefiltert, indem Daten über die Anwender, die ein Interesse an den Informationen bekundet haben, ausgetauscht werden. Die soziale Filterung ist bei spielsweise erfolgreich auf die Abgabe von Empfehlungen über Musikaufnahmen angewendet worden.

Weitere Ausgestaltungen der Erfindung sind der nachfolgenden Beschreibung und den Unteransprüchen zu entnehmen.

Die Erfindung wird nachstehend anhand der beigefügten Figu ren näher erläutert.

Fig. 1 ist ein Blockschaltplan, der eine Übersicht über ein Netzsystem gibt, in dem der Suchmechanismus implementiert ist.

Fig. 2 ist ein Blockschaltplan eines Suchbaums zum Suchen von Webseiten, der die Verwendung des Verfahrens veranschau licht.

Fig. 3 ist ein Blockschaltplan, der das in Java implemen tierte Verfahren darstellt.

Fig. 4 ist ein Ablaufplan, der die Ausführung der Suchbe fehle veranschaulicht.

Gemäß dem in Fig. 1 dargestellten Netzsystem ist ein Web- Server 110 mit einem lokalen Netz 104 verbunden. Das lokale Netz 104 ist seinerseits mit dem World Wide Web (WWW) 102 verbunden. Ebenso ist ein Web-Server 112 mit dem lokalen Netz 106 verbunden, das mit dem World Wide Web 102 verbunden ist. Die Web-Server 110 und 112 sind Standard-Internet- oder Standard-Intranet-Rechenmaschinen, die Webseiten im "Hypertext Markup Language"-Format (HTML-Format) anzeigen können. HTML ist ein wohlbekanntes Aufzeichnungssystem, das für die Erzeugung von Hypertext-Dokumenten verwendet wird, die von Plattform zu Plattform bewegt werden können. Um die erforderlichen Kommunikationsaufgaben zu erfüllen, verwenden Web-Server 110 und 112 Standard-Netzkommunikationsschemata und das "Internet Hypertext Transfer Protocol" (HTTP), das die Übertragung von Informationen vom Client zum Server ermöglicht. Statt dessen können aber auch andere Dokument formate und Protokolle verwendet werden.

HTML-Webseiten sind im Computerspeicher 114 des Web-Servers 110 gespeichert und für lokale Anwender 118 und 120 sowie für entfernte Anwender 122 und 124 über das World Wide Web 102 zugänglich. Ebenso sind andere Webseiten im Computer speicher 116 des Web-Servers 112 gespeichert, die für lokale Anwender 118 und 120 sowie für entfernte Anwender 122 und 124 über das World Wide Web 102 verfügbar sind. Die lokalen Anwender 118 und 120 sowie die entfernten Anwender 122 und 124 verwenden einen Standard-Web-Browser wie etwa NetScape™ der NetScape Communication Corporation oder den Microsoft Internet Explorer™ der Microsoft Corporation, die die HTML- codierten Webseiten lesen können. Jeder der Anwender 118, 120, 122 und 124 sowie jede Webseite im Speicher 114 und 116 besitzen eine zugreifbare Adresse oder einen Uniform Res source Locator (URL), der von den Anwendern, Agenten oder anderen Netzvorrichtungen zur Lokalisierung und zum Zugriff auf Anwender- oder Webseiten-Informationen verwendet werden kann.

In der zweckmäßigen Ausführung werden Agenten verwendet, um Aufgaben des Anwenders auszuführen, den Anwender zu trainie ren oder zu unterrichten, die Zusammenarbeit verschiedener Anwender zu unterstützen und Ereignisse und Prozeduren zu überwachen. Insbesondere werden verschiedene Anwender- und Webseiten-Profile von Agenten verwaltet. Weiterhin werden Suchoperationen durch die Kommunikation und die Zusammenar beit von Agenten erleichtert. In der zweckmäßigen Ausführung verwenden Agenten eine soziale Filterung, die auf Korrela tionen beruht, die zwischen verschiedenen Anwendern bei der Identifizierung relevanter Dokumente und Informationen gebildet werden.

Wie in Fig. 1 gezeigt ist, verwaltet der Agent 126 ein Spektrum von Anwenderprofilen für lokale Anwender 118 und 120 im Web-Server 110. Der Agent 126 verwaltet außerdem ein Spektrum von Webseiten-Profilen für jede im Speicher 114 des Web-Servers 110 gespeicherte Webseite. Der Agent 128 verwal tet ein Spektrum von Webseiten-Profilen für jede im Speicher 116 des Web-Servers 112 gespeicherte Webseite. Weiterhin verwaltet der Agent 130 das Anwenderprofil des Anwenders 122, während der Agent 132 das Anwenderprofil des Anwenders 124 verwaltet. Besonderheiten der Profile und der Informa tionen, die von den Agenten 126, 128, 130 und 132 verwaltet und ausgetauscht werden, werden im folgenden genauer be schrieben.

Ein Anwenderprofil, wie es vom Agenten 126, 128, 130 und 132 verwaltet wird, ist eine Beschreibung von Hintergrundinfor mationen über einen besonderen Anwender. Es wird durch Identifizieren und Auflisten spezifischer Merkmale oder Interessensbereiche des Anwenders erzeugt. Ein Verfahren zur Darstellung dieses Profils ist eine Vektordarstellung, bei der jedes Element das Interesse des Anwenders hinsichtlich eines besonderen Merkmals darstellt. Daher gibt im allgemei nen Fall in dem Booleschen Merkmalsvektor {u_i, . . ., u_n} jeder Boolesche Wert u_k an, ob das besondere Merkmal k für einen Anwender von Interesse ist. Beispielsweise könnten Vergleichsmerkmale folgendermaßen definiert sein: (a) Fahr zeuge; (b) Sport; (c) Kochen. Falls ein Anwender an Fahrzeu gen und Sport, jedoch nicht an Kochen interessiert ist, würde das Profil durch den Merkmalsvektor {1, 1, 0} darge stellt werden, wobei 1 "wahr" darstellt und 0 "falsch" darstellt. Dieses Profil könnte dann verwendet werden, um eine Korrelation mit den Profilen von Anwendern mit ähnli chen Interessen zu schaffen.

Ein Webseiten-Profil ist lediglich eine Liste der Profile jener Anwender, die das Webseiten-Dokument besucht haben. Es könnte als eine Liste der tatsächlichen Anwenderprofile oder lediglich als ein Zeiger auf den die Profile jedes Anwenders verwaltenden Agenten implementiert sein. Beispielsweise kann in einer Ausführung ein durch einen Agenten aufgebautes Web- Profil als Tabelle von {Merkmal-Anwenderidentifizierung- Interesse}-Tupeln gebildet sein.

Ein Beispiel hierfür ist in der folgenden Tabelle 1 angege ben:

TABELLE 1

Anwenderidentifizierung

Das Webseiten-Profil wird in der gleichen Weise wie ein Webseiten-Trefferzähler aktualisiert, wenn ein neuer Anwen der diese Webseite besucht.

Bevor eine Suche ausgeführt werden kann, müssen Anwenderpro file erzeugt werden. Obwohl Anwenderprofile manuell erzeugt werden könnten, besteht der bevorzugte Lösungsweg darin, Anwenderprofile in einer Lernoperation zu erzeugen. Während der Lernoperation werden Anwendern eine Menge von Webseiten oder Fragen präsentiert, wobei die Anwender gebeten werden, ihr Interesse durch Antworten entweder mit Ja oder mit Nein anzugeben. Trainingsseiten sind in der Weise vorbereitet, daß sie einer Menge von Merkmalen zugeordnet sind, die in das Anwenderprofil aufgenommen werden. Wenn daher die Menge positiver Konzeptbeispiele (oder Webseiten), an denen der Anwender interessiert ist, und die Menge negativer Beispiele (oder Webseiten), an denen der Anwender nicht interessiert ist, gegeben sind, kann die Menge der Merkmale, die interes sierende Seiten von jenen, die den Anwender nicht interes sieren, unterscheiden, durch einen informationstheoretischen Lösungsversuch gelernt werden. Die Verwendung eines informa tionstheoretischen Lösungsversuchs ist offenbart worden von Lang, K. "Newsweeder: Learning to filter News", Twelfth International Conference on Learning, 1995, und M. Passani u. a. "Syskell & Webbert: Identifying Web Sites", AAAI, 97; http://www.ics.uci.edu/''pazzani/RTF/AAAI.html, 1997. Trai ningsseiten, die stark mit einem Anwenderinteresse überein stimmen, werden anschließend dem Anwender als Ausgangspunkte für die Durchsuchung des Web vorgeschlagen. Dadurch wird der zusätzliche Vorteil geschaffen, daß der Anwender zu einem Web-Server geleitet wird, der die agentenbasierte Web-Ser vermaschine unterstützt.

In Fig. 2 ist der Suchbaum, der die typischen Suchaktionen der Anwender nach Fig. 1 darstellt, genauer gezeigt. Die Suche ist durch mehrere Knoten 202, 204, 206, 208, 210, 212, 214, 216 und 218 dargestellt. Jeder der Knoten im Suchbaum entspricht einer Webseite, die sich auf einem unterschiedli chen Web-Server befinden kann. Der Anfangsknoten 202 ist die momentan von einem Anwender empfangene Webseite, wie in Fig. 1 beschrieben worden ist. Die Zweige des Baums stellen Hypertext-Links zwischen den Webseiten dar. Jeder Webseite ist ein Webseiten-Profil zugeordnet, das verwendet wird, um zu verfolgen, welche Anwender diese besondere Webseite besucht haben. Wenn ein Anwender eine Webseite 204 besucht, stellt dies einen guten Hinweis dar, daß sie für diesen Anwender von Interesse ist.

Es könnte ein weiteres, besseres Maß für das Interesse zum Einsatz kommen, gemäß dem die tatsächliche Zeit, die vom Anwender zum Lesen einer Webseite verbraucht wird, aufge zeichnet wird. Dies kann durch eine Profilerzeugungseinrich tung implementiert werden, die dann, wenn ein Anwender erstmals auf die instrumentierten Seiten zugreift, als ein unsichtbares Applet, das in einer geeigneten Sprache wie etwa Java geschrieben ist, heruntergeladen werden kann und Informationen über die Durchgänge eines Anwenders durch die Webseiten sammelt und Nutzungszugriffsmuster einschließlich der bei einer besonderen Seite verbrachten Zeit erfaßt. Ein Beispiel einer solchen Profilerzeugungseinrichtung ist beschrieben worden von C. Shahabi und V. Shah, "Java based profiler for Capturing User Access Patterns" http://imsc.usc.edu/profiler.html, 1997. In dieser Weise kann die Zeit, die zur Betrachtung einer Webseite verbraucht wird, durch das Applet dem Agenten im Web-Server zurückge meldet werden. Falls die Betrachtungszeit in einem bestimm ten Bereich liegt, wird die Seite als interessant für den Anwender angesehen. Der Bereich ist durch einen unteren Schwellenwert, der vom Anwenderagenten gesetzt und einstell bar ist und unterhalb dessen die Seite als uninteressant angesehen wird, und optional durch einen entsprechenden oberen Schwellenwert begrenzt, oberhalb dessen angenommen wird, daß der Anwender die Webseite verlassen hat, anstatt anzunehmen, daß die Seite von hohem Interesse ist. Die besondere Suche, die dargestellt ist, beginnt beim Anfangs knoten 202 des Anwenders. Der Anwender formuliert eine Suche durch die Eingabe eines Schlüsselworts 222. Das Anwenderpro fil 224, das den Hintergrund des Anwenders beschreibt, wird der Suchspezifikation implizit hinzugefügt. Der Anwender hat auch die Option, das Schlüsselwort unspezifiziert zu lassen. Wenn er dies tut, wird das Web nach jedem Dokument durch sucht, das mit dem Anwenderprofil 224 übereinstimmt. Jeder Knoten 202-208 besitzt ein Seitenprofil, in Fig. 2 ist jedoch nur das Seitenprofil 220 gezeigt.

Bei fortgeschrittener Suche wird jeder der Knoten 204-208 daraufhin geprüft, ob er das spezifizierte Schlüsselwort enthält. Wenn dies der Fall ist, wird die Korrelation zwi schen dem Anwenderprofil 224 und dem Seitenprofil für den Knoten berechnet und mit einem Schwellenwert verglichen. Im folgenden wird eine hochentwickelte formale Beschreibung des Prozesses, mit dem der Knoten geprüft wird, beschrieben.

Es wird definiert:
u Anwenderprofil, u = {u₁, . . ., u_n}
u_i gibt an, ob das Merkmal i für den Anwender von Interesse ist
m Übereinstimmungsvektor, m = {m₁, . . ., m_M}
A Seitenprofil, A = {a1, . . . a _M}
θ Schwellenwert
N Anzahl der Merkmale
M Anzahl der Agenten oder Anwenderprofile im Seitenprofil
Die Korrelation zwischen u und A ergibt: u.A = m
Eine Übereinstimmung ist vorhanden, falls: |m| ≧ θ

Jede Spalte von A in dieser Beschreibung entspricht dem Profil eines Anwenders, der die Seite besucht hat. Zu A werden Zeilen hinzugefügt, wenn ein Anwenderbesuch durch den Agenten beim Laden dieser Seite verfolgt wird. Alternativ wird eine Verbindung (Link) zur Anwender-Webseite geschaf fen. Irgendwelche offensichtlichen Optimierungen bezüglich der Weise, in der diese Profile tatsächlich dargestellt werden, die dem Fachmann bekannt sind, finden Anwendung. Es gibt mehrere verschiedene Standardwege zur Berechnung dieser Korrelation. Ein Standardweg, die "Ähnlichkeit" zwischen zwei Merkmalsvektoren zu messen, besteht darin, das nor mierte Vektorprodukt zu berechnen, d. h. ein Kosinus-Ähn lichkeitsmaß zu verwenden. Für den Booleschen Merkmalsvektor besitzt dieses Maß Werte zwischen 0 und 1, wobei die Werte nahe bei 0 einen niedrigen und die Werte nahe bei 1 einen hohen Ähnlichkeitsgrad angeben.

Die Ähnlichkeitsfunktion lautet:

sim(u,v) = Kosinus(u,v)

wobei u und v Merkmalsvektoren sind und Kosinus(u,v) deren normiertes Vektorprodukt ist:

Kosinus(u, v) = (u.v)/(|u|.|v|).

Bei Verwendung dieser Ähnlichkeitsfunktion zur Berechnung der Ähnlichkeit zwischen Vektoren {0, 1, 1, 0, 1} und {1, 1, 0, 0, 1} lautet diese Funktion:

Daher ergibt bei Verwendung der obigen Definitionen, wo u das Anwenderprofil des neuen Besuchers ist und a_k die k-te Spalte im Webseiten-Profil A ist, die Durchschnittsähnlich keit des Anwenderprofils u mit dem Seitenprofil ein Maß für die Korrelation zwischen dem Anwenderprofil u und dem Sei tenprofil A.

Die Korrelation kann durch die folgende Formel ausgedrückt werden:

Dies wird unter Verwendung des Webseiten-Profils der folgen den Tabelle 2 weiter erläutert, in der ein neuer Anwender mit Anwenderprofil {0, 1, 1, 0, 1} die Seite besucht:

Tabelle 2

Anwenderidentifizierung

Die Korrelation wird durch Vergleichen des neuen Anwender profils mit jeder Spalte des Webseiten-Profils unter Verwen dung der Ähnlichkeitsfunktion über das Webseiten-Profil berechnet.

sim(u,a₁) = 0,67
sim(u,a₂) = 0,81
sim(u,a₃) = 1,00
Korrelation (u, A) = (0,67 + 0,81 + 1,00)/3 = 0,83

Eine Übereinstimmung zwischen einem Anwender und einer Seite wird durch Vergleichen der Korrelation mit einem Schwellen wert bestimmt, der im voraus definiert sein kann oder optio nal durch den Anwenderagenten gesetzt wird. Falls beispiels weise der Schwellenwert θ = 0,80 ist, würde für das Anwen derprofil eine Übereinstimmung festgestellt werden und würde das Anwenderprofil als im Seitenprofil enthalten angesehen werden, da 0,83 < 0,80.

Falls das Webseiten-Profil besonders groß ist, könnte es notwendig sein, einige Optimierungstechniken zu verwenden, um die Berechnung zu beschleunigen. Es sind viele Optimie rungen möglich, beispielsweise das Aufsummieren über eine Zufallsprobe von Spalten des Seitenprofils anstatt über sämtliche Spalten des Seitenprofils.

Das Ergebnis der Übereinstimmung kann in mehreren bekannten Weisen dargestellt werden, beispielsweise durch Farbcodie rung der Verbindungen oder durch Ergänzen der Verbindung mit einer numerischen Bewertung, einem Vertrauenspegel, einer Zahl oder eines Prozentsatzes einer Empfehlung (wie bei spielsweise beschrieben ist in Hill u. a. "Recommending and Evaluating in a Vertial Community of Users").

Die Suche wird für jede der Seiten fortgesetzt, die die Suchkriterien erfüllen und nicht durch Testen auf den Schwellenwert eliminiert worden sind. Die Liste der relevan ten Seiten wird verfeinert, bis sie mit keinen der Kriterien übereinstimmen, keine weiteren Verbindungen mit anderen Seiten enthalten oder irgendeine im voraus definierte Grenz zahl von Ergebnissen erreicht. Zirkuläre Verbindungen können durch Testen anhand einer Liste bereits erfolgreich überein stimmender Seiten vor dem Versuch einer Übereinstimmung gehandhabt werden. Die Webseiten, die den Schwellenwert erreichen oder übersteigen, werden dem Anwender präsentiert. In dieser Weise werden Dokumente und Informationen gelie fert, die sowohl die Suchkriterien des Anwenders erfüllen als auch mit den Interessen ähnlicher Anwender korrelieren.

In Fig. 3 ist eine zweckmäßige Ausführung, die in Java implementiert ist, gezeigt. Der Anwenderagent 302 arbeitet als ein Applet, das im WWW-Client 304 gespeichert ist. Der Profilagent 1 (306) ist mit demselben lokalen Netz 300 wie der Anwenderagent 302 verbunden. Der Profilagent 1 (302) ist als eine Java-Anwendung auf dem WWW-Server 308 implementiert und verwaltet die Seitenprofil-Datenbank 310. Der Profil agent 2 (312) und der Profilagent 3 (318) sind auf entfern ten WWW-Servern 314 bzw. 320 vorhanden (www.soccer.com und www.cars.com). Beide WWW-Server 314 und 320 sind in der Weise implementiert, daß sie Java-Anwendungen unterstützen. Der WWW-Client 304, der Profilagent 1 (302), der Profilagent 2 (306) und der Profilagent 3 (318) sind mit Verbindungen mit dem World Wide Web 324 versehen. Der WWW-Client 304 ist ein Standard-Web-Browser wie etwa der NetScape Communicator oder der Microsoft Explorer, während die WWW-Server 306, 314 und 320 Standard-Web-Server wie etwa der NetScape FastTrack- oder Apache-Server sind.

Die Profilagenten 306, 312 und 318 implementieren das HTTP- Protokoll und verhalten sich für den WWW-Client 304 so, wie dies ein typischer WWW-Server tun würde. Jeder Profilagent 306, 312 und 318 implementiert die drei folgenden Befehle: Suchen, Laden und Fragen. Der Suchbefehl wird durch einen Anwender begonnen, um eine Suche auszuführen. Der Ladebefehl wird verwendet, um die Suche zu verfeinern. Der Fragebefehl wird von Profilagenten 306, 312 und 318 verwendet, um die Interessenpegel für die verbundenen Seiten abzufragen. Diese Befehle haben das folgende Format:

search=uid:profile:keywords
load=uid:profile:keywords
ask=uid:profile.

Jedem Anwender wird eine eindeutige Anwenderidentifizierung (= user id = uid) zugewiesen, wenn der Anwender mit dem Anwenderagenten 302 in Kontakt tritt. Jeder Befehl enthält außerdem das Profil des Anwenders, der den Befehl beginnt. Die Schlüsselwörter, die einen Teil der Suche bilden, und die Ladebefehle sind Wörter, die durch Kommas getrennt sind und die der Anwender suchen möchte. Es ist auch möglich, in einer weiteren Ausführung mit jedem Befehl Informationen wie etwa einen Schwellenwert zur Festsetzung der Relevanz einer Seite, die vom Anwender gesetzt wird, zu verschicken.

Nun wird mit Bezug auf Fig. 4 die Verarbeitung der Befehle genauer beschrieben. Der Anwenderagent 402 stellt den Mecha nismus für den Anwender bereit, um sein Anwenderprofil wie oben mit Bezug auf Fig. 1 beschrieben oder unter Verwendung einer separaten Kombinationsbox für die Auswahl von Merkma len zu definieren.

Der Anwenderagent 402 gibt einen Suchbefehl 404 auf den Anfangsbildschirm 403 aus, von dem aus der Anwender seine Suche startet. Der Anwenderagent 402 ist in die Webseite für den Anfangsbildschirm 403 als ein Java-Applet eingebettet. Dieses Applet zeigt eine typische Suchform im HTML-Format mit einem Feld für die Eingabe der Schlüsselwörter 406 und einer Schaltfläche 408 zum Starten der Suche an. Das Applet wird heruntergeladen, wenn die Webseite des Anfangsbild schirms 403 vom WWW-Server wiederhergestellt wird, von der aus der Anwender seine Suche startet. Falls der Applet-Code als "SearchForm.class" im WWW-Server gespeichert ist, würde die HTML-Webseite des Anfangsbildschirms 403 die folgende Aussage enthalten:

Der Anwenderagent 402 stellt im Anfangsbildschirm 403 die Anwenderidentifizierung und das Profil 410 vom WWW-Client wieder her. Die zweckmäßige Ausführung verwendet das Vorhan densein eines "Cookie"-Mechanismus, durch den die Web-Ser ver-Verbindungen (wie etwa die Applets oder die CGI-Skripts) Informationen auf der Clientseite der Verbindung sowohl speichern als auch wiederherstellen können. Ein solcher Mechanismus wird durch die Haupt-Browser, z. B. dem NetScape Communicator, implementiert, wie in der einleitenden Be schreibung des Cookie-Mechanismus in "Persistent Client State HTTP Cookies",

http://www.netscape.com/newsref/std/cookie_spec.html,

beschrieben ist.

Die Cookies sind als Namen/Wert-Paare in einer bezeichneten Datei im WWW-Client gespeichert. Jedem Cookie ist ein Weg und ein optionales Ablaufdatum zugeordnet. Wenn das Java- Applet ein Cookie vom WWW-Client anfordert, wird die Wegkom ponente der Applet-Dokumentenbasis mit dem Wegattribut verglichen, wobei das Cookie dann, wenn eine Übereinstimmung vorhanden ist, für das Applet erkennbar ist. Kommerzielle Browser wie etwa NetScape schaffen eine Java-Klassenbiblio thek für den Zugriff auf Cookies von innerhalb eines App lets.

Der Cookie-Mechanismus wird folgendermaßen angewendet. Wenn ein erstmaliger Anwender (der durch Eingabe einer speziellen uid zusammen mit dem Suchbefehl bezeichnet werden kann) eine Suche über seinen Anwenderagenten 402 startet, erzeugt der Profilagent 412 auf seiten des Servers eine eindeutige Anwenderidentifizierung und schickt sie zum Anwenderagenten 402 zurück. Der Anwenderagent 402 erzeugt dann ein Cookie auf seiten des Clients der Verbindung, das die Anwenderiden tifizierung und das Profil 410 enthält. Beispielsweise repräsentiert das folgende Cookie einen Anwender mit der Anwenderidentifizierung "1234" und dem Anwenderprofil "01101" (das unter Verwendung einer direkten Codierung dem Merkmalsvektor {0, 1, 1, 0, 1} entspricht):

uid = 1234; Profil = 01101; Pfad=/.

Wenn der Anwenderagent 402 anschließend einen Suchbefehl 404 an den Profilagenten 402, der das Cookie erzeugt hat, aus gibt, stellt er die Anwenderidentifizierung und das Profil 410 aus dem Cookie wieder her und schickt es an den Profil agenten 412. Wie oben beschrieben worden ist, enthält ein vollständiger Suchbefehl die Anwenderidentifizierung, das Anwenderprofil und die Liste von Schlüsselwörtern. Bei spielsweise ist der folgende Ausdruck ein Suchbefehl zum Durchsuchen des Web durch einen Anwender mit der Identifi zierung "1234" und dem Profil "01101" nach dem Schlüsselwort "worldcup":

search=1234 : 01101 : worldcup.

Jeder WWW-Server wird mit einer Indexseite eingerichtet, die Anfangsverbindungen enthält, bei denen eine Suche begonnen wird. Dies könnte eine Datenbank von Schlüsselwörtern und zugeordneten Webseiten, die diese Schlüsselwörter enthalten, sein. Diese Datenbank könnte aus einer typischen Suchma schine oder einem Roboter abgeleitet sein. Falls beispiels weise der Anwender eine Verbindung mit einem WWW-Server herstellt, um seine Suche zu beginnen, könnte die Indexseite die folgenden HTML-Anfangsverbindungen enthalten:

Bei Empfang eines Suchbefehls stellt der Profilagent 412 die Indexseite aus seinem WWW-Server wieder her und gibt einen Fragebefehl 414 an einen oder mehrere andere Profilagenten 416 aus, um für jedes Dokument, das mit der Indexseite verbunden ist, Empfehlungen zu erhalten. Bei jedem Fragebe fehl werden die Anwenderidentifizierung und das Profil bereitgestellt. Beispielsweise:

ask=1234 : 01101.

Der Profilagent 416 für die verbundene Seite antwortet mit dem Interessenpegel, der in Verbindung mit anderen Profil agenten 416 unter Verwendung einer Korrelationsfunktion wie etwa der obenbeschriebenen Funktion für das gegebene Profil berechnet wird. Seiten, deren Interessenpegel oberhalb eines bestimmten im voraus definierten Schwellenwertes oder eines optional durch den Anwenderagenten 402 gesetzten Schwellen wertes liegt, werden heruntergeladen und anhand der optiona len Liste von Schlüsselwörtern gefiltert. In einem einfachen Filterungsschema werden Seiten, die die Schlüsselwörter nicht enthalten, aus der Liste der empfohlenen Verbindungen entfernt. Der Profilagent 412 modifiziert dann die Verbin dungen in der ursprünglichen Seite durch Codieren und durch Aufnehmen der Bewertung, wie interessant jede von ihnen für den Anwender wäre, woraufhin er die modifizierte Verbin dungsseite zum Anwenderagenten 402 zurückschickt. Jeder Verbindung wird beispielsweise über die Farbcodierung oder einen numerischen Hinweis auf den Vertrauensgrad die Aussage hinzugefügt, daß die Seite für den Anwender relevant ist.

Für das obige Beispiel könnte der Profilagent 412 die Ver bindungen folgendermaßen ergänzen:

Hierbei wird ein Farbcodierungsschema mit einem Schwellen wert verwendet. Irgendeine Verbindung, die empfohlen wurde und eine Korrelation bei oder oberhalb des Schwellenwerts hat, wird in rot codiert (entsprechend dem Farbcode FF000 im RGB-Format). Jede farbcodierte Verbindung enthält außerdem einen eingebetteten Ladebefehl, der die Anwenderidentifizie rung und das Profil 410 enthält, die zum Profilagenten 412 für diese Seite geschickt werden. Der Ladebefehl ist von der tatsächlichen Verbindung mittels eines "?" getrennt, was eine CGI-Konvention (Common Gateway Interface-Konvention) ist. Der Suchbefehl wird nur einmal aufgerufen. Anschlie ßende Verfeinerungen der Suche werden über Ladebefehle ausgeführt. Beispielsweise:

load=1234 : 01101 : worldcup.

Die Verarbeitung der Lade- und Suchbefehle ist im allgemei nen gleich, mit Ausnahme von zwei Aspekten, die die Auftei lung in zwei Befehle garantieren.

Zunächst ist im Fall des Ladebefehls der durch den Befehl angegebene Host des Empfangsprofilagenten der Hostteil des URL, der den Ladebefehl enthält. Falls beispielsweise der Anwender die Verbindung

http://intranet/home.html?load=1234 : 01101 : worldcup

in der durch den Profilagenten 412 zurückgeschickten Seite wählt, werden im Ladebefehl 419 (über den WWW-Client) an den Profilagenten 420 im Host "Intranet" die folgenden Informa tionen geschickt:

home.html?load=1234 : 01101 : worldcup.

Der Profilagent 420 entnimmt dann aus diesem lokalen Pfad (home.html) und dem aktuellen Ladebefehl (load=1234 : 01101 : worldcup) Informationen.

Dann enthält die Seite, die vom Profilagenten 402 als Ant wort auf einen Ladebefehl 419 zurückgeleitet wird, ein Java- Applet 422, das die Zeit überwacht, die der Anwender mit dem Lesen der Seite verbringt, wobei der Profilagent 420 diese Zeit dann als Hinweis auf die Interessiertheit verwendet.

Weitere Informationen hinsichtlich der Tatsache, wie Empfeh lungen von anderen Profilagenten erbeten werden und wie der Interessenpegel, der in einer besonderen Seite durch einen Benutzer angezeigt wird, gemessen werden, werden im folgen den beschrieben.

Bei Empfang eines Suchbefehls 404 oder eines Ladebefehls 419 stellt zunächst ein Profilagent 412 oder 420, je nach Fall, die geeignete Seite vom WWW-Server am gleichen Ort wieder her. Dies ist entweder eine Indexseite oder die Seite in dem Pfad, die zusammen mit dem Suchbefehl oder dem Ladebefehl verschickt wurde. Der Profilagent 412 oder 420, je nach Fall, entnimmt dann Verbindungen zu anderen Seiten aus dem Dokument. Für jede Verbindung stellt der Profilagent 412 oder 420 eine Socket-Verbindung mit dem entfernten Profil agenten 416 oder 426 unter Verwendung des URL für diese Verbindung her. Dies ist nicht notwendig, falls die Seite sich bereits auf dem lokalen WWW-Server befindet und vom selben Profilagenten überwacht wird. Der Profilagent 412 oder 420 schickt dann einen Fragebefehl 414 oder 424 an den oder die Profilagenten 416 oder 426 für die verbundene Seite und wartet auf die Antwort bezüglich des Interessenpegels (Korrelation) für diese Seite. Der Profilagent 416 oder 426 für die verbundene Seite berechnet die Korrelation zwischen dem spezifizierten Anwenderprofil 410 und den für diese Seite in der Seitenprofil-Datenbank gespeicherten Profilen und schickt sie an den Profilagenten 412 oder 420 (je nach Fall) als Interessenpegel zurück. Dann wird der Socket gegebenenfalls deinstalliert.

In dem Beispiel von Fig. 3 würde der Anwenderagent 302 zunächst einen Suchbefehl mit der uid 1234, dem Profil 01101 und dem Schlüsselwort "worldcup" an den Profilagenten 306 schicken, der dann die Seite intranet/index.html für den WWW-Server 308 laden würde. Dann schickt der Profilagent 1 (306) Fragebefehle mit derselben uid und demselben Profil an den Profilagenten 2 (312) im Host www.soccer.com und an den Profilagenten 3 (318) im Host www.cars.com. Aus den Antwor ten würde der Profilagent 1 (306) dann eine modifizierte Indexseite mit eingebetteten Ladebefehlen zusammenfügen. Falls der Anwender nun die Verbindung "Soccer" wählt, wurde der WWW-Client 104 eine Verbindung mit dem Profilagenten 2 (312) herstellen, der den Pfadabschnitt des URL zum Namen einer lokalen Seite (index.html), die aus dem WWW-Server www.soccer.com wiedergewonnen werden soll, sowie einen Ladebefehl von den Profilagenten, die mit der Index.HTML- Seite verbunden sind, analysiert und zum WWW-Client 304 eine modifizierte Seite zurückschickt.

Um die Zeit, die für die Betrachtung einer Seite verbraucht wird, zu erfassen, wird ein Anwenderagent-Applet, das die Zeit mißt, beim Laden der Seite zum WWW-Client 304 gestar tet. Wenn der Anwender zu einer anderen Seite wechselt (indem er einer Verbindung folgt oder indem er einer der Browser-Schaltflächen wie etwa "zurück" "vorwärts" usw. folgt), meldet der Anwenderagent 302 die verbrachte Zeit, in der die Seite sichtbar war, an den Profilagenten 312, von dem die Seite geladen wurde. Das Applet des Anwenderagenten 302 ist als unsichtbares Java-Applet implementiert, das in die Webseite eingebettet ist, die vom Profilagenten 312 heruntergeladen wird. Zur Veranschaulichung wird angenommen, daß der Code für den Anwenderagenten 302 in der Datei "TimeTracker.class" enthalten ist, so daß die durch den Profilagenten 312 zusammengefügte Seite beispielsweise die folgenden Aussagen enthalten muß:

Der Profilagent 312 auf der Serverseite zeichnet die vom Anwenderagenten 302 geschickten Informationen auf, die die Anwenderidentifizierung, das Anwenderprofil, die zum Lesen der Seite verbrauchte Zeit und den URL der geladenen Seite enthalten. Diese Informationen werden dann verwendet, um das Profil für diese Seite in der Seitenprofil-Datenbank 316 zu aktualisieren. Wie oben beschrieben worden ist, wird eine Seite als interessant für den Anwender angesehen, wenn die zum Lesen der Seite verbrachte Zeit in einem bestimmten Bereich liegt. Für derartige Seiten wird das Anwenderprofil dem Seitenprofil in der Seitenprofil-Datenbank 316 an der durch die Anwenderidentifizierung angegebenen Position hinzugefügt. Falls ein Eintrag für den Anwender im Profil bereits bestanden hat, wird es überschrieben. Diese prozedu rale Wechselwirkung zwischen dem Anwenderagenten 302 und dem Profilagenten 312 wird für alle weiteren Profilagenten, die mit dem Anwenderagenten während der Suche in Wechselwirkung stehen, verfolgt.

Claims

1. Verfahren zum Suchen und Identifizieren relevanter Dokumente aus einer elektronischen Suche, mit den folgenden Schritten:

(a) Definieren eines Anwenderprofils für einen Anwender, der eine Suche ausführen will;
(b) Anbringen eines Dokumentenprofils an jedem suchfähigen Dokument;
(c) Gewinnen von Suchparametern vom Anwender;
(d) Anbringen des Anwenderprofils an der Suche;
(e) Beginnen der Suche mit den Suchparametern;
(f) Suchen der suchfähigen Dokumente, um Kandidatendokumente zu identifizieren;
(g) Vergleichen des Anwenderprofils mit dem dem Kandidaten dokument entsprechenden Dokumentenprofil mittels sozia ler Filterung, um eine erfolgreiche oder nicht erfolg reiche Übereinstimmung festzustellen; und
(h) Zurückleiten des Kandidatendokuments zum Anwender, falls die Übereinstimmung erfolgreich ist.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß Suchparameter verwendet werden, die ein oder mehr Schlüsselwörter enthalten.

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß ein Dokumentenprofil verwendet wird, das Anwender profile von Anwendern enthält, die ein Interesse am Dokument zum Ausdruck gebracht haben.

4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Anwenderprofile und die Dokumente durch Agenten verwaltet werden.

5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Vergleichen mittels sozialer Filterung durch zusammenarbeitende Agenten ausgeführt wird.

6. Verfahren zum Bewerten von Dokumenten und zum Iden tifizieren relevanter Dokumente in einer elektronischen Suche, mit den folgenden Schritten:

(a) Erzeugen eines Suchbefehls von einer Anwenderentität, wobei der Suchbefehl eine Anwenderidentifizierung, ein Anwenderprofil und ein Such-Schlüsselwort enthält;
(b) Suchen eines Indexes, der Dokumenten-Schlüsselwörter und entsprechende verbundene Dokumente enthält, wobei die verbundenen Dokumente Dokumentenprofile besitzen;
(c) Lokalisieren einer oder mehrerer Übereinstimmungen zwischen dem Such-Schlüsselwort und den Dokumenten- Schlüsselwörtern im Index;
(d) Fragen nach Empfehlungen in den verbundenen Dokumenten, die den Übereinstimmungen der Dokumenten-Schlüsselwörter entsprechen, für die Anwenderidentifizierung anhand des Anwenderprofils;
(e) Berechnen eines Bewertungspegels für das Interesse an den Empfehlungen für jede Übereinstimmung mittels sozia ler Filterung unter Verwendung des Anwenderprofils und des Dokumentenprofils;
(f) Zurückleiten relevanter Dokumente der verbundenen Doku mente anhand der Übereinstimmungen zur Anwenderentität, dessen Bewertungspegel hinsichtlich des Interesses ober halb eines Schwellenpegels liegt.

7. Verfahren nach Anspruch 6, dadurch gekennzeichnet daß die Bewertung des Interessenpegels durch die folgende Korrelationsformel berechnet wird:
wobei:

(a) u das Anwenderprofil ist;
(b) a _k die k-te Spalte des Dokumentenprofils ist;
(c) M die Anzahl der Anwenderprofile im Dokumentenprofil ist; und
(d) sim(u,a _k) die Ahnlichkeit zwischen dem Anwenderprofil und der k-ten Spalte des Dokumentenprofils ist.