-
GEBIET DER ERFINDUNG
-
Die vorliegende Erfindung betrifft
einen netzwerkbasierten Datenverarbeitungsansatz. Genauer gesagt
betrifft die Erfindung die Steuerung und Konfiguration von Netzwerkkomponenten,
welche zum Erzeugen und Verarbeiten angesammelter Daten zusammenwirken.
-
HINTERGRUND
DER ERFINDUNG
-
Moderne Kommunikationsnetzwerke wie
das öffentliche
Internet, nicht öffentliche
Intranets oder Kombinationen davon haben den Austausch von Informationen
sowohl über
kürzere
als auch über
weitere Entfernungen sehr erleichtert. Der erleichterte Informationsaustausch
erfordert jedoch ein verbessertes Informationsmanagement, um Probleme
wie fehlende Zugänglichkeit
von Informationen, nicht optimale Geschwindigkeit der Informationsgewinnung, unnötige Verdopplung
von Prozessen und Informationen usw. bewältigen zu können. Es ist offensichtlich,
dass infolge der ständig
ansteigenden Menge der zu verwaltenden Informationen die Aufgabe
des Informationsmanagements immer schwieriger wird.
-
Zur Erleichterung der Aufgabe des
Informationsmanagements wurden zahlreiche Standardplattformen entwickelt.
Lotus Domino R5, vertrieben durch Lotus/IBM Inc., kann als Beispiel
für eine
solche Standardplattform angeführt
werden. Trotz der Verfügbarkeit
solcher Standardplattformen erfordert das Vorhandensein individueller
Bedürfnisse
komplexe Überlegungen
z.B. hinsichtlich der Netzwerktechnologien und -architekturen, hinsichtlich
der Programmierung und Verbindung von Netzwerkkomponenten und hinsichtlich
der Verteilung spezieller Verarbeitungsaufgaben auf die einzelnen
Netzwerkkomponenten.
-
Die von einzelnen Netzwerkkomponenten
zu verarbeitenden Informationen können sich auf verschiedene
Aspekte beziehen, und üblicherweise
sind die oben genannten Überlegungen
eines Netzwerktechnologen unabhängig
vom speziellen Wesen der verarbeiteten Informationen. Dennoch existieren
Situationen, in denen das Wesen der verarbeiteten Information auf
technische Aspekte des Kommunikationsnetzwerkes und seiner Komponenten
Einfluss nimmt. In solch einem Fall ist es unentbehrlich, dass die
technische Umgebung einschließlich
der Netzwerkarchitektur, Benutzeroberflächen usw. an den speziellen
Informationstyp angepasst ist, um eine geeignete, effiziente und
sichere Arbeitsweise des Kommunikationsnetzwerkes sicherzustellen.
In diesem Zusammenhang können
Informationen angeführt
werden, die sich auf mit verschiedenen Risiken verbundene Aufgaben,
Prozesse oder Ereignisse beziehen.
-
Es besteht das Bedürfnis nach
einer technischen Umgebung, die ein verbessertes Informationsmanagement
erlaubt. Genauer gesagt besteht ein Bedürfnis nach entsprechend konfigurierten
Netzwerkkomponenten und einem Steuerverfahren für solche Netzwerkkomponenten,
die eine schnelle, effiziente und sichere Verarbeitung von Informationen erlauben,
die auf mit verschiedenen Risiken behaftete Aufgaben, Prozesse und
Ereignisse bezogen sind.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Entsprechend einem Serveraspekt der
Erfindung wird dieses Bedürfnis
durch eine Netzwerkkomponente befriedigt, die als Server mindestens
eine erste Gruppe von Netzwerkkomponenten bedient und eine Host-Einheit,
eine Datenbank und einen Berichterzeugungsprozessor beinhaltet.
Die Host-Einheit ist als Host für
eine erste Gruppe von Netzwerkkomponenten konfiguriert, um mindestens
einen ersten Programmcodeteil zur Erzeugung einer oder mehrerer
graphischer Benutzeroberflächen
(GUIs) bereitzustellen, wobei eine erste GUI mindestens ein erstes
Steuerelement für
die Erzeugung oder die Aktualisierung elektronischer Dossiers besitzt,
wobei das erste Steuerelement aktiviert werden kann, um ein erstes
Steuersignal zu erzeugen, und einen zweiten, auf die Erzeugung des
ersten Steuersignals reagierenden Programmcodeteil, um eine Aufforderung zur
Eingabe allgemeiner Daten für
eine bestimmte Angelegenheit (z.B. eine bestimmte Aufgabe, einen bestimmten
Prozess oder ein bestimmtes Ereignis) zu erzeugen, die in ein elektronisches
Dossiers einer bestimmten Angelegenheit einbezogen werden, und einen
dritten, auf die Erzeugung des ersten oder eines zweiten Steuersignals
reagierenden Programmcodeteil, um eine Aufforderung zur Eingabe
standardisierter risikobezogener Daten für die bestimmte Angelegenheit
zu erzeugen, die in das elektronische Dossiers der bestimmten Angelegenheit
einbezogen werden. Die Datenbank der Netzwerkkomponente ist für die Speicherung
einer Vielzahl elektronischer Dossiers für die erste Gruppe von Netzwerkkomponenten
konfiguriert, wobei sich jedes elektronische Dossier auf eine bestimmte
Angelegenheit bezieht und die allgemeinen Daten für diese
bestimme Angelegenheit sowie die standardisierten risikobezogenen Daten,
die zu der bestimmten Angelegenheit gehören, einschließt. Der
Berichterzeugungsprozessor der Netzwerkkomponente hat Zugriff auf
die Datenbank und ist zur Erzeugung eines elektronischen Risikoberichts
durch automatisches Verarbeiten der standardisierten risikobezogenen
Daten, die in der Vielzahl der in der Datenbank gespeicherten elektronischen
Dossiers enthalten sind, konfiguriert.
-
Die Erfindung erlaubt ein automatisiertes verteiltes
Arbeitsfluss-Management in Bezug auf das Erzeugen, Berichten und
Analysieren risikobezogener Daten. Infolge des standardisierten
Formats der risikobezogenen Daten, welches durch Benutzung spezieller
GUIs erzwungen werden kann, wird der Arbeitsfluss beschleunigt.
Außerdem
wird die Zugänglichkeit
risikobezogener Daten verbessert und die Wahrscheinlichkeit einer
irrtümlichen
Dateneingabe vermindert.
-
Die Host-Einheit, die Datenbank und
der Berichterzeugungsprozessor der Netzwerkkomponente können zu
einer ersten Server-Einheit gehören.
Zusätzlich
zur ersten Server-Einheit kann die Netzwerkkomponente eine oder
mehrere weitere Server-Einheiten
mit ähnlichem
Aufbau wie die erste Server-Einheit umfassen. Mit anderen Worten,
die eine oder mehrere weiteren Server-Einheiten können jede eine
Host-Einheit, eine
Datenbank und einen Berichterzeugungsprozessor wie zuvor erwähnt umfassen.
-
Vorzugsweise bedient jede Server-Einheit eine
gesonderte Gruppe von Netzwerkkomponenten. Zum Beispiel kann die
erste Server-Einheit der Netzwerkkomponente die erste Gruppe von
Netzwerkkomponenten über
ein erstes Netzwerk bedienen und eine zweite Server-Einheit der
Netzwerkkomponente eine zweite Gruppe von Netzwerkkomponenten über ein
zweites Netzwerk, das zum ersten unterschiedlich ist. Gemäß einem
weiteren Szenario wird eine Gruppe von Netzwerkkomponenten über ein und
dasselbe Netzwerk von zwei oder mehr Server-Einheiten bedient.
-
Wenn die Netzwerkkomponente zwei
oder mehr Server-Einheiten umfasst, können sich die Server-Einheiten
geographisch voneinander entfernt befinden. In solch einem Fall
stellt die Netzwerkkomponente, welche die geographisch verstreuten
Server-Einheiten enthält,
ein verteiltes System dar. Vorzugsweise ist die erste Server-Einheit geographisch mit
der einen oder den mehreren weiteren Server-Einheiten der Netzwerkkomponente
zusammen untergebracht. In einem solchen Fall ist die Netzwerkkomponente
physikalisch an ein und demselben Ort untergebracht, aber in zwei
oder mehr separate Server-Einheiten aufgeteilt. Eine Kombination
dieser Varianten ist möglich.
Gemäß einer
solchen Kombination kann die Netzwerkkomponente zwei oder mehr gemeinsam
untergebrachte Server-Einheiten und eine oder mehr entfernt untergebrachte
Server-Einheiten enthalten.
-
Gemäß einer bevorzugten Implementierung der
Erfindung ist mindestens ein Kommunikationskanal zwischen den einzelnen
Server-Einheiten der Netzwerkkomponente vorgesehen. Der Kommunikationskanal
zwischen zwei Server-Einheiten kann als Replikationsverbindung zwischen
den einzelnen Datenbanken der Server-Einheiten konfiguriert sein.
Die Replikationsverbindung kann zum Replizieren von Daten, die in
den einzelnen Datenbanken gespeichert sind, gemäß einer speziellen Replikationsstrategie
verwendet werden. Die Replikationsstrategie kann selektiv sein,
so dass nur spezielle Daten repliziert werden.
-
Es kann eine Einweg-Replikationsstragie
implementiert werden. Gemäß der Einweg-Replikationsstrategie
erfolgt die Replizierung nur in eine Richtung. In dem Fall, dass
eine erste Server-Einheit eine erste Datenbank und eine zweite Server-Einheit
eine zweite Datenbank beinhaltet, werden die in der zweiten Datenbank
gespeicherten elektronischen Dossiers z.B. in die erste Datenbank
repliziert, während die
in der ersten Datenbank gespeicherten elektronischen Dossiers nicht
in die zweite Datenbank repliziert werden. Solch eine Replikationsstrategie
ist vom Sicherheitsstandpunkt aus besonders vorteilhaft, weil sie
auf sicherere Weise verhindert, dass eine von der zweiten Server-Einheit
bediente Netzwerkkomponente Zugriff auf die in der ersten Datenbank
gespeicherten elektronischen Dossiers hat. Das Sicherheitsniveau
kann durch physikalisches Trennen der verschiedenen Server-Einheiten
weiter erhöht
werden. Im Prinzip können
die Server-Einheiten jedoch auch als Softwarekomponenten konfiguriert
werden, die nur logisch getrennt sind.
-
Die eine oder mehreren Server-Einheiten können als
Hypertext-Transfer-Protokoll (HTTP)-Server konfiguriert werden.
Ebenso können
alternative Übertragungsprotokolle
verwendet werden. Der Gebrauch von HTTP hat den Vorteil, dass die
von einem oder mehreren HTTP-Servern bedienten Netzwerkkomponenten
nur einen konventionellen Browser für die Interpretation der Programmcodeteile
benötigen, die
sie von dem einen oder den mehreren HTTP-Servern erhalten. Die von
den als Host fungierenden NTTP-Servern bereitgestellten Programmcodeteile können in
der Hypertext-Mark-Up-Language (HTML) geschrieben sein.
-
Gemäß dem oben beschriebenen Server-Aspekt
der Erfindung stellt eine Netzwerkkomponente, die eine oder mehrere
Server-Einheiten umfasst, als Host Programmcodeteile für eine oder
mehrere Gruppen von Netrwerkkomponenten, welche zur Ausführung der
Programmcodeteile konfiguriert sind, bereit. Gemäß einem komplementären Aspekt
bezieht sich die Erfindung auf Netzwerkkomponenten, die die Programmcodeteile
unabhängig
von der Tatsache ausführen,
ob die ausgeführten
Programmcodeteile über
ein Kommunikationsnetzwerk empfangen wurden oder nicht.
-
Die Erfindung bezieht sich somit
auch auf eine Netzwerkkomponente mit einem Datenspeicher, in diesem
Datenspeicher gespeicherte Programmcodeteile, eine Netzwerkschnittstelle
und einen Berichterzeugungsprozessor oder Zugriff auf einen solchen Prozessor über die
Netzwerkschnittstelle. Die in dem Datenspeicher gespeicherten Programmcodeteile beinhalten
mindestens einen ersten Programmcodeteil zur Erzeugung einer oder
mehrerer GUIs, wobei eine erste GUI mindestens ein erstes Steuerelement zur
Erzeugung oder Aktualisierung elektronischer Dossiers beinhaltet,
wobei das erste Steuerelement aktiviert werden kann, um ein erstes
Steuersignal zu generieren, und einen zweiten Programmcodeteil, der
auf die Generierung des ersten Steuersignals reagiert, um eine Aufforderung
zur Eingabe allgemeiner Daten für
eine bestimmte Angelegenheit zu erzeugen, die in ein elektronisches
Dossier der bestimmten Angelegenheit einbezogen werden, und einen
dritten Programmcodeteil, der auf die Generierung des ersten oder
eines zweiten Steuersignals reagiert, um eine Aufforderung zur Eingabe
standardisierter risikobezogener Daten für die bestimmte Angelegenheit
zu erzeugen, die in das elektronische Dossier der bestimmten Angelegenheit
einbezogen werden. Elektronische Dossiers, die unter Nutzung der
Programmcodeteile erzeugt wurden, werden über eine Netzwerkschnittstelle
zu einer zentralen Datenbank des Netzwerksystems übertragen.
In dieser zentralen Datenbank werden auch elektronische Dossiers
gespeichert, die von anderen Netzwerkkomponenten erzeugt wurden.
Die Verwendung einer zentralen Datenbank erlaubt mittels des Berichterzeugungsprozessors
die zentrale Verarbeitung der in den elektronischen Dossiers enthaltenen
standardisierten risikobezogener Daten.
-
Gemäß einer ersten Variante der
Erfindung gehört
der Berichterzeugungsprozessor zu derjenigen Netzwerkkomponente,
welche die in ihrem Datenspeicher gespeicherten Programmcodeteile
ausführt.
Gemäß einer
weiteren Variante ist der Berichterzeugungsprozessor geographisch
von der Netzwerkkomponente getrennt, die die Programmcodeteile ausführt. In
diesem Fall kann die Netzwerkschnittstelle derjenigen Netzwerkkomponente,
welche die Programmcodeteile ausführt, so konfiguriert sein,
dass eine Kommunikation mit dem entfernten Berichterzeugungsprozessor
möglich
ist.
-
Im Folgenden werden verschiedene
Aspekte bezüglich
einer die Programmcodeteile als Host bereitstellenden Netzwerkkomponente
beschrieben sowie bezüglich
einer Netzwerkkomponente, welche hinsichtlich der Ausführung extern
von einem Host bereitgestellter oder intern gespeicherter Programmcodeteile
konfiguriert ist.
-
Wie aus dem Vorstehenden deutlich
wurde, wird jedes Mal, wenn ein neues elektronisches Dossier für eine spezielle
Aufgabe, einen speziellen Prozess oder ein spezielles Ereignis erzeugt
oder aktualisiert wird, nicht nur die Eingabe von allgemeinen, die
spezielle Aufgabe, den speziellen Prozess oder das spezielles Ereignis
kennzeichnenden Daten angefordert, sondern zusätzlich die Eingabe standardisierter
risikobezogener Daten für
die spezielle Aufgabe, den speziellen Prozess oder das spezielle
Ereignis. Mit anderen Worten werden die risikobezogenen Daten in
Verbindung mit der Erzeugung oder Aktualisierung elektronischer
Dossiers angefordert und eingegeben. Da die elektronischen Dossiers
zentral gespeichert werden können
und die in den elektronischen Dossiers enthaltenen risikobezogenen
Daten in einer standardisierten Form eingegeben und gespeichert
werden, können
die risikobezogenen Daten der Vielzahl elektronischer Dossiers während der
Erzeugung eines elektronischen Risikoberichts effizient verarbeitet
werden.
-
Die Ausführung eines speziellen Programmcodeteils
führt zur
Erzeugung einer Aufforderung zur Eingabe standardisierter risikobezogener
Daten. Vorzugsweise ist die Aufforderung zur Eingabe risikobezogener
Daten so konfiguriert, dass nur standardisierte risikobezogene Daten
angenommen werden, z.B. dass der Benutzer automatisch gezwungen
wird, unter vordefinierten risikobezogenen Daten eine Auswahl zu
treffen.
-
Die Erzeugung der Aufforderung zur
Eingabe standardisierter risikobezogener Daten kann die Erzeugung
eines z.B. graphischen Menüs
für die
Auswahl vordefinierter Risikoklassifikationen beinhalten. Ferner
können
Unterklassifikationen (z.B. gering/mittel/hoch) zur weiteren Charakterisierung
einer speziellen Risikoklassifikation benutzt werden. Zusätzlich oder
alternativ kann die Aufforderung zur Eingabe standardisierter risikobezogener
Daten die Erzeugung eines Datenfeldes zur Eingabe risikobezogener Standardwerte
wie die mit einem speziellen Risiko verbundenen erwarteten Gesamtkosten,
erwartete, mit der Rechtsdurchsetzung in Zusammenhang stehende Gebühren usw.
beinhalten.
-
Wie anfangs erläutert, reagiert der dritte
Programmcodeteil zur Erzeugung der Aufforderung zur Eingabe standardisierter
risikobezogener Daten auf das durch das erste Steuerelement der
ersten GUI erzeugte erste Steuersignal oder ein zweites Steuersignal.
Das zweite Steuersignal kann durch die Aktivierung eines zweiten
Steuerelements erzeugt werden, welches Teil der ersten GUI oder
einer separaten zweiten GUI ist.
-
Der erste oder ein vierter Programmcodeteil kann
zum Erzeugen einer dritten GUI mit einem dritten Steuerelement für das Auslösen der
Erzeugung des elektronischen Risikoberichts programmiert sein. Das
dritte Steuerelement kann für
die Aktivierung der Erzeugung eines dritten Steuersignals ausgelegt sein,
das den Berichterzeugungsprozessor veranlasst, den elektronischen
Risikobericht zu erzeugen. Vorzugsweise wird der elektronische Risikobericht gemäß einem
speziellen Berichtsprofil erzeugt.
-
Ein Berichtsprofil kann entweder
vordefiniert und abgespeichert oder von einer als Host fungierenden
Netzwerkkomponente bereitgestellt sein oder individuell erzeugt
werden. In letzterem Fall kann der erste oder ein fünfter Programmcodeteil
zum Erzeugen einer vierten GUI mit einem vierten Steuerelement zum
Auslösen
der Definition eines Berichtsformats programmiert sein und für die Aktivierung
der Erzeugung eines vierten Steuersignals ausgelegt sein. Ein sechster,
auf die Erzeugung des vierten Steuersignals reagierender Programmcodeteil
kann bereitgestellt werden, der eine Aufforderung zur Eingabe von
Berichtsformatdaten erzeugt, die von dem Berichterzeugungsprozessor
verarbeitet werden sollen, wenn der elektronische Risikobericht
erzeugt wird. Die Möglichkeit
des sich zu Nutze machens von benutzerdefinierten Berichtsprofilen
erlaubt die Erzeugung beliebiger elektronischer Risikoberichte auf der
Grundlage der in der Vielzahl elektronischer Dossiers enthaltenen
risikobezogenen Daten.
-
In Abhängigkeit von dem speziellen
Berichtsprofil können
verschiedene Typen von elektronischen Risikoberichten elektronisch
erzeugt werden. Die Erzeugung eines elektronischen Risikoberichts
kann z.B. das Ansammeln der in der Vielzahl elektronischer Dossiers
enthaltenen standardisierten risikobezogenen Daten umfassen. Ein
solches Ansammeln kann auf verschiedene Arten durchgeführt werden.
Gemäß einer
ersten Option werden die in den zugänglichen elektronischen Dossiers
enthaltenen spezifischen risikobezogenen Werte einfach zusammengezählt. Gemäß einer
weiteren Option werden alle risikobezogenen Daten, die mit spezifischen allgemeinen
Daten verknüpft
sind, angesammelt. Somit kann eine Verknüpfung zwischen spezifischen
allgemeinen Daten und entsprechenden risikobezogenen Daten errichtet
werden.
-
Ein siebter Programmcodeteil kann
zur Erzeugung einer Aufforderung zur Eingabe von haftungsbezogenen
Daten bereitgestellt werden, um sie zusätzlich in das elektronische
Dossier einer bestimmten Angelegenheit mit einzubeziehen. Haftungsbezogene
Daten stellen Informationen dar, die an eine Versicherung, die möglicherweise
das mit der bestimmten Angelegenheit verbundene Risiko abdeckt,
berichtet werden. Die haftungsbezogenen Daten können zumindest in Teilen mit
den risikobezogenen Daten identisch sein.
-
Der Berichterzeugungsprozessor kann
zum Erzeugen eines elektronischen Haftungsberichts in Form von z.B.
einer elektronischen Versicherungsmitteilung durch automatisierte
Verarbeitung der in der Vielzahl elektronischer Dossiers enthaltenen
haftungsbezogenen Daten konfiguriert werden. Vorzugsweise ist der
Berichterzeugungsprozessor so konfiguriert, dass sichergestellt
ist, dass der elektronische Haftungsbericht innerhalb eines vorbestimmten
Zeitraumes nach Erzeugung des elektronischen Dossiers für eine bestimmte
Angelegenheit oder nach dem Datum des Vorkommnisses der bestimmten
Angelegenheit (wie es z.B. in den allgemeinen Daten für die bestimmte
Angelegenheit angegeben ist) erzeugt wird.
-
Der siebte Programmcodeteil zur Erzeugung der
Aufforderung zur Eingabe von haftungsbezogenen Daten kann auf die
Erzeugung von z.B. des ersten oder eines fünften Steuersignals reagieren.
Das fünfte
Steuersignal kann durch die Aktivierung eines im ersten, im zweiten
oder einem sechsten GUI enthaltenen fünften Steuerelements erzeugt
werden.
-
Die einzelnen Steuerelemente können ausgelegt
sein, um mittels eines Eingabegerätes wie einer Tastatur, einer
Maus oder einem anderen Zeigeinstrument usw. aktiviert zu werden.
Zum Beispiel können
die einzelnen Steuerelemente von graphischen Darstellungen wie Knöpfen (Buttons)
oder als Links gebildet werden, die in einer entsprechenden GUI
enthalten sind. Vorzugsweise sind die einzelnen GUIs ausgelegt,
um auf einem Anzeigegerät
der entsprechenden Netzwerkkomponente erzeugt zu werden.
-
Die Erfindung kann als Steuerverfahren
für eine
oder mehrere Netzwerkkomponenten implementiert werden. Das Verfahren
umfasst das Speichern einer Vielzahl von Programmcodeteilen, einschließlich mindestens
des ersten bis dritten Programmcodeteils, die für die Erstellung oder die Aktualisierung
elektronischer Dossiers erforderlich sind. Das Verfahren umfasst
weiterhin das Speichern einer Vielzahl elektronischer Dossiers und,
als Reaktion auf den Empfang eines Steuersignals, das Zugreifen auf die
gespeicherten Dossiers, um durch automatisiertes Verarbeiten der
standardisierten risikobezogenen Daten, die in den elektronischen
Dossiers enthaltenen sind, einen elektronischen Risikobericht zu erstellen.
Die Verarbeitung der standardisierten risikobezogenen Daten enthält vorzugsweise
das Ansammeln der in der Vielzahl elektronischer Dossiers enthaltenen
standardisierten risikobezogenen Daten gemäß einem vordefinierten Berichtsprofil.
-
Ein Computerprogrammprodukt gemäß der Erfindung
umfasst mindestens einen der ersten bis dritten Programmcodeteile
und Programmcodeteile, die eine oder mehrere Netzwerkkomponenten
dazu veranlassen, die oben beschriebenen Schritte durchzuführen. Das
Computerprogrammprodukt kann auf einem computerlesbaren Aufzeichnungsmedium
gespeichert sein, das mit einer oder mehreren Netzwerkkomponenten
verbunden oder entfernbar ist.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Ein vollständigeres Verständnis der
vorliegenden Erfindung kann durch Studium der folgenden Beschreibung
der verschiedenen illustrativen Ausführungsformen der Erfindung
in Zusammenhang mit den Zeichnungen erhalten werden:
-
1 ist
ein schematisches Diagramm einer Netzwerkarchitektur, die eine Serverkomponente
gemäß der Erfindung
enthält;
-
2 ist
ein schematisches Diagramm, das eine Serverkomponente gemäß der Erfindung
detaillierter erläutert;
-
3 ist
ein schematisches Diagramm, das einen Zugriffssteuerungsmechanimus
gemäß der Erfindung
erläutert;
-
4 ist
ein schematisches Diagramm, das die individuellen Softwareschichten
gemäß einer
bevorzugten Ausführungsform
der Erfindung darstellt;
-
5 ist
ein schematisches Diagramm, das eine Clientkomponente gemäß der Erfindung
erläutert;
-
6-9 sind schematische Darstellungen der
GUIs der Erfindung zur Eingabe allgemeiner Daten für eine bestimmte
Angelegenheit;
-
10, 11 sind schematische Darstellungen der
GUIs der Erfindung für
die Eingabe standardisierter risikobezogener Daten;
-
12 ist
ein schematisches Diagramm, das einen beispielhaften Risikoklassifizierungsansatz
erläutert;
-
13-15 sind schematische Darstellungen von
GUIs der Erfindung für
die Eingabe standardisierter haftungsbezogener Daten;
-
16 ist
eine schematische Darstellung von GUIs der Erfindung für die Eingabe
von Daten bezüglich
einer Zugriffssteuerung;
-
17, 18 sind schematische Darstellungen von
GUIs der Erfindung zur Erstellung der Risikoberichte;
-
19 ist
eine schematische Darstellung der GUIs der Erfindung zur Eingabe
von Daten bezüglich
eines Risikoberichtsformats; und
-
20 zeigt
schematisch einen Risikobericht gemäß der Erfindung.
-
DETAILLIERTE
BESCHREIBUNG VON VERSCHIEDENEN BEISPIELHAFTEN AUSFÜHRUNGSFORMEN
-
Im Folgenden wird die vorliegende
Erfindung beispielhaft hinsichtlich einer auf einer solchen Netzwerkarchitektur
errichteten webbasierten Lösung dargelegt,
welche die Implementierung eines sicheren und zuverlässigen Zugriffssteuerungsmechanismus
unterstützt.
Obwohl die vorliegende Erfindung insbesondere auf die Handhabung
risikobezogener Daten angepasst ist, können die Netzwerkarchitektur und
der Zugriffssteuerungsmechanismus gemäß der Erfindung unabhängig vom
Wesen der Daten implementiert werden, die von einem Host bereitgestellt, gespeichert,
verarbeitet usw. werden.
-
Eine erste Ausführungsform der Erfindung in Form
einer "klassischen" Client-Server-Anwendung wird nun beschrieben.
-
1 zeigt
eine beispielhafte Client-Server-Netzwerkarchitektur gemäß der Erfindung.
Die Netzwerkarchitektur ist in zwei geographisch voneinander getrennte,
separate Zugriffsbereiche geteilt. Der erste Zugriffsbereich kann
z.B. eine spezielle geographische Region (Stadt, Land usw.) und
der zweite Zugriffsbereich der Rest der Welt oder einfach eine unterschiedliche
geographische Region sein. Im Prinzip können auch mehr als zwei unterschiedliche Zugriffsbereiche
oder überlappende
Zugriffsbereiche definiert werden.
-
Eine Netzwerkkomponente 10 mit
Server-Funktionalitäten
stellt den Kern der Netzwerkarchitektur dar. Die Serverkomponente 10 ist
geographisch im ersten Zugriffsbereich untergebracht, ist aber sowohl
von dem ersten Zugriffsbereich als auch von dem zweiten Zugriffsbereich
aus zugänglich.
-
Bei der in 1 dargestellten Ausführungsform umfasst die Serverkomponente 10 eine
erste Server-Einheit 12 und eine zweite Server-Einheit 14. Innerhalb
der Serverkomponente 10 können die erste Server-Einheit 12 und
die zweite Server-Einheit 14 als separate Software- oder
separate Hardwarekomponenten konfiguriert sein. Die Zugriffskontrolle
wird erleichtert, wenn die beiden Server-Einheiten 12, 14 physikalisch
als separate Hardwarekomponenten konfiguriert sind.
-
Jede der beiden Server-Einheiten 12, 14 bedient
einen unterschiedlichen Zugriffsbereich. Wie aus 1 ersichtlich ist, bedient die erste
Server-Einheit 12 über
ein lokales Verzeichnis LD und über
ein erstes Kommunikationsnetzwerk 16 eine Vielzahl von
im ersten Zugriffsbereich angeordneten verteilten Clientkomponenten
CC. Das erste Kommunikationsnetzwerk 16 kann ein "Wide
Area Network" (WAN), ein "Local Area Network" (LAN) oder eine Kombination
von diesen sein. Zusätzlich
zu ihren Server-Funktionalitäten
führt die
erste Serverkomponente 12 Authentifikations- und Autorisierungsaufgaben
hinsichtlich der im ersten Zugriffsbereich untergebrachten verteilten
Clientkomponenten CCs durch.
-
Die im zweiten Zugriffsbereich angeordnete zweite
Server-Einheit 14 bedient eine im zweiten Zugriffsbereich
untergebrachte zweite Gruppe von verteilten Clientkomponenten CC.
Die zweite Server-Einheit 14 führt diese Aufgabe über ein
lokales Verzeichnis LD, eine Firewall FW und ein zweites Kommunikationsnetzwerk 18 durch.
Das zweite Kommunikationsnetzwerk 18 kann ein WAN, ein
LAN oder eine Kombination von diesen sein. Zusätzlich zu den Server-Aufgaben
authentifiziert die zweite Server-Einheit 14 die im zweiten
Zugriffsbereich untergebrachten verteilten Clientkomponenten CC
und prüft ihre
Autorisierung.
-
Das erste Kommunikationsnetzwerk 16 und das
zweite Kommunikationsnetzwerk 18 sind in separaten Zugriffsbereichen
angeordnet. Bei der in 1 dargestellten Ausführungsform
besteht keine Überlappung
zwischen dem ersten Kommunikationsnetzwerk 16 und dem zweiten
Kommunikationsnetzwerk 18.
-
Jede der ersten Server-Einheit 12 und
der zweiten Server-Einheit 14 enthält eine separate Datenbank 20, 22.
In der Datenbank 22 der zweiten Server-Einheit 14 werden
die im zweiten Zugriffsbereich erzeugten elektronischen Dossiers
gespeichert, während
in der Datenbank 20 der ersten Server-Einheit 12 elektronische
Dossiers gespeichert werden, die entweder in dem ersten oder in
dem zweiten Zugriffsbereich erzeugt wurden. Um in der Datenbank 20 der ersten
Server-Einheit 12 im zweiten Zugriffsbereich erzeugte elektronische
Dossiers zu speichern, müssen
die in der Datenbank 22 der zweiten Server-Einheit 14 gespeicherten
elektronischen Dossiers dupliziert werden. Dazu wird zwischen der
Datenbank 22 der zweiten Server-Einheit 14 und
der Datenbank 20 der ersten Server-Einheit 12 eine
Replikationsverbindung 24 errichtet. Die Replikationsverbindung 24 kann
nur temporär
errichtet sein oder über
längere Zeiträume errichtet
bleiben.
-
Wie anhand des die Replikationsverbindung bezeichnenden,
in eine einzige Richtung zeigenden Pfeils erkennbar, wird die Replizierung
gemäß einer Einweg-Replikationsvorschrift
durchgeführt.
Bei der in 1 dargestellten
Ausführungsform
bedeutet dies, dass dort nur ein Datenfluss von der Datenbank 22 der
zweiten Server-Einheit 14 zu der Datenbank 20 der
ersten Server-Einheit 12 vorhanden ist, aber kein Datenfluss
in die Gegenrichtung. Diese Einweg-Replikationsvorschrift unterstützt eine
Zugriffssteuerung, gemäß welcher
die Clientkomponenten CCs, die im ersten Zugriffsbereich untergebracht sind,
prinzipiell (d.h. nicht berücksichtigt
werden individuelle Zugriffsbeschränkungen) zum Zugreifen auf alle
elektronischen Dossiers unabhängig
von ihrer Herkunft autorisiert sind, während die im zweiten Zugriffsbereich
untergebrachten Clientkomponenten CCs (vorausgesetzt dass diese
Clientkomponenten CCs geeignete individuelle Zugriffsrechte haben)
nur zum Zugreifen auf die im zweiten Zugriffsbereich erzeugten elektronischen
Dossiers autorisiert sind.
-
Beachtet werden sollte, dass in den
Datenbanken 20, 22 der Server-Einheiten 12, 14 auch
zusätzliche,
sich nicht auf die dort gespeicherten elektronischen Dossiers beziehende
Daten gespeichert sein können.
Für solche
zusätzliche
Daten kann parallel zu der in 2 dargestellten
Replikationsverbindung 24 eine zusätzliche Replikationsverbindung
errichtet werden. Diese zusätzliche
Replikationsverbindung kann auf einer Zwei-Wege-Replikationsvorschrift
basieren, die sicherstellt, dass die zusätzlichen Daten nicht nur von
der Datenbank 22 der zweiten Server-Einheit 14 zur Datenbank 20 der
ersten Server-Einheit 12 transferiert werden, sondern auch umgekehrt.
-
Die Struktur der ersten Server-Einheit 12,
die zu der Serverkomponenten 10 gemäß 1 gehört, wird
nun unter Bezugnahme auf 2 detaillierter beschrieben.
Wie aus 2 ersichtlich
ist, hat die erste Server-Einheit 12 für die Kommunikation über das
erste Kommunikationsnetzwerk 16 (und über ein in 2 nicht dargestelltes Ladeverzeichnis)
zu den im ersten Zugriffsbereich untergebrachten verteilten Clientkomponenten
eine Schnittstelle 28. Ferner ist die erste Server-Einheit 12 über die
Replikationsverbindung 24 in Kommunikation mit der zweiten
Server-Einheit 14 und insbesondere mit der Datenbank 22,
welche die im zweiten Zugriffsbereich erzeugten elektronischen Dossiers
enthält.
In Abhängigkeit
von der Konfiguration der ersten und der zweiten Server-Einheit 12, 14 kann
die Replikationsverbindung 24 eine Software- oder Hardware-Lösung sein.
-
Zusätzlich zu der oben erwähnten Schnittstelle 28 umfasst
die erste Server-Einheit 12 einen mit der Schnittstelle 28 in
Verbindung stehenden Zugriffssteuerungslisten (access control list,
ACL)-Controller 30, eine mit dem ACL-Controller 30 in
Verbindung stehende Host-Einheit 32, eine mit dem ACL-Controller 30 in
Verbindung stehende Datenbank 20 für elektronische Dossiers, einen
mit sowohl der Datenbank 20 als auch dem ACL-Controller 30 in Verbindung
stehenden Berichterzeugungsprozessor 34 und eine Replikationseinheit 36.
-
Die Replikationseinheit 36 steht
mit der Datenbank 20 der ersten Server-Einheit 12 in
Verbindung und über
die Replikationseinheit 24 mit der Datenbank 22 der
zweiten Server-Einheit 14. Die Replikationseinheit 36 muss
nicht unbedingt eine interne Einheit der ersten Server-Einheit 12 sein.
Es kann ebenso eine interne Einheit der zweiten Server-Einheit 14 sein
oder intern in Bezug auf die Serverkomponente 10 von 1 bereitgestellt werden,
jedoch extern in Bezug auf die beiden Server-Einheiten 12, 14.
-
Die zweite Server-Einheit 14 hat
einen ähnlichen
Aufbau wie die erste Server-Einheit 12 und ähnliche
Funktionalitäten.
Daher wird nur die in 2 dargestellte
erste Server-Einheit 12 im Folgenden beispielhaft detaillierter
erörtert.
-
Nachdem eine Clientkomponente von
der erste Server-Einheit 12 authentifiziert ist, werden
alle Zugriffe von dieser Clientkomponente über das erste Kommunikationsnetzwerk 16 und
die Schnittstelle 28 innerhalb des ACL-Controllers 30 einer
Autori sierungsprüfung
unterzogen. So verhindert der ACL-Controller nicht autorisierte
Zugriffe auf jede der Komponenten Datenbank 20, Host-Einheit 32 und Berichterzeugungsprozessor 34.
Die spezielle, durch den ACL-Controller 32 erzwungene Zugriffssteuerungsvorschrift
wird später
unter Bezugnahme auf 3 detaillierter
erklärt.
-
Die in 2 dargestellte
Host-Einheit 32 der ersten Server-Einheit 12 stellt
als Host den Programmcode für
die im ersten Zugriffsbereich untergebrachte erste Gruppe von Clientkomponenten
bereit. Der von der Host-Einheit 32 als Host bereitgestellte Programmcode
enthält
Programmcodeteile zur Erzeugung der GUIs und Eingabeaufforderungen,
die später
unter Bezugnahme auf die 6-11 und 13-20 erörtert werden.
-
Jede zur ersten Gruppe von Clientkomponenten
gehörende,
im ersten Zugriffsbereich untergebrachte und geeignete Zugriffsrechte
besitzende Clientkomponente kann den Berichterzeugungsprozessor 34 auslösen, um
einen elektronischen Risikobericht mittels automatisierter Verarbeitung
der in der Datenbank 20 gespeicherten standardisierten
risikobezogenen Daten, die in den elektronischen Dossiers enthalten
sind, zu erzeugen. Der elektronische Risikobericht wird gemäß einem
vordefinierten Berichtsprofil erzeugt, welches von der den Berichterzeugungsprozessor 34 auslösende Clientkomponente
bereitgestellt oder welches zuvor in einem internen Datenspeicher
des Berichterzeugungsprozessors 34 gespeichert wurde.
-
Einzelheiten bezüglich der Erzeugung eines Berichtsprofils
und eines elektronischen Risikoberichts werden später unter
Bezugnahme auf die 17-20 detaillierter ausgeführt. Angemerkt
sei hier, dass nur der Berichterzeugungsprozessor 34 der
ersten Server-Einheit 12 einen "globalen" Risikobericht
erzeugen kann, weil nur die Datenbank 20 der ersten Server-Einheit 12 komplett
die elektronischen Dossiers beider Zugriffsbereiche enthält. Der
entsprechende Berichterzeugungsprozessor der zweiten Server-Einheit 14 kann
nur "lokale" Risikoberichte erzeugen, auf Grundlage der in der Datenbank 22 der
zweiten Server-Einheit 14 gespeicherten elektronischen
Dossiers, d.h. auf der Grundlage auf der im zweiten Zugriffsbereich
erzeugten elektronischen Dossiers. Eine solche Konfiguration fügt eine
zusätzliche
Sicherheitsschicht dem erfindungsgemäß implementierten Zugriffssteuerungsmechanismus
hinzu. Dies wird nun unter Bezugnahme auf 3 detaillierter beschrieben.
-
3 zeigt
das Zugriffssteuerungsschema, das unter Verwendung zweier verschiedener
Server-Einheiten 12, 14 gemäß der Erfindung implementiert
ist, mit geeignet konfigurierten ACL-Controllern in jeder der Server-Einheiten 12, 14 und
einer Ein weg-Replikationsverbindung 24 für die Replizierung der
in den Server-Einheiten 12, 14 verwalteten elektronischen
Dossiers.
-
Gemäß dem in 3 dargestellten Zugriffssteuerungsschema
bestimmt die durch den für
den ersten Zugriffsbereich verantwortlichen ACL-Controller erzwungene
ACL, dass zum zweiten Zugriffsbereich gehörende Benutzer keinen Zugriff
auf die in der Datenbank 20 der Server-Einheit 12 gespeicherten
elektronischen Dossiers haben, sogar wenn sie vorübergehend
im ersten Zugriffsbereich ansässig wären. Weiterhin
wird bestimmt, dass es zum ersten Zugriffsbereich gehörenden Benutzern
erlaubt ist, alle in der Datenbank 20 der ersten Server-Einheit 12 verfügbaren elektronischen
Dossiers zu lesen, vorausgesetzt dass ihre Zugriffsrechte nicht
individuell beschränkt
sind.
-
Nun wird die durch den ACL-Controller
der zweiten Server-Einheit 14 erzwungene ACL erörtert. Die
im zweiten Zugriffsbereich erzwungene ACL enthält keinerlei Beschränkungen.
Dies bedeutet, dass prinzipiell jeder Benutzer des zweiten Zugriffsbereichs
auf jedes in der Datenbank 22 der zweiten Server-Einheit 14 gespeicherte
elektronische Dossier Zugriff hat, vorausgesetzt dass geeignete
individuelle Zugriffsrechte erteilt wurden. Angemerkt sei jedoch, dass
im ersten Zugriffsbereich erzeugte elektronische Dossiers in der
Datenbank 22 der zweiten Server-Einheit 14 nicht
verfügbar
sind. Daher kann jeder Benutzer mit Zugriff auf die Datenbank 22 der
zweiten Server-Einheit 14 nur die im zweiten Zugriffsbereich
erzeugten elektronischen Dossiers lesen. Dies bedeutet, dass sogar
dann, wenn ein üblicherweise im
ersten Zugriffsbereich ansässiger
Benutzer (der somit bezüglich
der im ersten Zugriffsbereich erzeugten elektronischen Dossiers
prinzipiell unbeschränkte
Zugriffsrechte hat) vorübergehend
im zweiten Zugriffsbereich ansässig
wäre, dieser
Benutzer nur die im zweiten Zugriffsbereich erzeugten elektronischen Dossiers
lesen kann, weil es nicht möglich
ist, auf im ersten Zugriffsbereich erzeugte elektronische Dossiers
von einer im zweiten Zugriffsbereich untergebrachten Clientkomponente
aus zuzugreifen.
-
Wie oben bereits erwähnt wurde,
ist die erste Ausführungsform
der Erfindung als klassische Server-Client-Anwendung konfiguriert. 4 zeigt die beispielhaft
geschichtete Softwarestruktur einer solchen Client-Server-Anwendung.
-
Die 4 dargestellte
Softwarestruktur ist grundsätzlich
in eine bei der Clientkomponente angesiedelten Benutzerschicht und
eine bei der Serverkomponente (Lotus Notes/Domino Server) angesiedelte
Anwendungsschicht unterteilt. Die Benutzer schicht umfasst einen
Web-Browser als primäre
Benutzerschnittstelle, einen E-Mail-Client und eine oder mehrere Office-Anwendungen
wie ein Textverarbeitungsprogramm.
-
Die Interaktion zwischen der Benutzerschicht
und der Anwendungsschicht wird hauptsächlich in Übereinstimmung mit TCP/IP über einen HTTP-Server
(beinhaltet in der Lotus Notes/Domino Plattform) durchgeführt. Die
eigentliche Anwendung umfasst eine Vielzahl von einzelnen Komponenten wie
eine Mailbox für
den Transfer von E-Mails von und zum E-Mail-Client der Benutzerschicht.
Zusätzlich
wird eine Berichtsdatenbank bereitgestellt, in der früher erzeugte
Berichte in Form von HTML-Dokumenten
gespeichert sind. Früher
erzeugte, in der Berichtsdatenbank gespeicherte Berichte können von einem
Benutzer zu einem späteren
Zeitpunkt zurückgeholt
und z.B. in eine Office-Anwendung zur weiteren Verarbeitung exportiert
werden. Die in der Berichtsdatenbank gespeicherten Originalberichte
sind schreibgeschützt
und können
nicht geändert
werden.
-
Weitere Komponenten der auf der Serverkomponente
laufenden Anwendung beinhalten eine Datenbank für elektronische Dossiers, eine
Komponente für
Wissensmanagement, eine Referenzdatenbank, eine Administrationskomponente
und eine Komponente für
die Verwaltung extern bereitgestellter Referenzdaten.
-
Die oben unter Bezugnahme auf die 1-4 beschriebene erste Ausführungsform
basiert auf einem Client-Server-Ansatz. Im Folgenden wird eine zweite
Ausführungsform
der Erfindung unter Bezugnahme auf 5 beschrieben.
Gemäß der zweiten Ausführungsform
ist die Serverkomponente optional, weil der Programmcode, der durch
eine Netzwerkkomponente in Verbindung mit der Erzeugung oder Aktualisierung
eines elektronischen Dossiers ausgeführt wird, nicht unbedingt durch
eine als Host-Einheit arbeitende Serverkomponente bereitgestellt
werden muss, sondern in einen Datenspeicher dieser Netzwerkkomponente
von einem externen Datenträger wie
einer CD-ROM oder einer DVD oder von einem internen Datenträger wie
einer Festplatte geladen worden sein kann.
-
In 5 sind
die Netzwerkkomponenten 40, 56 für die Implementierung
der zweiten Ausführungsform
der Erfindung schematisch gezeigt. Auf eine detailliertere Beschreibung
der Netzwerkarchitektur und eine Erörterung des Zugriffssteuerungsschemas
für die
zweite Ausführungsform
wird verzichtet. Prinzipiell jedoch kann die zweite Ausführungsform
auf einer Netzwerkarchitektur ähnlich
der in 1 gezeigten und
auf dem unter Bezugnahme auf 3 erklärten Zugriffssteuerungsschema
basieren.
-
Wie aus 5 ersichtlich ist, umfasst eine Netzwerkkomponente 40 gemäß der Erfindung
(hier als eine Clientkomponente konfiguriert) eine Schnittstelle 42,
die zwischen einem Kommunikationsnetzwerk 43 auf der einen
Seite und einem Berichterzeugungsprozessor 44 und einem
elektronischen Dossierprozessor 46 der Clientkomponente 40 auf
der anderen Seite angeordnet ist. Der elektronische Dossierprozessor 46 der
Clientkomponente 40 ist zwischen der Schnittstelle 42 und
einem Programmcodespeicher 48 angeordnet. Im Programmcodespeicher 48 sind
der zur Erzeugung der GUIs erforderliche Programmcode und die unten
unter Bezugnahme auf die 6-11 und 13-18 erläuterte Eingabeaufforderung
gespeichert. Diese Programmcodes wurden über eine weitere Schnittstelle 50 der
Clientkomponente 40 von einem externen Datenträger in Form
einer CD-ROM oder DVD 52 in den Programmcodespeicher 48 geladen.
-
Der Programmcodespeicher 48 enthält einen Programmcode,
der den elektronischen Dossierprozessor 46 steuert, damit
dieser die zur Erzeugung oder zur Aktualisierung eines elektronischen
Dossiers erforderliche Daten von einem Benutzer der Clientkomponente 40 anfordert.
Wenn ein elektronisches Dossier einmal erzeugt oder aktualisiert
wurde, steuert der Programmcode den elektronischen Dossierprozessor 46,
um das erzeugte oder aktualisierte elektronische Dossier über das
Kommunikationsnetzwerk 43 zu der weiteren Netzwerkkomponente 56 zu übertragen.
Diese weitere Netzwerkkomponente 56 kann eine Serverkomponente
oder eine weitere Clientkomponente sein.
-
Das über das Kommunikationsnetzwerk 43 von
der Clientkomponente 40 empfangene, erzeugte oder aktualisierte
elektronische Dossier wird über eine
Schnittstelle 54 der Netzwerkkomponente 56 empfangen
und in einer zentralen Netzwerkdatenbank 58 gespeichert.
In der Datenbank 58 werden elektronische Dossiers gespeichert,
die von der Netzwerkkomponente 56 von einer Vielzahl von
Clientkomponenten empfangen worden sind, die eine ähnliche
Struktur wie die in 5 dargestellte
Clientkomponente 40 haben.
-
Wenn die Clientkomponente 40 einen
Programmcodeteil ausführt,
der die Erzeugung eines Risikoberichts auslöst, greift der Berichterzeugungsprozessor 44 der
Clientkomponente 40 auf die Datenbank 58 der Netzwerkkomponente 56 zu,
um durch automatisierte Verarbeitung der standardisierten risikobezogenen
Daten, welche in der in der Datenbank 58 gespeicherten
Vielzahl elektronischer Dossiers enthalten sind, einen elektronischen
Risikobericht zu erzeugen.
-
Im Folgenden werden die Dateneingabe- und
die Datenverarbeitungsoperationen unter Bezugnahme auf die Bildschirmausdrucke
der 6-11 und 13-20 beschrieben, die unter
der Steuerung der Programmcodeteile, die von den in den 1 und 3 dargestellten, als Host fungierenden
Server-Einheiten 12, 14 bereitgestellt und/oder
in dem in 5 dargestellten
Datenspeicher 48 der Clientkomponente 40 gespeichert
sind, durchgeführt
werden. Bei der nachfolgenden Ausführungsform wird die Verwaltung der
elektronischen Dossiers bezogen auf in Verbindung mit typischen
Geschäftsoperationen
vorkommenden Ereignissen beispielhaft erläutert. Für solche Ereignisse sind Risikoeinschätzungen
und ein sicheres Berichten von Risiken unerlässlich.
-
Jedes Mal, wenn ein z.B. auf ein
rechtliches Ereignis bezogenes, neues elektronisches Dossier erzeugt
oder ein existierendes aktualisiert werden soll, muss der "Universal
Ressource Locator" (URL) der den Programmcode als Host bereitstellenden Serverkomponente
in den Web-Browser einer Clientkomponente eingegeben oder ein entsprechender Link
aktiviert werden (erste Ausführungsform
wie in den 1-4 dargestellt). Bei der in 5 dargestellten zweiten
Ausführungsform
muss der im Programmcodespeicher 48 der Clientkomponente 40 enthaltene
Programmcode ausgeführt
werden.
-
In einem nächsten Schritt werden Authentifikations-
und Autorisierungsschritte durchgeführt, um die Authentität eines
Benutzers festzustellen und zu prüfen, ob der authentifizierte
Benutzer tatsächlich zur
Erzeugung oder Aktualisierung des elektronischen Dossiers autorisiert
ist. Sobald die Authentifikation und die Autorisierung erfolgreich
durchgeführt wurden,
wird eine erste GUI 60 mit dem in 6 dargestellten Inhalt über den
Browser der Clientkomponente angezeigt.
-
Die GUI 60 hat ein Steuerelement
in Form eines Links 54, bezeichnet als "Erzeuge Datei"
(der Term "Datei" bezeichnet ein elektronisches Dossier), der mittels
z.B. einer Maus zum Erzeugen eines Steuersignals aktivierbar ist.
Ein auf das Erzeugen dieses Steuersignals reagierender Programmcodeteil
erzeugt eine weitere GUI 64 in Form eines Registerblattes
mit der Bezeichnung "Allgemein".
-
6 zeigt
die GUI 64 in einem Zustand nach der Bestätigung von
früher
eingegebenen allgemeinen Daten. Während der Dateneingabe hat
die GUI 64 ein wie in 7 gezeigtes
Aussehen.
-
Wie aus den 6 und 7 ersichtlich
wird, existieren sechs weitere Registerblätter mit den Bezeichnungen
"Speziell", "Hintergrund", "Finanzen", "Risiko", "Daten" und "Zugriff'.
Die Funktion der weiteren Registerblätter wird unten erklärt werden.
-
Die GUI in dem Zustand gemäß 7 beinhaltet die Aufforderung
zur Eingabe von verschiedenen, standardisierten und nicht-standardisierten,
allgemeinen, ein spezielles Ereignis charakterisierenden Daten,
das sich im Zusammenhang mit einem Geschäftsbetrieb ereignete. Das nicht
standardisierte Feld 66 fordert z.B. den Benutzer zur Eingabe
einer speziellen Bezeichnung für
das zu erzeugende elektronische Dossier auf. Das nächste Datenfeld "Dateityp" 68 akzeptiert
nur standardisierte Eingaben. Wenn das Datenfeld 68 aktiviert
wird, öffnet
sich ein Pul-Down-Menü und
der Benutzer kann zwischen verschiedenen standardisierten Dossier-Typen
wie allgemeine Angelegenheiten, Streitfälle (d.h. ein Prozess, in den
die Firma entweder als Kläger,
als Beklagter oder als Zeuge involviert ist), Aussicht eines Falles
(d.h. ein Fall, der zukünftig
ein spezielles Risiko hervorrufen kann), die eine rechtliche Beschwerde (d.h.
eine Beschwerde von einem Klienten oder Kunden, die eine rechtliche
oder Erfüllungsimplikation haben
könnte)
usw. auswählen.
Weitere Datenfelder zur Eingabe von allgemeinen Daten, bezogen auf
ein spezielles Ereignis, beinhalten ein Datenfeld 70 für Hinweise
auf die verantwortliche Person, welche für die Bearbeitung des Ereignisses
verantwortlich ist, eine Vielzahl 72 von Datenfeldern für die Bestimmung
der in das Ereignis involvierten juristische Einheit und ein Datenfeld 74 für das Eintragen
eines externen Rechtsbeistandes, der bei der Abwicklung des Ereignisses
assistiert.
-
Sobald alle verfügbaren Datenfelder der GUI 64 mit
den geeigneten standardisierten oder nicht-standardisierten, die
bestimmte Angelegenheit charakterisierenden allgemeinen Daten ausgefüllt wurden,
können
weitere allgemeine Daten in die Registerblätter "Speziell" und "Hintergrund"
eingegeben werden. In der GUI 64 bilden alle Registerblätter von "Speziell"
bis zu "Zugriff' Steuerelemente, die über darauf Klicken mit einer
Maus aktivierbar sind zum Generieren eines entsprechenden Steuersignals.
Als Reaktion auf die Generierung eines solchen Steuersignals wird
ein auf die Generierung des speziellen Steuersignals reagierender
spezieller Programmcodeteil ausgeführt und der spezielle Programmcodeteil
erzeugt eine entsprechende GUI, die eine zusätzliche Dateneingabe erlaubt.
Zum Beispiel wird durch Klicken auf das Registerblatt "Speziell" 76 von
GUI 64 die entsprechende in 8 dargestellte
GUI 80 und durch Klicken auf das Registerblatt "Hintergrund" die
entsprechende in 9 dargestellte
GUI 82 angezeigt.
-
Jede der GUIs 80, 82 beinhaltet
eine Vielzahl von Aufforderungen (Datenfelder) zur Eingabe von das
Ereignis weiter charakterisierenden allgemeinen Daten. Zum Beispiel
beinhaltet die GUI 80 ein Datenfeld 81 mit dem
Bezeichnung "Versicherungsanspruch", das den Benutzer zur Spezifizierung
versicherungsbezogener Daten auffordert. Hinsichtlich der Aufforderung 81 kann
der Benutzer zwischen den Standardoptionen "Nein", "Ja" und "Nicht
bekannt" wählen.
"Nein" erteilt den die Versicherungsangelegenheiten abwickelnden
Benutzern keinen Zugriff auf die elektronischen Dossiers, während die
anderen beiden Optionen solche Benutzer zur Zugriffsliste hinzufügen. Die
Zugriffsformen auf das elektronische Dossier sind in Form einer
entsprechenden Nachricht auf der rechten Seite des Datenfeldes "Versicherungsanspruch"
81 gezeigt. Wenn ein die Versicherungsangelegenheiten abwickelnder
Benutzer den Wert auf "Nein" setzt, wird der Zugriff auf das elektronische
Dossier für
alle die Versicherungsangelegenheiten abwickelnden Benutzer widerrufen.
Da die verbleibenden Datenfelder der GUI 80, 82 passende Bezeichnungen
haben, wird auf eine detailliertere Beschreibung der Eingabemöglichkeiten
hier verzichtet.
-
Ein wichtiger Aspekt des Risikoberichtsvorganges
ist ein standardisierter Risikomessprozess. Der Risikomessprozess
beginnt mit der Sammlung von "harten" Zahlen, die mit einem speziellen
Ereignis (z.B. Streitfälle,
Aussicht eines Falles, rechtliche Beschwerde, usw.) verbunden sind.
-
Durch Aktivierung des in den GUIs 64, 80 und 82 enthaltenen
Registerblattes mit dem Bezeichnung "Finanzen" wird ein Steuersignal
generiert, das einen auf die Generierung dieses Steuersignals reagierenden
speziellen Programmcodeteil zum Erzeugen der in 10 dargestellten GUI 84 veranlasst. Die
GUI 84 enthält
verschiedene Datenfelder zur Eingabe von sowohl allgemeinen Daten
als auch risikobezogenen Daten für
das Ereignis. Zum Beispiel ist das Datenfeld 86 der GUI 84 als
ein Pull-Down-Menü konfiguriert,
das die Auswahl der spezifischen Währung erlaubt, in welcher die
allgemeinen und risikobezogenen Zahlen anschließend eingegeben werden. Die
weiteren Datenfelder 88 erlauben die Eingabe von speziellen
Zahlen, die das Ereignis und das damit verbundene Risiko näher charakterisieren.
-
Standardisierte risikobezogene Zahlen,
die über
die Datenfelder 88 des Registerblattes "Finanzen" eingegeben
werden, werden jetzt beispielhaft erklärt. Das Datenfeld "Ausgangswert"
bezieht sich auf die erste Summe, die durch den Anspruchssteller in
einem bestimmten Verfahren gefordert wird. Das Datenfeld "Aktueller
Wert" bezeichnet den aktuellsten Wert, der von dem Anspruchssteller
einschließlich
aller Zinsen gefordert wird. Das Datenfeld "Vergleichswert" bezieht
sich auf die Summe, welche nach Auffassung der für die Abwicklung des rechtlichen
Ereignisses verantwortlichen Person voraussichtlich zu zahlen sein
wird oder erhalten werden wird. In einem nächsten Schritt werden die erwarteten
Kosten bewertet und in das geeignete Datenfeld eingegeben. Die erwarteten
Kosten sind der zu erwartende Verlust, der in Verbindung mit dem
speziellen Ereignis entsteht. Mit anderen Worten hilft das Datenfeld
"Erwartete Kosten" zur Aufzeichnung des erwarteten Nettoresultats,
das aus z.B. einem speziellen Streit oder einer speziellen Forderung
entsteht.
-
Die für die Abwicklung des speziellen
Ereignisses verantwortliche Person hat entsprechend der Summe der
zu erwartenden Kosten zur Rücklagenerstellung
aufzufordern. Dieser Rücklagenprozess
bezieht sich im einzelnen auf alle Typen der Folge- (auch genannt
"operative") Risiken. Als eine Regel sollte die Summe in Datenfeld
"Rücklage
Rechtskosten" dieselbe Summe sein wie im Datenfeld "Erwartete Rechtskosten".
Die Rücklagen
werden auf das Konto gebucht, auf welches sich der ausgewählte Risikotyp
bezieht. Zum Beispiel werden Rücklagen
für ein
Ereignis mit einem Haftungsrisiko in "Haftungsrücklagenkonto" gebucht. Details
bezüglich
der Auswahl eines speziellen Risikotyps werden unter Bezugnahme
auf die 11 und 12 unten erklärt werden.
Wenn ein Ereignis nur Primärrisiken
wie ein Kreditrisiko oder ein Marktrisiko (12) umfasst, kann der Rücklagenprozess
direkt durch den Geschäftsbereich
eingeleitet werden, in dessen Betätigungsfeld das rechtliche
Ereignis aufgetreten ist. Unabhängig
vom Risikotyp müssen
Informationen über
die Kontonummern und die "Buchungseinheit", die für den Rücklagenprozess
verantwortlich ist, in die entsprechenden Datenfelder 90 eingegeben
werden.
-
Ein weiteres finanzielles Risiko
entsteht aus den mit dem bestimmten Ereignis zusammenhängenden
Rechtskosten. Derartige Rechtskosten beinhalten z.B. Kosten für externen
Rechtsbeistand, Gebühren
für Gerichtsverfahren
usw.. Wenn ein elektronisches Dossier für ein spezielles Ereignis erzeugt wird,
muss eine entsprechende Zahl für
die ungefähren
Rechtskosten veranschlagt und in das Datenfeld "Anfangs erwartete
Rechtskosten" eingegeben werden. Wenn die erwarteten Rechtskosten
einen bestimmten Betrag überschreiten,
muss eine Rücklage gebildet
werden. Zu diesem Zweck wird ein geeigneter Wert in das Datenfeld
"Rücklage
Rechtskosten" eingetragen.
-
Jedes Mal wenn eine Rechnung zur
Zahlung registriert wird, muss die entsprechende Summe unter Verwendung
einer (nicht in den Zeichnungen dargestellten) GUI gebucht werden.
Dies erlaubt ein automatisiertes Bestimmen und Anzeigen der gesamten
aufgelaufenen Rechts- und Gerichtskosten für ein spezielles rechtliches
Ereignis.
-
Der oben bezogen auf die 10 beschriebene standardisierte
Risikomessansatz hilft beträchtlich,
die Vorgänge
des automatischen Risikoberichtens und der automatischen Rücklage zu
erleichtern. Dies wird unten detaillierter beschrieben.
-
Durch Aktivierung des Steuerelements
in Form des "Risiko"-Registerblattes 94 von z.B. der in 10 dargestellten GUI 84 wird
ein Steuersignal generiert, das eine Aufforderung zur Eingabe von
zusätzlichen
risikobezogenen Daten hervorruft. In 11 wird
eine entsprechende GUI 94 angezeigt. Im Folgenden werden
die relevanten Datenfelder 96 dieser GUI 94 und
die standardisierten Optionen für das
Ausfüllen
dieser Datenfelder 96 detaillierter erklärt.
-
Das erste Datenfeld der Vielzahl
von Datenfelder 96 bezieht sich auf den einen oder die
mehreren spezifischen Risikotypen, die mit dem bestimmten Ereignis
verbundenen sind, für
welche das elektronische Dossier erzeugt wurde. Ein Überblick über die
standardisierten Risikotypen, die in das Datenfeld "Risikotyp" eingegeben
werden können,
ist in 12 gezeigt.
-
Wie man der 12 entnehmen kann, werden drei unterschiedliche
Risikokategorien unterschieden, nämlich Primärrisiko, Gefahr der Rufschädigung und
Folgerisiko (oder operatives Risiko). In der in 11 dargestellten Ausführungsform ist der zur Risikokategorie
Folgerisiko gehörende
Risikotyp "Erfüllungsrisiko"
eingetragen worden. Der Risikotyp "Erfüllungsrisiko" bezieht sich
auf das Risiko, dass das Unternehmen anwendbare Gesetze, interne oder
externe Vorschriften oder Beschränkungen nicht
erfüllt
und mit irgendeiner Form von Sanktionen bestraft werden kann. Andere
Risikotypen beinhalten Marktrisiko (Verlustrisiko entstehend aus
Marktpreisbewegungen einschließlich
der Zinssätze
usw.), Kreditrisiko (Risiko, dass eine Gegenseite oder ein Aussteller
eines Schuldtitels seiner Verbindlichkeit nicht nachkommt oder dass
ihre/seine Fähigkeit
zum Erfüllen
der Verbindlichkeit fragwürdig
wird), Gefahr der Rufschädigung
(Risiko des Geschäftsverlusts,
entstehend als Resultat einer Unterlassung, Geschäftsaktivitäten in einer
geeigneten Weise auszuführen), Haftungsrisiko
(Verlustrisiko, verursacht dadurch, dass das Unternehmen für einen
vertraglichen oder rechtlichen Anspruch, eine Verbindlichkeit oder
eine Aktion für
verantwortlich gehalten wird), rechtliches Risiko (Verlustrisiko,
weil Verträge
nicht durchgesetzt werden können,
einschließlich
der aus mangelhafter Dokumentation, unzureichender Kapazität usw. entstehenden
Risiken).
-
Nachdem der standardisierte Risikotyp
ausgewählt
wurde, muss das mit dem speziellen Ereignis verbundene Risiko hinsichtlich
einer der vordefinierten Kategorien "Gering", "Mittel" und "Hoch"
eingestuft werden. Ein geringes Risiko bedeutet, dass eine geschätzte Wahrscheinlichkeit
zwischen 0 % und 25 % beträgt,
dass z.B. das Unternehmen ein streitiges Verfahren verlieren wird.
Der entsprechende Prozentsatzbereich für ein mittleres Risiko beträgt 26 % bis
70 % und für
ein hohes Risiko 71 % bis 100 %.
-
Die Datenfelder "Gefahr der Rufschädigung" und
"PR-Risiko" müssen
ausgefüllt
werden, wenn das Ereignis den Ruf des Unternehmens beeinflusst. In
einem ersten Schritt muss ausgewählt
werden, mit welcher Intensität
der Ruf des Unternehmens durch das Ereignis berührt wird. Zu diesem Zweck muss eine
der standardisierten Klassifikationen "Gering", "Mittel", "Hoch"
oder "Keine Gefahr der Rufschädigung"
ausgewählt
werden. In einem zweiten Schritt muss durch Ausfüllen des Datenfeldes "PR-Risiko" die
Art und Weise beschrieben werden, in welcher das Ereignis öffentliche
Beachtung finden wird. Die folgenden standardisierten Eingaben sind
verfügbar: "keine
externe Auswirkung", "keine Medienberichterstattung", "eingeschränkte lokale
Bedeutung oder lokale Medienberichterstattung", "eingeschränkte nationale
Bedeutung" und "anhaltende nationale und beschränkte internationale Medienberichterstattung".
-
Das Datenfeld "Anderes Risiko" der
Vielzahl der Datenfelder 96 der GUI 94 hilft dem
Erkennen solcher rechtlicher Ereignisse, die Merkmale aufweisen,
welche die Richtung des Unternehmens betreffen könnten, in der es künftig seine
Tätigkeiten
ausführen
muss. Standardisierte Eingabeoptionen enthalten z.B. "Risiko Präzedenzfallschaden"
(diese Option sollte ausgewählt
werden, wenn ein nachteiliger Urteilsspruch aus dem Ereignis entstehen
könnte, der
starken Einfluss auf die Fähigkeit
des Unternehmens hat, auf bestimmte Rechtsgebiete oder Marktprodukte
zuzugreifen), "Symptom eines Steuerungsfehlverhaltens" (die Existenz
eines bestimmten Ereignisses kann signifikantes Steuerungsfehlverhalten
innerhalb des Unternehmens anzeigen) und andere.
-
Ein wichtiges Datenfeld hinsichtlich
des automatisierten Risikoberichtens ist das Datenfeld "Gruppenrisikobericht"
von GUI 94. Dieses Datenfeld erlaubt die Steuerung von
Aspekten, die sich auf das Berichten von einem speziellen Ereignis
beziehen, für
welches das elektronische Dossier erzeugt wird. Insbesondere erlaubt
dieses Datenfeld die Auswahl, ob und in welcher Weise ein bestimmtes
Ereignis in einen "globa len" Risikobericht, bezogen auf alle mit einem
speziellen (z.B. geographischen oder funktionalen) Geschäftsbereich
des Unternehmens oder der ganzen Unternehmung verbundenen Risiken,
einbezogen wird. Die folgenden standardisierten Eingaben werden
akzeptiert:
- – Gruppenrisikobericht (group
risk report, GRR) nicht relevant:
Das Ereignis sollte nicht
in den GRR aufgenommen werden
- – GRR
neu:
Das Ereignis wird zum ersten Mal in den GRR aufgenommen
werden. In der Regel sollten alle rechtlichen Ereignisse mit erwarteten
Kosten (rechtliches Risiko) höher
als ein vordefinierter Wert oder mit einer sehr hohen Gefahr der
Rufschädigung
in den GRR aufgenommen werden.
- – GRR
wesentliche Entwicklungen seit dem letzten Bericht:
Das Ereignis
wurde bereits in den letzten GRR aufgenommen. Seither sind einige
neue Entwicklungen erfolgt, die es wert sind, im GRR erwähnt zu werden.
- – GRR
keine materiellen Entwicklungen seit dem letzten Bericht:
Über das
Ereignis wurde bereits im letzten GRR berichtet. Jedoch sind seither
keine wesentlichen Entwicklungen eingetreten, die es wert sind,
in den GRR aufgenommen zu werden.
-
Wie aus dem obigen ersichtlich wurde,
ist die in 11 dargestellte
GUI 94 neben der in 10 dargestellten
GUI 84 die Hauptschnittstelle zur Eingabe standardisierter
risikobezogener Daten für
ein bestimmtes Ereignis.
-
In vielen Fällen werden die mit einem Ereignis
verbundenen Risiken durch eine Versicherung abgedeckt. Deshalb ist
es vorteilhaft, versicherungsbezogene Daten in das elektronische
Dossier dieses Ereignisses mit aufzunehmen. Dies erlaubt es, die Versicherungsbenachrichtigung
zu automatisieren und insbesondere eine zu späte Benachrichtigung, die zur
Ablehnung der Deckung führen
kann, zu verhindern.
-
Die in 11 dargestellte
GUI 94 hat ein Anzeigeelement 92 mit der Bezeichnung
"Versicherungseinschätzung".
Das Anzeigeelement 92 zeigt den über die "Versicherungsarbeit"-GUI,
die unten unter Bezugnahme auf 15 detaillierter
erklärt wird,
eingegebenen Wert an.
-
Die automatische Erzeugung eines
elektronischen Versicherungsberichts erfordert die Eingabe von entsprechenden,
versicherungsbezogenen Daten für
das bestimmte Ereignis, für
welches das elektronische Dossier erzeugt wird. Durch Aktivierung
eines Steuerelements in der Form des "Daten"-Registerblattes, z.B.
von dem in 7 dargestellten
"Allgemein"-GUI 64 aus, wird ein Steuersignal generiert, auf
welches als Reaktion die in 13 dargestellte und
eine Eingabeaufforderung für
versicherungsbezogene Daten umfassende "Daten"-GUI 100 angezeigt
wird.
-
Versicherungsbezogene Daten werden über eine
Vielzahl 102 von Datenfeldern eingegeben, einschließlich eines
Datenfeldes für
das Anfordern des Vorfallsdatums. Das Vorfallsdatum ist das Datum,
an welchem der Vorfall, der Fehler oder die Verletzung stattgefunden
hat, der/die das Ereignis und das damit verbundene Risiko verursacht
hat. Ein weiteres Datenfeld fordert das Entdeckungsdatum des Vorfalls an.
Dieses Datenfeld ist in Verbindung mit dem automatisierten Versicherungsberichten
von großer Wichtigkeit,
weil die Versicherung üblicherweise
innerhalb einer bestimmten Frist nach dem Entdeckungsdatum des Vorfalls
benachrichtigt werden muss. Mittels des automatisierten elektronischen Versicherungsberichts,
der unmittelbar nach dem Erzeugen eines neuen elektronischen Dossiers
eingeleitet wird, kann eine zu späte Benachrichtigung verhindert
werden. Die weiteren Datenfelder 102 der in 13 dargestellten GUI 100 enthalten
ein Datenfeld zur Eingabe des Forderungsdatums (d.h. des Datums,
an welchem eine gegnerische Partei eine formelle Schadensersatzforderung
geltend macht).
-
Die Anwendung ist so konfiguriert,
dass ein Versicherungsbericht für
ein bestimmtes Ereignis automatisch erzeugt wird, wenn das Ereignis,
wie in das elektronische Dossier eingetragen, spezielle Voraussetzungen
erfüllt.
Diese Voraussetzungen können z.B.
enthalten, dass der anfänglich
geforderte Betrag und/oder die erwarteten Kosten höher sind
als ein vordefinierter Betrag und/oder dass das Ereignis eine persönliche Forderung
gegen einen Mitarbeiter des Unternehmens beinhaltet. Wird mindestens
eine dieser Voraussetzungen erfüllt,
wird das Ereignis der Versicherung automatisch auf dem Weg eines
elektronischen Versicherungsberichts mitgeteilt. Dies bedeutet,
dass die das Ereignis abwickelnde Person keine Sorge dafür tragen
muss, ob das Ereignis tatsächlich
durch irgendein Versicherungsprogramm abgedeckt ist.
-
Wenn nach der Bewertung eines elektronischen
Versicherungsberichts die verantwortliche Stelle zu dem Entschluss
kommt, dass das berichtete Ereignis für Versicherungszwecke nicht
relevant ist, wird dieses Ereignis von der Ereignisliste gelöscht, für die später Aktualisierungen
berichtet werden müssen.
In diesem Fall muss die Option "nein" in dem Datenfeld "Versicherungsanspruch"
81 in der in 8 dargestellten
"Spezial"-GUI 80 ausgewählt werden.
Wenn jedoch das Ereignis eine Versicherungsangelegenheit wird, muss
die Option "ja" ausgewählt
werden. In diesem Fall wird regelmäßig eine Aktualisierung der
risikobezogenen Daten zusammen mit dem speziellen Aktualisierungsvorgang
der Risikoberichte angefordert. In einem solchen Fall wird ein aktualisierter
elektronischer Versicherungsbericht basierend auf den während des
Aktualisierens der risikobezogenen Daten eingegebenen Informationen
automatisch erzeugt.
-
In den 14 und 15 werden zwei optionale GUIs 103, 105 gezeigt,
die das Sammeln von versicherungsbezogenen Daten ermöglichen.
Auf die GUIs 103, 105 kann über optionale Registerblätter mit
den Bezeichnungen "Versicherungsarbeit" und "Versicherungsdetails"
zugegriffen werden. Die GUIs 103, 105 enthalten
eine Vielzahl von Datenfeldern zur Eingabe standardisierter und
nicht-standardisierter versicherungsbezogener Informationen. Zum
Beispiel enthält
die GUI 105 ein auf eine Versicherungseinschätzung bezogenes
Datenfeld 107. Die ausgewählte Option wird über das
Anzeigeelement 92 der in 11 dargestellten
GUI 94 angezeigt. Die GUI 105 umfasst weiter ein
Steuerelement 109 in Form eines Hyperlinks zu einer anwendbaren
Versicherungspolice. Da die einzelnen Datenfelder auf den GUIs 103, 105 selbsterklärend sind,
wird hier auf eine detailliertere Beschreibung verzichtet.
-
Wie zuvor bereits erwähnt ist
die Zugriffssteuerung ein wichtiges Merkmal der Erfindung. Ein Aspekt
der Zugriffssteuerung bezieht sich auf die einzelne Definition von
Benutzern, denen der Zugriff auf ein besonderes elektronisches Dossier
erlaubt ist. Zu diesem Zweck wird ein Steuerelement in Form des "Zugriff"-Registerblattes
bereitgestellt, z.B. in der "Allgemein"-GUI 64 von 7. Durch Aktivierung des
"Zugriff"-Registerblattes der "Allgemein"-GUI 64 wird die
in 16 dargestellte GUI 104 angezeigt. Die
GUI 104 fordert zur Eingabe von Zugriffssteuerungsdaten
auf. Die Datenfelder 106 der GUI 104 erlauben
das Erzeugen von Benutzerlisten oder Benutzergruppen, denen das
Lesen (Lesezugriff) und/oder die Modifizierung (Schreibzugriff)
der bestimmten elektronischen Dossiers erlaubt ist. Es gibt zwei
Datenfelder 108, die nicht von der Person, die das elektronische
Dossier erzeugt, modifiziert werden können. Diese Datenfelder 108 sind
als System-"Lesezugriff" und System-"Schreibzugriff' bezeichnet. Die in
den Datenfeldern 108 aufgeführten Benutzer oder Benutzergruppen
haben automatisch Lese- oder Schreibzugriff auf das bestimmte elektronische
Dossier. Die Datenfelder 108 werden zu Informationszwecken
bereitgestellt.
-
Sobald alle relevanten, ein spezielles
Ereignis charakterisierenden Daten in ein neues elektronisches Dossier
oder in ein existierendes elektronisches Dossier aufgenommen oder
aktualisiert worden sind, müssen
die relevanten Daten in einen elektronischen Bericht für dieses
elektronische Dossier aufgenommen werden. Um einen solchen Bericht
zu erzeugen, muss ein Steuerelement in Form eines "Berichte"-Registerblattes der
eingangs in 6 dargestellten
GUI 60 aktiviert werden. In der Ansicht von 6 ist das "Berichte"-Registerblatt
hinter der "Allgemein"-GUI 64 verborgen.
-
Wird das "Berichte"-Registerblatt
aktiviert, wird die in 17 dargestellte
GUI 110 erzeugt. Die in 17 dargestellte
GUI 110 umfasst ein Steuerelement 112 mit der
Bezeichnung "Erzeuge Bericht". Durch Anklicken dieses Steuerelements 112 werden automatisch
alle Informationen, welche für
den Berichtsprozess notwendig sind, in einem (Risiko-) Bericht für ein bestimmtes
neu erzeugtes oder aktualisiertes elektronisches Dossier per einem
bestimmten Datum gespeichert. Ein solcher Bericht kann somit als
eine Momentaufnahme der Informationen eines bestimmten speziellen
elektronischen Dossiers an einem speziellen Datum betrachtet werden.
Bevor der Bericht gesichert und für den Risikoberichtsprozess freigegeben
wird, ist es notwendig, die in dem Bericht enthaltenen Informationen
auf Fehlerfreiheit zu prüfen. Änderungen
können
nicht in dem Bericht selbst gemacht werden, sondern nur in dem elektronischen Dossier über die
entsprechenden Registerblätter
der einzelnen GUIs.
-
Einmal erzeugt werden die Risikoberichte
als HTML-Dokumente in einer geeigneten Datenbank (4) gespeichert. Durch Aktivierung des
Steuerelements 114 mit der Bezeichnung "Ansicht Bericht" der
in 15 dargestellten
GUI 110 kann der Risikobericht eines jeden elektronischen
Dossiers, für
das ein Benutzer Zugriffsrechte hat, von der entsprechenden Datenbank
abgerufen und von einem Browser angezeigt werden.
-
Wenn ein elektronischer Risikobericht
für ein spezielles
elektronisches Dossier gespeichert ist, werden die in dem elektronischen
Dossier enthaltenen Informationen automatisch hinsichtlich der oben erörterten
Kriterien bewertet, um entscheiden zu können, ob oder ob keine elektronische
Versicherungsbenachrichtigung erforderlich ist. Sollte eine elektronische
Versicherungsbenachrichtigung erforderlich sein, wird eine elektronischer
Versicherungsbericht für
das bestimmte elektronische Dossier automatisch erzeugt und über ein
Kommunikationsnetzwerk an die für
die Bearbeitung des elektronischen Versicherungsberichts zuständige Stelle übermittelt.
-
Die in 17 dargestellte
GUI 110 hat eine Vielzahl 116 von weiteren Steuerelementen
(Links), die das Verwalten von Risikoberichten, die Ansicht von
gelöschten
Risikoberichten und die Ansicht von Risikoberichten geordnet nach
"Geschlossen durch Datum", "Geschlossen durch Unternehmensgruppe/Geschäftsbereich",
"Offen Beklagter" oder "Offen Kläger"
erlauben. Außerdem
wird eine Vielzahl 118 von weiteren Steuerelementen bereitgestellt,
die zum Generieren von Steuersignalen aktiviert werden können, welche
die Erzeugung und die Darstellung eines Gruppenrisikoberichts in
Bezug auf alle in einer speziellen Datenbank verfügbaren elektronischen
Dossiers auslösen.
In Folge der Nutzung von standardisierten risikobezogenen Daten
wird die Erzeugung des Gruppenrisikoberichts außerordentlich erleichtert.
Mögliche
Optionen enthalten die Erzeugung und die Anzeige eines Gruppenrisikoberichts
bezogen auf neue elektronische Dossiers, elektronische Dossiers
in Abhängigkeit
von einer materiellen Entwicklung, elektronische Dossiers ohne materielle
Entwicklung und elektronische Dossiers betreffend eine bestimmte
Unternehmensgruppe oder Geschäftsbereich.
-
Zum Beispiel wird durch die Aktivierung
des Steuerelements mit der Bezeichnung "Neu" der Vielzahl 118 von
Steuerelementen ein Steuersignal generiert, welches die Erzeugung
eines elektronischen Risikoberichts betreffend neu erzeugte elektronische Dossiers,
die zum Eintragen in den Gruppenrisikobericht ausgewählt wurden,
veranlasst.
-
In 18 wird
eine GUI 124 in Form eines elektronischen Gruppenrisikoberichts
für neu
erzeugte elektronische Dossiers gezeigt. Wie aus 18 ersichtlich ist, enthält der Gruppenrisikobericht
für jedes
Ereignis, welches Teil des Gruppenrisikoberichts ist, eine Vielzahl
von Daten einschließlich
der Unternehmensgruppe, des Geschäftsbereichs, des Typs, des
Gegenstands, des Verantwortlichen, der mit dem Ereignis verbundenen
Gefahr der Rufschädigung verknüpft usw..
Der in 18 beispielhaft
dargestellte elektronische Risikobericht enthält nur ein einziges Ereignis.
Wenn jedoch eine Vielzahl von Ereignissen mit "GRR neu" klassifiziert
worden wäre,
würde der entsprechende
Gruppenrisikobericht mehrere Ereignisse auflisten.
-
Um einem autorisierten Benutzer das
Erzeugen eines Risikoberichts beinhaltend individuell spezifizierte
Daten zu ermöglichen,
kann sich ein autorisierter Benutzer selbst ein spezielles Berichtsformat durch
Eingabe geeigneter Berichtsformatdaten definieren. 19 zeigt eine entsprechende, zur Eingabe
von Berichtsformatdaten auffordernde GUI 130, die durch
den Berichterzeugungsprozessor während der Erzeugung
eines speziellen elektronischen Risikoberichts verarbeitet werden.
Die GUI 130 ermöglicht
es einem Benutzer, ein Berichtsformat zu erzeugen, indem über eine
Mehrzahl von Datenfeldern 132 die in dem benutzerdefinierten
Risikobericht zu sammelnden Informationen ausgewählt werden.
-
In 20 ist
ein beispielhafter benutzerdefinierter elektronischer Risikobericht
in Form eines von einem auf der Clientkomponente eines Benutzers laufenden
Browser angezeigten HTML-Dokuments dargestellt. Wie aus 20 ersichtlich ist, bezieht sich
der elektronische Risikobericht auf alle neu berichteten Ereignisse,
die einem rechtlichen Risiko unterliegen. Für jedes diese Voraussetzungen
erfüllende
Ereignis wird eine Vielzahl von Informationen wie Hintergrund, Entwicklung,
verantwortlicher Rechtsanwalt usw. berichtet. Für jedes in dem Bericht enthaltene
Ereignis werden relevante Zahlen wie der aktuelle Wert, die erwarteten
Kosten und die Risikorücklage
gezeigt. Optional können
für alle
in dem elektronischen Risikobericht 140 enthaltenen Ereignisse
angesammelte, d.h. akkumulierte Zahlen in den elektronischen Risikobericht 140 aufgenommen werden.
-
Alternative Berichtsformate könnten z.B.
für die
Erzeugung eines elektronischen Risikoberichts, der alle durch einen
bestimmten intern Verantwortlichen oder externen Rechtsanwalt abgewickelten
Ereignisse enthält,
verwendet werden. Solche Risikoberichte helfen z.B. Ereignisse mit
einem höheren
Risiko gleichmäßiger zu
streuen. Im Zusammenhang mit der Erzeugung von Risikoberichten sollte
beachtet werden, dass durch die Implementierung spezieller Replikations-
und Zugriffssteuerungsmechanismen der Inhalt eines von einem speziellen
Benutzer erzeugten Risikoberichts gesteuert werden kann.
-
Die oben beschriebenen Ausführungsformen sollen
als Beispiele für
die vorliegende Erfindung verstanden werden, wobei von Fachleuten Änderungen und
Modifikationen daran vorgenommen werden können, ohne vom Inhalt der Erfindung,
die einzig durch die folgenden Ansprüche definiert ist, abzuweichen.