Jusletter IT

Mithilfe von HTML5, CSS3 und Javascript ist es möglich, Apps zu erstellen, die per Browser über das World Wide Web aufgerufen werden können.¹ Derartige Web-Apps unterscheiden sich in Funktion und Aussehen kaum von einer «normalen» App.

MICRO-LAW² ist eine Web-App. Sie dient dazu, Studierende der Anfangssemester in spielerischer Weise mit dem Aufbau und der Komplexität juristischer Gutachten vertraut zu machen. Ausgehend von einem auszuwählenden Sachverhalt (Fall) sollen die Studierenden aus vorgegebenen Textblöcken ein in sich stimmiges (und richtiges) juristisches Gutachten zusammenstellen, welches anschließend durch die App ausgewertet wird. Falsche Antworten werden entsprechend markiert und den Studierenden werden Hinweise zur richtigen Lösung gegeben.

Im Folgenden werden die einzelnen Komponenten der Web-App MICRO-LAW vorgestellt und die Funktionsweise der automatisierten Auswertung und Aufbereitung der juristischen Gutachten erläutert. Anschließend werden Ideen skizziert, wie sich die mit der Web-App erprobten Techniken im Rahmen eines Information-Retrieval-Systems im Bereich des Verbraucherschutzes nutzbar machen lassen.

Die Funktionalität von MICRO-LAW resultiert im Wesentlichen aus einem Zusammenspiel von XML, HTML5 und Javascript. Um das Erscheinungsbild der App an die Anforderungen unterschiedlicher Endgeräte, d.h. Desktop-PCs, Tablets und Smartphones, anzupassen, wurde auf die Methode des sogenannten «responsive Webdesigns» zurückgegriffen, die mittels CSS3 realisiert wird.

Die Interaktion der Studierenden mit der App ist in erster Linie durch drei Handlungsalternativen gekennzeichnet: Sie sollen einen Fall laden, einen Fall lösen und einen gelösten Fall auswerten lassen können.

Mit Blick auf diese Anforderungen lässt sich die Systemarchitektur von MICRO-LAW beschreiben.

Abbildung 1: System-Architektur der Web-App MICRO-LAW

Über das Benutzer-Interface können die Studierenden die eben erwähnten Handlungen vornehmen. Um einen Fall zu laden, haben die Studierenden die Wahl, entweder den zu lösenden Fall aus einer Liste verfügbarer Fälle, die bei Bestehen einer Internetverbindung automatisch vom Server geladen wird, auszusuchen oder den zuletzt im Web-Storage abgelegten Fall aufzurufen. Die Fälle nebst Lösungen sind als XML-Dokumente auf einem Server gespeichert, der diese auf Abruf in das JSON-Format transferiert und an den Client sendet. Das so bezogene JSON-Dokument wird vom Client in den Web-Storage geschrieben und in ein Javascript-Objekt umgewandelt.

Das Lösen des Falls beginnt, indem den Studierenden der Sachverhalt präsentiert wird. Dieser wird, ebenso wie die auf den Sachverhalt folgenden Textbausteine aus dem Javascript-Objekt bezogen. Hat sich der Benutzer für einen (von mehreren zur Auswahl stehenden) Textbaustein entschieden, wird seine Wahl in dem Javascript-Objekt notiert. Anschließend werden ihm die nächsten Textbausteine angezeigt. Dies geschieht so lange, bis das Ende des Gutachtens erreicht ist.

Um den Fall auszuwerten, werden die vom Benutzer gewählten Textbausteine der Reihe nach auf ihre Richtigkeit hin überprüft. Da die Angabe darüber, ob ein Textbaustein richtig ist, ebenfalls im Javascript-Objekt hinterlegt ist, erfolgt auch diese Abfrage über das Objekt-Interface. Im Anschluss an die Auswertung wird dem Benutzer das von ihm zusammengestellte Gutachten im Zusammenhang angezeigt. Dabei werden richtige Textbausteine grün und falsche rot markiert sowie Rückmeldungen zu den Fehlern eingefügt, die wiederum aus dem Javascript-Objekt stammen.

Da das Javascript-Objekt aus dem XML-Dokument generiert wird, ist seine Struktur an dieses angelehnt. Die XML-Dokumente ihrerseits werden mit Hilfe der E-Learning-Software «moodle» erstellt. Dazu werden die einzelnen Aufgaben zunächst in «moodle» als Multiple-Choice-Quizes angelegt und anschließend als XML-Dokumente exportiert. Dies hat nicht nur den Vorteil, dass Fehler bei der Erstellung der XML-Dokumente vermieden werden, die bei einem manuellen Anlegen zu befürchten wären. Der Einsatz von «moodle» als XML-Generator ermöglicht es vor allem auch Juristen, die im Umgang mit XML nicht versiert sind, neue Fälle für die App zu erstellen.³ Die nachfolgende Abbildung zeigt beispielhaft die Struktur eines so erzeugten XML-Dokuments.

Abbildung 2: XML-Struktur

Der Einsatz von «moodle» als XML-Generator hat zur Konsequenz, dass das Objekt-Interface die «Grammatik» von Moodle-XML kennen muss, da diese bei der Umwandlung der XML-Dokumente in das JSON-Format erhalten bleibt. Wie bereits in Abschnitt 2.2.2 erläutert, erfolgt die Konvertierung der XML-Daten in das JSON-Format auf Seiten des Servers mittels PHP.⁴ Das in Abbildung 2 wiedergegebene Beispiel-Dokument würde nach einer Konvertierung in das JSON-Format wie folgt aussehen.

Abbildung SEQ Abbildung \* ARABIC 3: Daten im JSON-Format

Nach dem Empfang der Daten kann der Client aus diesem JSON-Dokument das in Abschnitt 2.2.4 erwähnte Javascript-Objekt erzeugen. Bezogen auf vorliegendes Beispiel wäre dies ein Objekt mit der Eigenschaft «question», dessen Wert ein indiziertes Array bildet, welches die einzelnen Textbausteine und die ergänzend hierzu benötigten Angaben beinhaltet.

Das Benutzer-Interface erzeugt die Bedienoberfläche von MICRO-LAW, die in zwei Bereiche aufgeteilt ist: den Hauptbereich zur Anzeige des Sachverhalts, zur Auswahl der Textblöcke und zur Vor/Zurück-Navigation, sowie die Seitenleiste mit Menüpunkten zum Verbindungsstatus, zum aktuell geladenen Fall, einer Liste online verfügbarer Fälle und zur Hilfe.

Die Auswahl der einzelnen Textblöcke geschieht mittels «Drag & Drop». Diese Funktionalität wird durch die Erweiterung «jQuery UI» der Javascript-Bibliothek «jQuery» bereitgestellt, die einen Satz an Werkzeugen zur Gestaltung von Bedienoberflächen bietet. Die «Drag & Drop»-Methode soll sicherstellen, dass die Textblöcke auch auf Tablets und Smartphones komfortabel ausgewählt werden können. Die Seitenleiste und der Hauptbereich sind bei entsprechend großen Bildschirmen nebeneinander angeordnet. Bei kleineren Bildschirmen rutscht die Seitenleiste nach unten, um mehr Platz für den Hauptbereich zu schaffen und eine hinreichend große Anzeige der Textblöcke zu gewährleisten. Realisiert wird dies mittels CSS3 über die Methode des sogenannten «responsive Webdesign». Hierbei werden zunächst Standardeigenschaften der einschlägigen Elemente definiert. Anschließend lassen sich über sogenannte «Media Queries» die konkreten Geräteeigenschaften des Clients wie beispielsweise die Größe des Browserfensters oder die Pixelauflösung abfragen und in Abhängigkeit dieser Vorgaben die zuvor definierten Standardeigenschaften «überschreiben». So ist die Breite des Hauptbereichs der Bedienoberfläche von MICRO-LAW standardmäßig auf 75% des verfügbaren Anzeigebereichs festgelegt, damit die Seitenleiste daneben platziert wird. Unterschreitet die horizontale Pixelanzahl des Endgeräts jedoch 1024 Punkte, wird die Breite des Hauptbereichs auf 100% hochgesetzt, was bewirkt, dass die Seitenleiste unter dem Hauptbereich angeordnet wird.

Das Server-Interface besteht aus zwei Teilkomponenten: eine in Javascript unter Zuhilfenahme der Javascript-Bibliothek «jQuery» geschriebene auf Seite des Clients und eine in PHP geschriebene auf Seite des Servers. Aufgabe der Client-Komponente ist im Wesentlichen, eine Verbindung zum Server aufzubauen, die Daten zum gewählten Fall im JSON-Format abzurufen und an das Web-Storage-Interface weiterzureichen. Die Server-Komponente kümmert sich in erster Linie darum, die als XML-Dateien vorliegenden Fälle zu laden, in das JSON-Format umzuwandeln und an den Client zu übergeben.

Um die App auch nutzen zu können, wenn keine Internetverbindung besteht, müssen die Daten des jeweiligen Falls clientseitig gespeichert und geladen werden können. Hierum kümmert sich das Web-Storage-Interface.⁵ Dieses schreibt das vom Server-Interface erlangte JSON-Dokument als String in den permanenten Speicher des Browsers, holt es von dort wieder zurück und wandelt es in ein Javascript-Objekt um, so dass es anschließend vom Objekt-Interface iteriert werden kann.

Aufgabe des Objekt-Interface ist es, Daten aus dem Javascript-Objekt zu holen bzw. in dieses zu schreiben. Darüber hinaus überprüft es das vom Benutzer zusammengestellte Gutachten auf seine Richtigkeit hin. Das Javascript-Objekt selbst beinhaltet ein mehrdimensionales Array, das aus einer geordneten Liste von Objekten besteht, die weitere Objekte und Arrays beinhalten.⁶ Über eine kombinierte Angabe von Index/Eigenschaft kann das Objekt-Interface auf jedes einzelne Element des Javascript-Objekts, d.h. den Sachverhalt, die einzelnen Textbausteine sowie die weiteren zur Lösung des Falls notwendigen Angaben, zugreifen und diese auslesen.

Die Auswertung des vom Benutzer zusammengestellten Gutachtens erfolgt, indem die vom Benutzer ausgewählten Textbausteine der Reihe nach mit jenen verglichen werden, denen innerhalb des Javascript-Objekts die Eigenschaft als richtig zugewiesen ist. Stimmen die Textbausteine überein, wird dem vom Benutzer ausgewählten Textbaustein ein Element mit der CSS-Eigenschaft «color: green» hinzugefügt. Stimmen Sie nicht über ein, wird der vom Benutzer ausgewählte Textbaustein um ein Element mit der CSS-Eigenschaft «color: red» ergänzt und mit dem jeweiligen Feedback versehen. Anschließend werden die so modifizierten Textbausteine an das Benutzer-Interface zur Ausgabe auf dem Bildschirm übergeben.

Bevor auf die Frage eingegangen wird, inwiefern sich die Systemarchitektur von MICRO-LAW für ein Information-Retrieval-System des Verbraucherschutzes nutzen lässt, sollen die Gründe dargelegt werden, warum die Erstellung eines solchen Systems zur Informationsrückgewinnung als notwendig erachtet wird.

Das Verbraucherrecht wird von unterschiedlichen Leitbildern des Verbrauchers geprägt. Eines davon ist das sogenannte «Informationsmodell», das den Verbraucher als aufzuklärenden «homo oeconomicus» sieht.⁷ Im Gegensatz zum «altliberalen» Modell, das noch davon ausgeht, dass der Markt selbst hinreichende Mechanismen zur Wahrung der Interessen des Verbrauchers bereithält, diesen also als vollinformiert betrachtet, sieht das «Informationsmodell» den Verbraucher als potenziell unterinformiert an und nur dann in der Lage, ökonomisch rational am Markt zu agieren, wenn er angemessen aufgeklärt wird.⁸

Auch die Gesetzgebung richtet sich regelmäßig am «Informationsmodell» aus, so zu sehen an der Vielzahl von Verbraucherschutzvorschriften, die in den vergangenen Jahren Informationspflichten für Unternehmer statuierten. Dahinter steht die Intention, das (anzunehmende) Informationsdefizit des Verbrauchers auszugleichen und ihn in die Lage zu versetzen, eine «informierte» Entscheidung zu treffen, sprich auf «Augenhöhe» mit dem Unternehmer zu kontrahieren. Dieser Ansatz hat durchaus seine Berechtigung; er ist jedoch nicht alleine zielführend. Insbesondere muss berücksichtigt werden, dass Informationsversorgung und Informationsaufnahme nicht zwangsläufig Hand in Hand gehen. Dies hat auch der (europäische) Gesetzgeber erkannt. Ausweislich Art. 5 Abs. 1 sowie Art. 6 Abs. 1 der Richtline 2011/83/EU des europäischen Parlaments und des Rats vom 25. Oktober 2011 über die Rechte der Verbraucher sind die vom Unternehmer mitzuteilenden Informationen in klarer und verständlicher Weise abzufassen. Dahinter steht der naheliegende Gedanke, Verbraucher nicht nur mit Informationen zu versorgen, sondern auf einen tatsächlichen Ausgleich der Informationsasymmetrie hinzuwirken.⁹ Hierfür spricht auch Erwägungsgrund 39 der Richtlinie, der speziell für Fernabsatzverträge, die über Webseiten abgeschlossen werden, erläutert, dass es wichtig sei sicherzustellen, dass Verbraucher in der Lage sind, die Hauptbestandteile des Vertrags zu verstehen. Daher verwundert es umso mehr, dass nach Erwägungsgrund 15 der Richtlinie die (weiteren?) sprachlichen Anforderungen für Verbraucherverträge nicht der (Voll-)Harmonisierung unterliegen. Nichtsdestotrotz zeigt das in der Richtlinie verankerte Transparenzgebot, dass sich der europäische Gesetzgeber der (problematischen) Diskrepanz von Informationsversorgung und Informationsaufnahme bewusst ist.

Verbraucher in klarer und verständlicher Weise mit Informationen zu versorgen, ist ein wichtiges Mittel, um bestehende Informationsasymmetrien zwischen Unternehmern und Verbrauchern zu beseitigen. Ob es ausreichend ist, darf jedoch bezweifelt werden. Es liegt auf der Hand, dass die Rechtsordnung niemals wird sicherstellen können, dass Verbraucher die ihnen zur Verfügung gestellten Informationen auch verstehen. Sie kann sich jedoch darum bemühen. Geradezu kontraproduktiv erscheint es daher, wenn durch die Etablierung immer neuer Informationspflichten die Aufnahmekapazität des Verbrauchers allmählich an seine Grenzen geführt oder sogar überschritten wird.¹⁰ Diesen Umstand haben auch bereits einige Unternehmer für sich entdeckt. In scheinbar überobligatorischer Pflichterfüllung werden alle erdenklichen Informationen, die dem Unternehmer über die für ihn arbeitenden Experten – sein Entwicklerteam, die Rechtsabteilung und/oder Vertragsanwälte – zur Verfügung stehen, in allgemeinen Geschäftsbedingungen gebündelt und dem Verbraucher vollkommen «transparent» in zig Seiten umfassenden (digitalen) Vertragswerken präsentiert. Eine derartige Informationsflut zu bewältigen, ist von einem Individuum alleine in kurzer Zeit kaum zu bewerkstelligen, unabhängig davon, ob es sich hierbei um einen Verbraucher handelt oder nicht. Kommt es dem Verbraucher noch dazu nur auf eine ganz spezielle Information, zum Beispiel die Vertragslaufzeit, an, steht erst recht zu befürchten, dass er sich nicht der Mühe aussetzt, den Paragraphendschungel zu durchforsten, sondern sich lieber auf das Wagnis einlässt, den Vertrag in Unkenntnis der begehrten Information abzuschließen.

Ein anderes Problem stellt sich auf der Ebene der Rechtsdurchsetzung, wenn der Verbraucher das Schuldverhältnis mit dem Unternehmer eingegangen ist. Selbst wenn der Verbraucher die ihm vorvertraglich zur Verfügung gestellten Informationen vollständig zur Kenntnis genommen hat, bedeutet das noch lange nicht, dass damit die Informationsasymmetrie zwischen Unternehmer und Verbraucher beseitigt wäre. Wie die Erfahrung mit den sogenannten Kostenfallen im Internet¹¹ gezeigt hat, können gerade auch Informationsdefizite des Verbrauchers in Bezug auf die rechtliche Durchsetzbarkeit von Forderungen dessen Position erheblich schwächen. Zwar gibt es mit der Verbandsklage und der wettbewerbsrechtlichen Abmahnung Instrumente, mit denen Unternehmer von der Verwendung unwirksamer Vertragsklauseln abgehalten werden können. Wie die Erfahrung ebenfalls gezeigt hat, können diese Instrumente jedoch keine Garantie dafür bieten, dass Verbraucher im Einzelfall nicht doch mit unwirksamen Vertragsklauseln konfrontiert werden. Da darüber hinaus kaum erwartet werden kann, dass der Unternehmer selbst den Verbraucher von der Unwirksamkeit seiner Vertragsklauseln in Kenntnis setzt, bleibt letztlich nur, den Verbraucher in die Lage zu versetzen, die Rechtmäßigkeit der vom Unternehmer erhobenen Forderungen zu bewerten.

Den soeben skizzierten Problemkonstellationen ist gemein, dass ihnen weniger eine Informations- als vielmehr eine Kompetenzasymmetrie zugrundeliegt, die dadurch gekennzeichnet ist, dass der Verbraucher die ihm zur Verfügung stehenden Informationen in Bezug auf das Vertragsverhältnis nicht hinreichend bewerten kann. Daher liegt der Gedanke nahe, dem Verbraucher ein System an die Hand zu geben, mit dem er die für ihn relevanten Erkenntnisse aus den vorhandenen Informationen gewinnen kann.

Wie bei MICRO-LAW könnte auch ein solches System auf XML-Dokumenten basieren, in denen sämtliche relevanten Informationen erfasst sind.

Um der Problematik undurchsichtiger Verträge Herr zu werden, könnte man beispielsweise die Web-App MICRO-LAW so modifizieren, dass sie einen mittels des OASIS LegalXML eContracts-Standards¹² ausgezeichneten Vertragstext analysiert und den Bedürfnissen des Verbrauchers entsprechend (visuell) aufbereitet. Dem Verbraucher könnte dann z.B. die Wahl eröffnet werden, ob er sich nur Überschriften, Kurzzusammenfassungen oder den vollständigen Vertragstext einzelner Klauseln anzeigen lässt. Damit könnten sich Verbraucher in kurzer Zeit einen Überblick über die wesentlichen Vertragsklauseln verschaffen und die für sie notwendigen Informationen identifizieren. Die Option des OASIS LegalXML eContracts-Standards, Zusammenfassungen zu Klauseln in den Vertragstext einzufügen, ermöglicht es Unternehmern ferner, die Gründe für die jeweiligen Klauseln zu erläutern. Für Unternehmer hätte dies den Vorteil, mit ihren allgemeinen Geschäftsbedingungen auf breitere Akzeptanz bei Verbrauchern zu stoßen. Um den Anreiz für die Erstellung von allgemeinen Geschäftsbedingungen im LegalXML eContracts-Format zu erhöhen, könnte das Information-Retrieval-System ferner um eine Zertifizierungskomponente erweitert werden. Unternehmern, die ihre allgemeinen Geschäftsbedingungen im LegalXML eContracts-Format bereithalten, könnte dies in einem (kostenlosen) Zertifikat bescheinigt werden. In einem erweiterten Zertifikat könnte darüber hinaus bestätigt werden, ob der Unternehmer (nur) geprüfte Standardklauseln verwendet, in denen die Verbraucherinteressen hinreichend berücksichtigt werden.¹³

Da, wie in Abschnitt 3.1 bereits erwähnt wurde, Unternehmer kaum ein Interesse daran haben werden, Verbrauchern Informationen darüber zu liefern, inwieweit die von ihnen verwendeten Klauseln wirksam sind, müsste das Information-Retrieval-System diese Informationen eigenständig generieren können. Ein Ansatz, um dies zu verwirklichen, wäre, eine Datenbank aufzubauen, in der Klauseln, die von der Rechtsprechung als unwirksam erachtet wurden, gespeichert sind. Vergleichbar mit Anti-Viren-Programmen, die schadhafte Programmteile über sogenannte Virensignaturen erkennen, könnten mithilfe von regulären Ausdrücken entsprechende «Klauselsignaturen» erstellt werden, anhand derer unwirksame Vertragsbedingungen auch dann in Vertragstexten identifiziert werden können, wenn diese von der Standardformulierung abweichen oder Rechtschreib- und/oder Interpunktionsfehler enthalten. Verbraucher, die einen Vertrag analysieren lassen wollten, müssten diesen nur hochladen und würden anschließend nach dem Prinzip von MICRO-LAW einen farblich markierten Text zurückerhalten, in dem wirksame Klauseln grün, strittige gelb und unwirksame rot markiert wären. Idealerweise würden die Klauseln zudem um Rückmeldungen ergänzt, denen die Gründe für ihre jeweilige Einstufung zu entnehmen wären.¹⁴

 

---

 

Gregor Völtz, Wissenschaftlicher Mitarbeiter, Universität Kassel, Institut für Wirtschaftsrecht.

 

---