DE60222871T2

DE60222871T2 - Anordnung und Verfahren zum Schutz von Endbenutzerdaten

Info

Publication number: DE60222871T2
Application number: DE60222871T
Authority: DE
Inventors: Helena Lindskog; Mikael Nilsson
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2002-07-01
Filing date: 2002-07-01
Publication date: 2008-07-24
Anticipated expiration: 2022-07-02
Also published as: EP1379045B1; EP1379045A1; US20050188220A1; ATE375670T1; DE60222871D1

Description

Technisches Gebiet
Die vorliegende Erfindung bezieht sich auf eine Anordnung und ein Verfahren zum Schutz von Endnutzerdaten, allgemeiner von persönlichen Profildaten eines Endnutzers in einem Kommunikationssystem mit einer Anzahl von Endnutzerstationen und einer Anzahl von Dienst-/Informations-/Inhalts-Anbietern.
Stand der Technik
Persönliche Profildaten von Endnutzern neigen dazu, mehr und mehr an verschiedenen Orten, beispielsweise im Internet, verteilt zu werden. Mit der schnellen Entwicklung von globalen Datenkommunikationsnetzwerken wird es möglich, Daten sowohl über feste als auch über drahtlose Anwendungen zu verteilen. Auch werden Daten in einem sogar [noch] höheren Ausmaß als bisher ausgestoßen, beispielsweise von Firmen an Endnutzer, andere Firmen usw., und sowohl mobile als auch nicht mobile Endnutzer des Internets müssen sich auf Dienstanbieter verlassen und diesen vertrauen. Die Dienstanbieter wiederum fordern, dass die Endnutzer viele persönliche Informationen bereitstellen, um in der Lage zu sein, die Endnutzer richtig zu bedienen, und möglicherweise aus anderen Gründen. Jedoch kann die persönliche Information leicht missbraucht werden, beabsichtigt oder unbeabsichtigt, und doch wird immer noch sehr wenig getan, um die Datenschutzrechte der Endnutzer zu schützen. Dies ist ein ernsthaftes Problem. Dies wird auch zur Folge haben, dass sich weniger Endnutzer einschreiben oder den Vorteil nehmen von allen Diensten, die für sie nützlich sein könnten, was auch nachteilhaft ist. Daher erhöht sich die Notwendigkeit von Mitteln zum Schützen der Geheimhaltung bzw. des Datenschutzes. Für den einzelnen Endnutzer ist es außerordent lich wichtig, dass seine persönliche Information vor einer unkontrollierten Verteilung unter den Dienstanbietern, anderen Endnutzern, Firmen usw. geschützt werden können. Zur selben Zeit, wie beispielsweise die Anzahl der Dienste zunimmt, die Endnutzern beispielsweise über das Internet bereit gestellt werden können, wird es für Dienst- und Informationsanbieter stets interessanter, in der Lage zu sein, ausführliche Information über die Nutzer einzuholen. Dies kann in Konflikt mit dem Aspekt der Sicherheit (beispielsweise des Datenschutzes bzw. der Geheimhaltung) für die Endnutzer sein, ebenso wie es selbstverständlich auch für die Endnutzer attraktiv sein kann, weil sie ebenfalls einen Vorteil daraus ableiten können, dass persönliche Information verteilt wird und sie dadurch andere nützliche oder gewünschte Information usw. erhalten. Für statistische Zwecke ist es beispielsweise für Firmen interessant, Information zu bekommen, um mit dem Bedarf an Diensten, Produkten usw. vertraut zu werden. Ein Endnutzer kann heutzutage persönliche Profildaten verschiedener Arten an verschiedenen Orten gespeichert haben, die vielfältige Arten von Informationen über den Benutzer enthalten, wie etwa den Namen, die Adresse, bestimmte Gewohnheiten, Hobbys, Konten, finanzielle Situation usw. So wird es für die Dienst-/Inhaltsanbieter außerordentlich wichtig, die Merkmale von bestehenden und potentiellen Kunden zu kennen, um eine zielgerichtete Werbung usw. zu ermöglichen, gleichzeitig wie es für den Endnutzer ebenfalls außerordentlich wichtig ist, in der Lage zu sein, die persönlichen Profildaten richtig zu schützen.
Daher gibt es einen inhärenten Konflikt zwischen verschiedenen Interessen. Folglich wurden in einer wachsenden Anzahl von Ländern, wie etwa beispielsweise innerhalb der Europäischen Union, Gesetze und Anordnungen geschaffen, um die Zugänglichkeit zu Information, die der Geheimhaltung unterliegt bzw. die Privatsphäre betrifft, zu beschränken. Derartige Gesetze und Anordnungen variieren häufig von ei nem Land zum anderen, haben jedoch im allgemeinen gemeinsam, dass der Konsument oder der Endnutzer die Kontrolle über sein oder ihr Profil haben sollte, einschließlich der Bedingungen für die Freigabe derselben.
Es sind Lösungen vorgeschlagen worden für Systeme zum Schutz von persönlichen Profildaten von Benutzern, die als eine Art von Safe fungieren oder als eine Profilablage bzw. ein Profilverwahrungsort funktionieren. Die Profile können durch Ersetzen der Benutzeridentität, beispielsweise der mobilen Telefonnummer, durch einen Code so gespeichert werden, dass es keine Verbindung durch das Netzwerk zu der Benutzeridentität geben wird. Derartige Verwahrungsorte oder Speichermittel für Nutzerprofile können an verschiedenen Knoten innerhalb des Netzwerks angeordnet werden. Ein Beispiel bezieht sich auf ein Profilverwaltungsmittel, das zwischen einem Portal und einem Werbungsknoten bereit gestellt wird. Es wird dann angenommen, dass das persönliche Profil zu dem Werbungsknoten übertragen worden ist, wobei die Benutzeridentität in der Form einer mobilen Telefonnummer (MSISDN) ersetzt ist durch einen Code, der völlig ohne Zusammenhang mit der Telefonnummer ist. Der Vorgang wird dann so sein, dass das Portal eine Werbung für einen Benutzer, beispielsweise mit einer Telefonnummer, anfordert. Das Profilverwaltungsmittel leitet die Anforderung dann an den Werbungsknoten weiter, wobei die mobile Telefonnummer in einen entsprechenden Code umgewandelt ist. Der Werbungsknoten gibt anschließend die Werbung zurück an das das persönliche Profil verwaltende Mittel, das anschließend die Werbung an das Portal zurückgibt. Ein derartiges System ist beispielsweise bekannt unter der Handelsmarke Respect^TM, und ist eine Plattform für E-Business ist, die eine Geheimhaltungssteuerung, ein Identitätsmanagement und eine unverzügliche Personalisierung für Online-Transaktionen ermöglicht. Das Profilverwaltungsmittel wird dann durch den Respect^TM Server dargestellt, der eine bei dem mobilen In ternet-Dienstanbieter angeordnete, virtuelle Infrastruktur ist.
Es gibt jedoch einige, den oben beschriebenen Systemen zugeordnete Probleme. Ein Hauptpunkt ist die Transaktionskapazität des das Profil schützenden Mittels. Normalerweise ist die Anzahl von Nutzen, die verarbeitet werden können, begrenzt, was für Echtzeitanwendungen zu ernsthaften Problemen führt. Mit Verweis auf das oben angegebene Beispiel, gilt hier, dass Werbungen präsentiert werden müssen, wenn ein Endnutzer tatsächlich eine bestimmte Seite besucht oder auf einen bestimmten Dienst zugreift, und viele Operationen sind zeitkritisch. Das Zeitkritikalität ist insbesondere in drahtlosen Umgebungen wichtig.
US Patent 6,005,939 zeigt ein Verfahren und eine Anordnung, um Zugang zu einer Internetwebseite zu erlauben. Ein Benutzer spezifiziert einmal eine bestimmte Information, und die Information kann jedes Mal dann benutzt werden, wenn der Benutzer auf eine beliebige Seite in dem öffentlichen Netzwerk zugreift.
Es wird ein Geleitbrief- bzw. Ausweissystem mit einem einzigen Aufbewahrungsort für Benutzerinformation und einem Ausweis-Zugangsanbieter zum Zugreifen auf die Nutzerinformation (in dem Aufbewahrungsort) und zum Bereitstellen eines Ausweises an einen Anfrager benutzt. Ein Ausweis-Agent (umfassend einen Ausweis-Server und eine Ausweis-Datenbank) sind mit dem Internet verbunden. Ein Benutzer speichert darin einmal Information und kann (wahlweise) einen Sicherheitsgrad für ein jeweiliges Teilstück von Information zugewiesen bekommen. Der Agent enthält eine Sicherheits-/Authentifizierungsfunktion.
Wenn ein Benutzer eine Transaktion auf einer Webseite auszuführen wünscht, dann fordert er mit einer verschlüsselten Nachricht den Ausweis-Agenten auf, die spezifische Benutzerinformation für die Webseite freizugeben. Der Agent ist zuvor mit einem Kodierungsschlüssel versehen worden, und entschlüsselt die Anfrage, um zu bestimmen, zu welcher Webseite ein Ausweis zu schicken ist. Dann werden verschlüsselte Daten von dem Agenten an die Webseite bereit gestellt, die bereits einen öffentlichen Schlüssel von dem Benutzer empfangen hat, so dass die Webseite das verschlüsselte Datum decodieren kann.
Jedoch ist dieses System nicht sicher genug und insbesondere nicht flexibel genug zugleich wie persönliche Daten gesichert werden. Des weiteren gibt es im Wesentlichen keine Möglichkeit für einen Dienstanbieter, unter gebührender Berücksichtigung der Erfordernisse bezüglich Benutzersicherheit, die Benutzer in einer optimierten Weise gemäß den Vorlieben oder Erfordernissen der Benutzer zu bedienen.
Es ist sicher, dass ein vollständiger Schutz von persönlichen Profildaten von Endnutzern niemals garantiert werden kann, eine beliebige Lösung kann im Prinzip von einer arglistigen Partei geknackt werden, doch lassen die bisher gemachten Vorschläge noch eine Menge zu wünschen übrig.
Zusammenfassung der Erfindung
Es ist daher eine Aufgabe der vorliegenden Erfindung, eine Anordnung und ein Verfahren bereitzustellen, durch die bzw. durch das persönliche (Profil-)Daten von Endnutzern in einem hohen Ausmaß geschützt werden können, insbesondere so viel, wie das von den meisten Endnutzern, die noch immer von den verfügbaren Diensten Gebrauch machen wollen und den Vorteil ausnutzen wollen, gefordert wird. Es ist auch eine Aufgabe der Erfindung, eine Anordnung bereitzustellen, die es einem Endnutzer möglich macht, einem Dienstanbieter bis zu einem solchen Grad zu vertrauen, dass es dem Dienstanbieter erlaubt wird, die persönlichen Daten beispielsweise für statistische und andere Zwecke zu benutzen, wobei dem Endnutzer immer noch die Genugtuung gegeben wird, dass die Daten kaum missbraucht werden können.
Darüber hinaus ist es eine Aufgabe, eine Lösung bereitzustellen, mit der Endnutzerdaten durch den Endnutzer in einem solchen Ausmaß bereitgestellt werden können, dass auch der Dienstanbieter die Daten in einem solchen Ausmaß benutzen kann, dass er in der Lage ist, dem Endnutzer optimal zu bedienen. Es ist insbesondere eine Aufgabe, eine Lösung bereitzustellen, mit der eine Vereinbarung zwischen einem Endnutzer und einem Dienstanbieter geschlossen werden kann, die sehr schwierig zu brechen ist. Es ist eine allgemeine und hauptsächliche Aufgabe der Erfindung, eine Anordnung und ein Verfahren bereitzustellen, die bzw. das einen Missbrauch von persönlichen Daten besonders schwierig machen und unwahrscheinlich geschehen lassen, und so dass der Endnutzer sich sicher fühlen kann, wenn er persönliche Daten ausgibt.
Daher werden eine Anordnung und ein Verfahren vorgeschlagen mit den Merkmalen der unabhängigen Ansprüche. Vorteilhafte Implementierungen werden durch die beigefügten abhängigen Ansprüche bereitgestellt.
Kurze Beschreibung der Zeichnungen
Die Erfindung wird im Folgenden in einer nicht beschränkenden Weise und mit Verweis auf die beigefügten Zeichnungen vollständiger beschrieben, wobei gilt:
1 ist ein schematisches Blockdiagramm, welches das er finderische Konzept veranschaulicht,
2A ist ein Blockdiagramm, das eine Implementierung des erfinderischen Konzepts beschreibt,
2B ist ein Blockdiagramm, das eine andere Implementierung des erfinderischen Konzepts beschreibt,
3 ist ein Kommunikationsdiagramm, das den Nachrichtenstrom gemäß einer ersten Implementierung veranschaulicht,
4 ist ein Diagramm, das den Nachrichtenstrom gemäß einer zweiten Ausführungsform veranschaulicht,
5 ist ein Schaubild, das den Nachrichtenstrom veranschaulicht, und das vier verschiedene Implementierungen andeutet,
6 beschreibt den Vorgang, der die Benutzung eines Schutzservers veranschaulicht, und
7 ist ein Ablaufdiagramm, das eine Implementierung des erfinderischen Konzepts beschreibt.
Ausführliche Beschreibung der Erfindung
1 ist eine allgemeine Übersicht einer grundlegenden Implementierung des erfinderischen Konzepts. Die Anordnung umfasst einen dazwischen geschalteten bzw. vermittelnden Proxyserver 2, der ein erstes Kommunikationsprotokoll zur Kommunikation mit einer Endnutzerstation (Benutzer-Agent) 1 unterstützt. Der vermittelnde Proxyserver 2 ist in einer Ausführungsform innerhalb der persönlichen Umgebung des Endnutzers, beispielsweise in einem Home-PC, angeordnet. In einer alternativen Ausführungsform ist er innerhalb eines Intranets angeordnet. Gemäß noch einer anderen Ausführungsform ist er in den Räumlichkeiten des Betreibers angeordnet. Der vermittelnde Proxyserver unterstützt auch ein zweites Kommunikationsprotokoll zur Kommunikation mit einem Schutzserver 4.
In einer Implementierung wird ein Zertifikat des Schutzservers 4 bei einer vertrauenswürdigen Drittpartei, wie etwa dem Betreiber, der es verkauft hat, registriert und Zertifikate des Schutzservers werden dem vermittelnden Proxyserver 2 in irgendeiner Weise verfügbar gemacht. Die Aufgabe des vermittelnden Proxyservers ist es, die Echtheit eines Schutzservers 4 zu überprüfen, beispielsweise durch Anfragen eines Zertifikats und, in einer bestimmten Implementierung, von signiertem Inhalt aus dem Schutzserver 4 über das zweite Kommunikationsprotokoll und durch Vergleichen desselben mit in einem Zertifikatspeichermittel 3 gespeicherten, veröffentlichten Zertifikaten. Es sollte deutlich sein, dass die Überprüfung der Echtheit (beispielsweise Authentizität) des Schutzservers auch in anderen Weisen durch den vermittelnden Proxyserver ausgeführt werden kann.
Das erste Kommunikationsprotokoll kann ein sicheres Protokoll sein, jedoch ist dies nicht notwendig für das Funktionieren des erfinderischen Konzepts. Auch das zweite Kommunikationsprotokoll kann ein sicheres Protokoll sein, beispielsweise IPSec oder HTTPS, jedoch ist auch dies nicht notwendig. Sowohl das erste als auch das zweite Kommunikationsprotokoll können ein sogenanntes sicheres Protokoll sein, jedoch muss dies keines von beiden sein, alternativ kann eines von ihnen, entweder das erste oder das zweite, ein sicheres Protokoll sein. Im Prinzip ist jede beliebige Variation möglich. Der Schutzserver 4 ist in einer Implementierung ein HTTP Proxy mit einer Datenbank 5 mit Tabellen, die Information gemäß den relevanten Grundsätzen bzw. Leitlinien enthalten, um in der Lage zu sein, dem Dienstanbieter das bereitzustellen, was benötigt wird und was nach den Leitlinien verfügbar ist. Der Schutzserver umfasst eine Anfrage-API (Englisch: Application Programming Interface, Anwendungsprogrammierungsschnittstelle), um zu ermöglichen, dass Anfragen oder Fragen an die Datenbank gerichtet werden. Der Schutzserver umfasst ferner eine einfache Verwaltungs-API, so dass eine IP (Internetprotokoll) Nummer eingestellt werden kann und so dass Veränderungen an den Da teien mit den Geheimhaltungsleitlinien des Dienstproviders ausgeführt werden können. Wenn der Schutzserver 4 gekauft wird, wird in einer Implementierung, wie oben erwähnt, dessen Zertifikat bei einer vertrauenswürdigen Drittpartei registriert. Der Schutzserver 4 kommuniziert mit dem Dienstanbieter über ein drittes Kommunikationsprotokoll, beispielsweise HTTP.
In einer Implementierung werden die Präferenzen des Endbenutzers in dem vermittelnden Proxyserver 2 verwaltet. Jedoch werden in einer alternativen Ausführungsform die Benutzerpräferenzen in der Endnutzerstation verwaltet. Immer noch weiters können die Endnutzerpräferenzen mit dem Benutzer vereinbart werden, indem er sich durch diese durchklickt. Nach der Verhandlung können sie zwischengespeichert oder gespeichert werden, so dass die Vereinbarung zu einer späteren Zeit schneller abgearbeitet werden kann. Wenn keine Veränderung gewünscht ist, kann das beispielsweise OK bedeuten. Allgemein sollte der Schutzserver eine API bereitstellen, die dem Dienstanbieter die Möglichkeit gibt, die Grundsätze bzw. Leitlinien von Einsatzorten und Seiten unter Berücksichtigung des Grads der Geheimhaltung zu verändern, so dass wenn beispielsweise der Geheimhaltungsgrad angehoben wird, die betroffenen Daten gelöscht werden sollten, usw. Ferner muss der Schutzserver 4 an den vermittelnden Proxyserver 2 Antworten auf Anfragen bereitstellen, beispielsweise was Zertifikate, mögliche Signaturen usw. betrifft. Des Weiteren sollte er dem vermittelnden Proxyserver 2 Antworten auf Anfragen nach Vereinbarungen, die sich auf die Leitliniendateien beziehen, und/oder Aussagen in natürlicher Sprache bereitstellen. Immer noch weiters stellt er eine Anfrage-API bereit, an die durch den Dienstanbieter gemäß den Einstellungen der Leitlinien Anfragen gerichtet werden können.
2A zeigt in einer etwas ausführlicheren Weise eine Implementierung des erfinderischen Konzepts. Es wird hier angenommen, dass der vermittelnde Proxyserver 2A mit Verwaltungsmitteln, die die veröffentlichten Zertifikate 3A verwalten, in Kommunikation ist. Die Endnutzerstation umfasst hier einen PC 1A, der Anfragen an den vermittelnden Proxyserver unter Benutzung von HTTP(S) sendet. Die Funktion ist die gleiche wie oben. Der Schutz-Proxyserver 4A umfasst Speichermittel mit drei Tabellen oder drei getrennten Datenbanken DB1 5A₁ , DB2 5A₂ , DB3 5A₃ . Es sollte deutlich sein, dass die Anzahl der Tabellen nicht auf drei beschränkt ist, sondern dass jede beliebige relevante Anzahl von Tabellen und/oder getrennten Verwaltungsmitteln implementiert werden können; verschiedene Tabellen in ein und derselben Datenbank beziehen sich auf eine Implementierung.
Der Schutz-Proxyserver 4A weist SQL zulassende Fragen auf, die aus dem/der Dienstanbieter(-anwendung) 6A heraus an die Datenbank(en) 5A₁ , 5A₂ , 5A₃ gerichtet werden können. [Es sollte deutlich sein, dass SQL nur ein Beispiel unter vielen, beispielsweise LDAP (Englisch: Lightweight Directory Access Protocol, leichtes Verzeichniszugangsprotokoll) darstellt.] Es wird angenommen, dass der vermittelnde Proxyserver 2A von dem Schutzserver 4A über eine IPSec Verbindung (oder eine andere Verbindung) ein Zertifikat und einen signierten Inhalt anfordert, überprüft, dass das Zertifikat zu einem Schutzserver bei der vertrauenswürdigen Drittpartei gehört, und zwar durch Vergleichen des angeforderten Zertifikats mit den aus den Zertifikatverwaltungsmitteln 3A verfügbaren, veröffentlichten Zertifikaten, wobei der [Verwaltungsmittel] aktuelle Verwaltungsmittel sein können, oder über das Internet oder in jedweder anderen Weise. Es ist tatsächlich nicht erforderlich, ein Verarbeiten der Zertifikate zu implementieren, denn beispielsweise kann eine Liste von Schutzservern auch über das Internet verfügbar sein. Es wird auch angenommen, dass in dieser Implementie rung der vermittelnde Proxyserver 3A eine P3P Vereinbarung (P3P = Englisch: Platform for Privacy Preferences Projekt, Plattform für das Projekt bezüglich Geheimhaltungspräferenzen) ausführt, die ein Protokoll spezifiziert, das eine automatisierte Weise für Benutzer bereitstellt, eine Steuerung über die Benutzung der persönlichen Daten auf besuchten Webseiten zu erlangen. Die Erfindung umfasst Sicherheitskommunikationsvereinbarungen im Allgemeinen, wie beispielsweise P3P, Vereinbarungen in nationaler Sprache, usw., die auf dem Gebiet der Geheimhaltung benutzt werden. Demgemäß werden Webseiten in die Lage versetzt, ihre Geheimhaltungspraktiken in einem maschinenlesbaren XML-Format (XML = Englisch: Extensible Markup Language, erweiterbare Markierungssprache) auszudrücken, wobei das Format automatisch hervorgeholt und mit den Geheimhaltungspräferenzen eines Endnutzers verglichen werden kann. Dies macht es für einen Endnutzer möglich, eine Entscheidung darüber zu treffen, einen Teil der Stück persönlichen Information an eine bestimmte Webseite einzureichen oder nicht. Wie oben genannt, können die Präferenzen eines Benutzers in dem vermittelnden Proxyserver 2A oder in der Vorrichtung PC 1A des Endnutzers sein oder vereinbart werden, wenn der Endnutzer durch diese hindurchklickt. Das Speichern oder Zwischenspeichern kann implementiert werden, wie oben ebenfalls erwähnt, oder nicht. Nach dem Ausführen der P3P-Vereinbarung kann, wenn die Echtheit des Schutzservers usw. erwiesen worden ist, die aktuelle Webseite nach dem vollständigen oder akzeptablen Profil des Benutzers abgefragt werden. Tatsächlich können auch persönliche Daten, wie etwa Name, Adresse, usw. gesendet werden, weil dem Schutzserver dahingehend vertraut werden kann, dass er die Daten richtig und in einer für den Endnutzer akzeptablen Weise verarbeitet.
Wie oben erwähnt stellt der Schutzserver 4A eine API bereit, die dem Dienstanbieter die Möglichkeit gibt, die Grunsätze bzw. Leitlinien der Einsatzorte und Seiten zu verändern, und wenn der Grad der Geheimhaltung angehoben wird, sollten die betroffenen Daten gelöscht werden. Zum Antworten auf Anfragen nach Zertifikaten und Signaturen antwortet der Schutzserver 4A zusätzlich auf Anfragen nach P3P Referenzen und Leitliniendateien und/oder nach Aussagen in natürlicher Sprache. Nach den Leitlinieneinstellungen kann der Dienstanbieter dann an den Schutzserver über die SQL API gemäß den Leitlinieneinstellungen Fragen richten, beispielsweise in Bezug auf benutzerspezifische Daten, wie etwa Name, Adresse, gekaufte Objekte usw., die dann erlangt werden können, weil der Schutzserver vertrauenswürdig ist. Es kann auch möglich sein, Profilinformation, insbesondere Implementierungen mit historischer Information, zu erlangen. Noch weiters kann der Dienstanbieter sogar statistische Daten erlangen, jedoch [nur] in einer solchen Weise, dass ein bestimmter Endnutzer nicht nachverfolgt werden kann.
In einer bestimmten Implementierung werden statistische Information und Profilinformation in einer geeigneten Weise pseudonymisiert und anonymisiert, beispielsweise können sie unter Benutzung einer Einweg-Hash-Funktion gespeichert und wieder erlangt werden, um die Geheimhaltung und Sicherheit auch in Fällen, wo tatsächlich in den Schutzserver eingebrochen worden ist, oder vergleichbaren, sicherzustellen.
Insbesondere fordert der Schutzserver das Zertifikat und die Signatur von dem Dienstanbieter 6A an. Der Schutzproxyserver 4A kann eine Anfrage (über HTTP) bezüglich der URL (Englisch: Uniform Resource Locator, Internetadresse) des Dienstanbieters pseudonymisieren. Für eine jeweilige neue URL, die angefordert worden ist, muss ein neues Pseudonym (beispielsweise ein Zähler) benutzt werden. Die Daten, die die Leitliniendatei zur Benutzung beansprucht, müssen zusammen mit der Anfrage gesendet werden. Insbesondere stellt der Schutzserver sicher, dass persönliche Daten nicht in einer solchen Weise weiter geleitet werden, dass die Profilinformation mit dem Benutzer in Verbindung gebracht werden kann. Wenn beispielsweise eine Seite wünscht, bestimmte Arten von benutzerspezifischen Daten zu speichern, dann wird die mit der Anfrage bereitgestellte benutzt, um die Information in dem Schutzserver zu speichern. Wenn jedoch die Information zurückzuholen ist, ist es wichtig, dass die Anfrage von einer Seite kommt, wo die Profilinformation nicht wieder erlangt worden ist, um die Sicherheit (den gewünschten Grad der Geheimhaltung nach den Leitlinien) sicherzustellen.
2B ist eine Darstellung vergleichbar derjenigen der 2A, stattdessen jedoch für eine Endnutzerstation mit einer WAP Vorrichtung 1B (WAP = Englisch: Wireless Application Protocol, drahtloses Anwendungsprotokoll) implementiert. Dann wird das WSP (Englisch: Wireless Session Protocol, drahtloses Sitzungsprotokoll) verwendet, sei es eine sichere Version oder nicht. Der vermittelnde Proxyserver 2B funktioniert vergleichbar zu dem oben beschriebenen, vermittelnden Proxyserver 2A. Es wird hier angenommen, dass die veröffentlichten Zertifikate in einem mit dem vermittelnden Proxyserver assoziierten Zertifikatverwaltungsmittel 3B verwaltet werden. Insbesondere befinden sich der vermittelnde Proxyserver und die Verwaltungsmittel für veröffentlichte Zertifikate in den Räumlichkeiten des Betreibers. Dies ist jedoch nicht notwendiger Weise der Fall, siehe 2A usw. Auch zwischen dem vermittelnden Proxyserver und dem Schutz-Proxyserver wird WSP (sicher oder nicht) benutzt. In anderen Aspekten ist die Funktion vergleichbar mit dem, was mit Bezugnahme auf 2A beschrieben ist.
3 ist ein Schaubild, das die Kommunikation zwischen dem Benutzer-Agenten (Endnutzerstation), dem vermittelnden Proxyserver, dem Schutzserver und der Anwendung gemäß einer Implementierung beschreibt. Es wird hier angenommen, dass von dem Benutzer-Agenten (für den es nicht erforderlich ist, dass er eine spezifische Kenntnis bzw. Intelligenz aufweist) an den vermittelnden Proxyserver, beispielsweise einen ISP (Englisch: Internet Service Provider, Internetdienstanbieter) eine Anfrage gesendet wird. Der vermittelnde Proxyserver sendet eine Anfrage nach einem Zertifikat an den Schutzserver, empfängt es und überprüft es, wie oben erläutert (in der Abbildung werden nicht alle Schritte explizit angedeutet). Die Anfrage wird dann an den Schutzserver weitergeleitet. Danach wird eine entschlüsselte Anfrage an die Anwendung gesendet, die mit einer Datei an den Schutzserver antwortet. Die Antwort wird zu dem vermittelnden Proxyserver weitergeleitet und von dort weiter zu dem Benutzer-Agenten. SQL Anfragen, beispielsweise aus der Anwendung an den Schutzserver und die Antworten darauf sind mit gestrichelten Linien angedeutet, weil beabsichtigt ist, anzudeuten, dass diese bereitgestellt werden können oder nicht; die Hauptsache ist dabei, dass eine derartige Funktionalität ermöglicht ist; und ob keine, eine oder mehrer derartige Anfragen tatsächlich gesendet werden, ist irrelevant, so lange nur die Möglichkeit dafür für die Anwendung oder für den Dienstanbieter offen ist.
4 veranschaulicht eine andere Ausführungsform, in der eine Anfrage von dem Benutzer-Agenten an den vermittelnden Proxyserver gesendet wird, der dann eine Anfrage nach eine Vereinbarungsreferenzdatei an den Schutzserver schickt. Letzterer gibt dann eine Vereinbarungsreferenzdatei an den vermittelnden Proxyserver zurück. Danach fordert der vermittelnde Proxyserver von dem Schutzserver eine Vereinbarungsleitlinie an, [woraufhin] der [Schutzserver] eine Vereinbarungsleitlinie, einen Schutzserver-Indikator und ein Zertifikat zurückgibt. Danach sendet der vermittelnde Proxyserver eine (mit dem Zertifikat) verschlüsselte Anfrage an den Schutzserver, der diese Anfrage (entschlüsselt) an die Anwendung weiterleitet. SQL Anfragen sind mittels gestrichelter Linien angedeutet, wie in der vorhergehenden Figur. Der Anwendungsserver stellt eine Antwort bereit mit der angeforderten Datei, die über den Schutzserver und den vermittelnden Proxyserver an den Benutzer-Agenten zurückgegeben wird. Die Anfrage nach der Vereinbarungsreferenzdatei und der Vereinbarungsleitlinie usw. können von dem vermittelnden Proxyserver gesendet werden, ohne dass der Benutzer dabei mit einbezogen wird, jedoch kann, wie durch die gestrichelten Linien angedeutet, der Benutzer-Agent auch mit einbezogen werden, d. h. dass er Intelligenz und Funktionalität aufweist, um derartige Anfragen zu bearbeiten. Alternativ wird dies für den Benutzer-Agenten transparent abgearbeitet, was für derartige Aktionen keine bestimmte Intelligenz oder Software umfasst. Wenn die Leitlinie auf ein niedrigeres Niveau verändert wird, sollten die Daten gelöscht werden.
5 ist ebenfalls ein Schaubild, das die Kommunikation zwischen dem Benutzer-Agenten, dem vermittelnden Proxyserver, dem Schutzserver und dem Anwendungsserver veranschaulicht. In Abhängigkeit davon, ob hier P3P implementiert ist oder nicht, oder ob die Überprüfung des Zertifikats implementiert ist oder nicht, sind ein oder mehrere der Schritte I, II, III, IV implementiert. In einer ersten Implementierung wird angenommen, dass P3P ebenso wie die Zertifikatüberprüfung implementiert ist und dass der Benutzer-Agent eine bestimmte Intelligenz umfasst. Somit wird eine Anfrage nach einer P3P Referenzdatei von dem Benutzer-Agenten an den vermittelnden Proxyserver geschickt, der die Anfrage an den Schutzserver weiterleitet. Der Schutzserver gibt dann eine P3P Referenzdatei zurück an den vermittelnden Proxyserver, der diese dann dem Benutzer-Agenten zurückgibt (Schritt I).
Danach sendet der Benutzer-Agent eine Anfrage nach einer P3P Leitlinie, die von dem vermittelnden Proxyserver weitergeleitet wird an den Schutzserver, der dann eine P3P Leitlinie und einen Schutzserverindikator, der den bestimmten Schutzserver anzeigt, sowie ein Zertifikat zurückgibt. Diese Antwort wird dann von dem vermittelnden Proxyserver an den Benutzer-Agenten weitergeleitet. Dies entspricht dem Schritt II. Dann wird eine Überprüfung dieses Zertifikats ausgeführt, weil in dem vermittelnden Server eine Anfrage an den Schutzserver mit diesem Ziel empfangen wird, Schritt III. Schließlich werden Benutzerdaten, die mit dem Zertifikat verschlüsselt sind, von dem Benutzer-Agenten über den vermittelnden Proxyserver an den Schutzserver gesendet, beispielsweise gemäß dem in der Patentveröffentlichung Nr. US 2003/0041100 beschriebenen Verfahren "Method for limiting conveyance information of user profile within mobile Internet transactions" (übersetzt: "Verfahren zum Beschränken von Weiterleitungsinformation von Benutzerprofilen in mobilen Internet-Transaktionen"), eingereicht am 23. August 2001 in den USA. Eine entschlüsselte Anfrage wird dann an die Anwendung geschickt, die mit einer Datei an den Schutzserver antwortet, und die Datei wird anschließend über den vermittelnden Proxyserver an den Benutzer-Agenten zurückgegeben, Schritt IV. SQL Anfragen (V), d. h. Anfragen von der Anwendung an den Schutzserver, können gesendet werden und es kann darauf gemäß den Leitlinieneinstellungen und Geheimhaltungseinstellungen, wie oben erläutert, geantwortet werden.
In einer anderen Implementierung wird angenommen, dass P3P nicht implementiert ist. Dann werden nur die Schritte III, IV benutzt. In noch einer anderen Implementierung wird angenommen, dass die Zertifikatsüberprüfung ausgelassen ist, wobei man sich dabei tatsächlich darauf verlässt, dass der Schutzserver authentisch ist. In diesem Fall werden nur die Schritte I, II und IV implementiert, und es wird immer noch angenommen, dass P3P implementiert ist. Schließlich kann der Benutzer-Agent keine Kenntnis von dem Schutzserver und P3P haben und so eine Anfrage an die Anwendung senden. Insbesondere ist dies eine Anfrage mit Benutzerdaten. (Einfache Anfragen von dem Benutzer-Agenten, d. h. ohne Benutzerdaten, sind in den 3, 4 veranschaulicht). Um in der Lage zu sein, Benutzerdaten zusammen mit der Anfrage zu schicken, bedingt dies einen "intelligenten" Benutzer-Agenten, wie oben beschrieben, der in der Lage ist, Daten in die Anfrage einzufügen. Die Dateninformation wird dann direkt in den Nachrichtenkopf (CC/PP, HTTP Nachrichtenkopf) eingefügt. Dies beruht tatsächlich darauf, dass der Benutzer-Agent die Leitlinien holt, vergleiche mit [dem Verfahren gemäß] der oben bezeichneten Patentanmeldung, dass XML benutzt wird, und dass über XML-Kennzeichen Information erlangt wird darüber, welche Daten erforderlich sind und die relevante Leitlinie. Der Benutzer-Agent liest dann die Leitlinie, erstellt, was benötigt wird, und sendet die relevanten Daten unmittelbar, was besonders vorteilhaft ist.
Die oben mit einem Verweis versehene US Patentanmeldung bezieht sich allgemein auf ein Verfahren zum Kontaktieren eines Quell-Servers von einem Benutzer, bei dem für den Benutzer ein minimales Benutzerprofil, das die vom Benutzer angewiesene CPI (Englisch: Capabilities and Preferences Information, Information über Fähigkeiten und Präferenzen) enthält, erzeugt wird. (CPI wird durch ein Profil dargestellt und bestimmt, inwieweit und in welchem Ausmaß Profilinformation an andere Webseiten zu kommunizieren ist). Dann wird unter Benutzung des minimalen Benutzerprofils eine Verbindung mit dem Quellserver errichtet. Es wird bestimmt, ob eine Geheimhaltungsleitlinie des Quellservers zumindest die Geheimhaltungspräferenzen des Benutzers erfüllt, und es wird ein zweites Profil (mindestens eines), das eine ausführlichere CPI enthält, dem Quellserver bereitgestellt, wenn die Geheimhaltungsleitlinie des Quell servers zumindest die Geheimhaltungspräferenzen des Benutzers erfüllt. Dieses Konzept kann in der Implementierung des vorliegenden erfinderischen Konzepts verwendet werden.
Es sei angemerkt, dass der Benutzer-Agent und der vermittelnde Proxyserver beide in der Umgebung des Betreibers sein können, d. h. eine kombinierte Einheit, jedoch ist dies nicht notwendigerweise der Fall.
6 veranschaulicht den Vorgang ab dem Punkt, wo eine entschlüsselte Anfrage von dem Schutzserver an die Anwendung gesendet wird. Die Anfrage ist insbesondere eine HTTP Anfrage, die mindestens HTTP Information, wie etwa eine IP Nummer usw., enthält. Wenn das in 5 beschriebene Konzept implementiert ist (Benutzerdaten im Nachrichtenkopf), dann werden auch diese Daten mit aufgenommen. Noch weiter sogar, wenn die Anfrage tatsächlich eine Antwort ist auf ein Formular, das die benötigte Information definiert, dann werden GET/POST Parameter mit aufgenommen (WSP oder HTTP GET, POST Anfragen).
Der Schutzserver mit seiner Logik ist dann verantwortlich für das Speichern von Daten gemäß der Vereinbarung, oder gemäß der Leitlinie in der Datenbank (den Datenbanken) innerhalb des Schutzservers oder assoziiert mit dem Schutzserver. Dies wird in einer anonymisierten und pseudonymisierten Weise ausgeführt. Die anonymisierte, pseudonymisierte HTTP Anfrage wird auch an die Anwendung weitergeleitet, wobei sie beispielsweise eine Sequenznummer oder irgendetwas enthält, das sie "identifizierbar" macht. SQL Anfragen nach Daten können dann aus der Anwendung an den Schutzserver (die Speichermittel) gesendet werden, und Antworten werden dann gemäß der Leitlinie bereitgestellt. Schließlich wird eine HTTP Antwort für den Schutzserver (Logikteil) bereitgestellt, der (das) diese dann über den vermittelnden Proxyserver an den Benutzer-Agenten weiterleitet.
7 ist ein sehr schematisches Ablaufdiagramm, das sich auf eine der in 5 offenbarten Implementierungen bezieht, nach der P3P, jedoch keine Zertifikatsüberprüfung implementiert ist. Es wird auch angenommen, dass der Benutzer-Agent eine bestimmte Intelligenz aufweist, dass der Benutzer-Agent die Leitlinie, wie etwa vermittels der XML Kennzeichnung, die die Leitlinie spezifiziert und anzeigt, welche Daten tatsächlich benötigt werden, eingeholt hat, so dass Benutzerdaten von dem Benutzer-Agenten (mit dem Zertifikat verschlüsselt) direkt gesendet werden können.
So wird eine Anfrage nach einer P3P Referenzdatei von dem Benutzer-Agenten über den vermittelnden Proxyserver an den Schutzserver gesendet, 100. Von dem Schutzserver wird dann die P3P Referenzdatei zurückgegeben, 101. Danach wird eine Anfrage nach einer P3P Leitlinie von dem Benutzer-Agenten an den Schutzserver gesendet, 102. Der Schutzserver gibt dann die P3P Leitlinie, eine Andeutung des Schutzservers und ein Zertifikat zurück an den Benutzer-Agenten, 103. Obwohl in dieser Implementierung keine Zertifikatsüberprüfung veranschaulicht ist, kann hier ein Schritt mit aufgenommen werden, nach dem der Benutzer-Agent einfordert, dass der vermittelnde Proxyserver eine Überprüfung des Zertifikats oder allgemeiner des Schutzservers bereitstellt, beispielsweise wie oben in dieser Druckschrift erläutert, und dann eine Antwort an den Benutzer-Agenten zurückgibt. Mit oder ohne Überprüfung des Zertifikats werden Benutzerdaten dann in dem vermittels des Zertifikats verschlüsselten Nachrichtenkopfs von dem Benutzer-Agenten an den Schutzserver gesendet, 104. Der Schutzserver (Logik) stellt dann ein geeignetes Speichern in den Schutzserver-Speichermitteln gemäß der Leitlinie bereit, anonymisiert und pseudonymisiert, 105. Eine anonymisierte und pseudonymisierte HTTP Anfrage wird dann auch an die Anwendung gesendet, 106. SQL Anforderungen können dann von der Anwendung an den Schutzserver oder an dessen Speichermittel gesendet werden, die dann gemäß der Leitlinie antworten, 107. Schließlich wird eine Antwort mit der Datei von der Anwendung über den Schutzserver usw. zu dem Benutzer-Agenten gesendet, 108.
Die Erfindung ist selbstverständlich nicht auf die explizit veranschaulichten Ausführungsformen beschränkt, sondern kann in einer Anzahl von Arten und Weisen innerhalb des Schutzumfangs der beigefügten Patentansprüche verändert werden.

Claims

Ein Kommunikationssystem zum Schutz von persönlichen Profildaten eines Endnutzers, welches System eine Anzahl von Endnutzerstationen (1; 1A; 1B) und eine Anzahl von Dienst-/Informations-/Inhalts-Anbietern (6; 6A; 6B) umfasst, dadurch gekennzeichnet, dass es folgendes umfasst: einen dazwischen geschalteten bzw. vermittelnden Proxi-Server (2; 2A; 2B), der ein erstes Kommunikationsprotokoll für Kommunikation mit einer Endbenutzerstation unterstützt und Mittel zum Bereitstellen von veröffentlichten Zertifikaten (3; 3A; 3B) umfasst, einen Schutzserver für persönliche Profildaten (4; 4A; 4B), der ein zweites Kommunikationsprotokoll zur Kommunikation mit dem dazwischen geschalteten Proxi-Server (2; 2A; 2B) und ein drittes Kommunikationsprotokoll zur Kommunikation mit einem Dienst-/Informations-/Inhalts-Anbieter (6; 6A; 6B) unterstützt, und eine Anwendungsprogrammschnittstelle (API, Englisch: Application Programming Interface), die Abfragen/-Interaktionen von einen Dienst-/Informations-/Inhalts-Anbieter erlaubt, wobei der Schutzserver (4; 4A; 4B) Speichermittel (5; 5A; 5B) mit einer Anzahl von Tabellen (5; 5A₁ , 5A₂ , 5A₃ ) oder separate Haltemittel zum Speichern von spezifischen Daten des Endnutzers und persönlichen Profildaten des Endnutzers umfasst, und dadurch dass der dazwischen geschaltete Proxi-Server (2; 2A₁ ; 2B₁ ) Mittel umfasst zum Überprüfen der Echtheit eines Zertifikats, das über das zweite Kommunikationsprotokoll von dem Schutzserver (4; 4A; 4B) für persönliche Profile gegen ein veröffentlichtes Zertifikat angefordert hat, und dadurch dass der Dienst-/Informations-/Inhalts-Server (6; 6A; 6B) Mittel umfasst zum Anfragen von persönlichen Profildaten über die API, dass der Schutzserver (4; 4A; 4B) Mittel umfasst zum Ausliefern von persönlichen Profildaten gemäß dem Grad des Datenschutzes des Endnutzers, und dadurch dass der Schutzserver (4; 4A; 4B) eine API umfasst, die eine Steuerung von Betriebs- und Seitengrundsätzen (Englisch: Site and Page Policies) durch den Dienst-Anbieter (6; 6A; 6B) ermöglicht.
Ein System nach Anspruch 1, dadurch gekennzeichnet, dass das erste Kommunikationsprotokoll ein sicheres Protokoll ist.
Ein System nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das erste Protokoll HTTP oder WSP/HTTPS ist.
Ein System nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass das zweite Kommunikationsprotokoll ein nicht-sicheres Protokoll ist.
Ein System nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass das zweite Protokoll ein sicheres Protokoll ist.
Ein System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Endnutzerstation (1; 1A; 1B) ein mobiles Gerät oder eine feste Station ist.
Ein System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der dazwischen geschaltete Proxy-Server (2; 2A; 2B) ein HTTP Proxy ist.
Ein System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der dazwischen geschalte te Proxy-Server (2B) Haltemittel (3B) zum Halten von veröffentlichten Zertifikaten umfasst.
Ein System nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass der dazwischen geschaltete Proxy-Server (2; 2A) dazu ausgebildet ist, in Kommunikation mit externen, veröffentlichte Zertifikate haltenden Haltemitteln (3A; 3B) zu sein.
Ein System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der dazwischengeschaltete Proxy-Server an der Endbenutzerstation angeordnet ist oder mit der Endbenutzerstation assoziiert ist.
Ein System nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass der dazwischen geschaltete Proxy-Server innerhalb eines Intranets oder in den Räumlichkeiten des Betreibers angeordnet ist.
Ein System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der dazwischen geschaltete Proxy-Server (2; 2A; 2B) eine Funktionalität umfasst zum Erstellen einer Sicherheitskommunikationsübereinkunft, die es ermöglicht, mit dem Schutzserver (4; 4A; 4B) eine automatisierte Verfahrensweise für Benutzer zum Steuern der Benutzung von persönlichen Daten bei besuchten Dienst-Anbietern zu implementieren.
Ein System nach Anspruch 12, dadurch gekennzeichnet, dass die Endnutzerstation dazu ausgebildet ist, die Präferenzen des Benutzers zu speichern.
Ein System nach Anspruch 12, dadurch gekennzeichnet, dass der dazwischen geschaltete Proxy-Server (2; 2A; 2B) dazu ausgebildet ist, auf den Grad des Datenschutzes bezogene Benutzerpräferenzen zu speichern.
Ein System nach Anspruch 13 oder 14, dadurch gekennzeichnet, dass separate Speichermittel mit schnellem Zugang bereitgestellt werden, die dazu ausgebildet sind, die auf den Grad des Datenschutzes bezogenen Benutzerpräferenzen nach der Vervollständigung der Sicherheitskommunikationsübereinkunft zu speichern.
Ein System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Schutzproxy-Server (4; 4A; 4B) dazu ausgebildet ist, Zertifikate auf Anfrage des dazwischen geschalteten Proxy-Servers (2; 2A, 2B) bereitzustellen.
Ein System nach Anspruch 16, dadurch gekennzeichnet, dass der Schutzproxy-Server (4A; 4B) Haltemittel zum Halten von Sicherheitsübereinkünften umfasst oder damit assoziiert ist.
Ein System nach einem der Ansprüche 1 bis 17, dadurch gekennzeichnet, dass es eine API umfasst, die Dienst-Anbieter-Anfragen an die Speichermittel (5; 5A; 5B) des Schutzservers (4; 4A; 4B) gemäß den Grundsatz-Einstellungen des Dienst-Anbieters (6; 6A; 6B) ermöglicht.
Ein System nach Anspruch 18, dadurch gekennzeichnet, dass die Speichermittel (5; 5A₁ , 5A₂ , 5A₃ ) des Schutzservers mindestens drei Tabellen umfassen, die jeweils Information über spezifische Daten von Endnutzern, Information über persönliche Profildaten und statistische Daten enthalten.
Ein System nach Anspruch 18 oder 19, dadurch gekennzeichent, dass die spezifischen Daten über Endnutzer und die persönlichen Profildaten von Endnutzern dazu ausgebildet sind, dem Dienst-Anbieter (6; 6A; 6B) be reitgestellt zu werden, ohne Zuordnung zwischen dem tatsächlichen Endnutzer und den persönlichen Profildaten des Endnutzers, so dass der Endnutzer nicht verfolgt werden kann.
Ein System nach Anspruch 20, dadurch gekennzeichnet, dass der Schutzproxy-Server (4; 4A, 4B) Mittel umfasst zum Pseudonymisieren von statistischer Information und Information über persönliche Profile durch Verwenden eines eindeutigen Pseudos für jede URL des Dienst-Anbieters, der angefordert wird.
Ein Verfahren zum Schutz von persönlichen Profildaten von Endnutzern in einem Kommunikationssystem mit einer Anzahl von Endnutzerstationen und einer Anzahl von Dienst-/Informations-/Inhaltsanbietern, dadurch gekennzeichnet, dass es die folgenden Schritte umfasst: – Registrieren eines Zertifikats für einen Schutzserver für persönliche Profile von Endnutzern bei einem vertrauenswürdigen Dritten, – Bereitstellen einer Anforderung für das Zertifikat an den Schutzserver über ein zweites Kommunikationsprotokoll von einem dazwischen geschalteten Proxy-Server in Kommunikation mit einer Endnutzerstation unter Benutzung eines ersten Kommunikationsprotokolls, – Bereitstellen einer Antwort von dem Schutzserver an den dazwischen geschalteten Server, – Überprüfen, in dem dazwischen geschalteten Proxy-Server, dass das Zertifikat echt ist, zu dem entsprechenden Schutzserver gehört und bei dem vertrauenswürdigen Dritten registriert ist, – nach der Überprüfung, dass das Schutzserver-Zertifikat echt ist, – Speichern von Daten in einer Anzahl von Tabellen in den Schutzserver, wobei sich die Tabellen auf spezifische Daten des Endnutzers und persönliche Profildaten des Endnutzers beziehen, – Ermöglichen, dass der Dienstanbieter, der den Schutzserver angerufen hat, Endnutzerdaten und persönliche Profildaten gemäß den Grundsatz-Einstellungen und dem Grad des Datenschutzes des Endnutzers über eine Anwendungsprogrammschnittstelle (Englisch: Application Programming Interface) und ein drittes Kommunikationsprotokoll abruft, – der Schutzserver einer API die Steuerung durch den Dienstanbieter von Betriebs- und Seitengrundsätzen (Englisch: Site and Page Policies) bereitstellt, wobei der Grad an Geheimhaltung berücksichtigt wird.
Das Verfahren nach Anspruch 22, dadurch gekennzeichnet, dass es ferner die folgenden Schritte umfasst: – Errichten einer Sicherheitsübereinkunft für persönliche Profildaten eines Endnutzers, die es ermöglicht, eine automatisierte Verfahrensweise für Nutzer zu implementieren, um die Benutzung von persönlichen Daten auf besuchten Dienstanbietern zwischen dem dazwischen geschalteten Proxy-Server und dem Schutzserver im Namen des Endnutzers und des Dienstanbieters zu steuern.
Das Verfahren nach Anspruch 23, dadurch gekennzeichnet, das die Übereinkunft eine P3P Übereinkunft umfasst.
Das Verfahren nach Anspruch 23, dadurch gekennzeichnet, dass die Übereinkunft eine Übereinkunft in natürlicher Sprache umfasst.
Das Verfahren nach einem der Ansprüche 22 bis 25, dadurch gekennzeichnet, dass das erste und zweite Kommunikationsprotokoll sicher sind.
Das Verfahren nach einem der Ansprüche 22 bis 26, dadurch gekennzeichnet, dass das erste und/oder zweite Kommunikationsprotokoll HTTP, WSP oder ein vergleich bares ist, unabhängig davon, ob es eine sichere Version ist oder nicht.
Das Verfahren nach einem der Ansprüche 23 bis 25, dadurch gekennzeichnet, dass die Grade der Geheimhaltung von Endnutzern in der Endnutzerstation oder in dem dazwischen geschalteten Proxy-Server gespeichert sind, und dadurch dass sie nach der Bestätigung der Übereinkunft separat gespeichert werden können.
Das Verfahren nach einem der Ansprüche 22 bis 28, dadurch gekennzeichnet, dass es die folgenden Schritte umfasst: – Bereitstellen einer API an den Schutzserver, – Benutzen der API für Anfragen an den Schutzserver aus dem Dienst-Anbieter – Bereitstellen von Antworten über den Eintritt des Kommunikationsprotokolls bei dem Dienstanbieter.
Das Verfahren nach Anspruch 29, dadurch gekennzeichnet, dass es den folgenden Schritt umfasst: – Pseudonymisieren von statistischen Daten und Profilinformation, so dass persönliche Daten von Endnutzern nicht mit tatsächlichen Endnutzer assoziiert werden können mit, oder bezogen werden können, auf.