-
Die Erfindung betrifft ein Videokonferenz-System und ein Verfahren zum Durchführen einer Videokonferenz mit einem derartigen System.
-
Videokonferenz-Systeme sind seit längerem bekannt. Sie dienen zur Kommunikation über große Distanzen, wobei sich die Beteiligten jeweils über einen Teilnehmercomputer (häufig auch Client genannt) austauschen. Hierbei werden generelle Daten sowie Audio- und Video-Ströme ausgetauscht. Generelle Daten sind beispielsweise PowerPoint-Folien oder pdf-Dokumente, die ein Moderator in das System einspielt und welche die übrigen Teilnehmer auf ihrem jeweiligen Computerbildschirm sehen. Audio- und Videoströme (Engl.: Audio-/Video-Streams) können insbesondere die mit entsprechender Kamera und Mikrofon aufgenommenen und zur Übertragung digitalisierten Personenabbilder bzw. deren Gesichter und deren mündliche Beiträge sein.
-
Bisher ist jedoch kein Videokonferenz-System bekannt geworden, welche alle Bedürfnisse der Nutzer befriedigt. Es ist daher die Aufgabe der vorliegenden Erfindung, ein komfortables, flexibles und vertrauenswürdiges Videokonferenz-System zur Verfügung zu stellen.
-
Diese Aufgabe wird durch die Merkmale des Anspruchs 1 gelöst.
-
Die Vorteile der Erfindung sind insbesondere darin zu sehen, dass das erfindungsgemäße Videokonferenz-System es erstmalig erlaubt, ein vollständiges Protokoll bzw. Protokolldokument mit allen relevanten Informationen, d. h. der oder den gezeigten Präsentationen, ggf. den Audio- und Videoströmen der Konferenzteilnehmer, den Zeitstempeln zu den verschiedenen Ereignissen der Videokonferenz, den Notizen bzw. Anmerkungen der Teilnehmer usw., zu erstellen sowie eine Authentifizierung zumindest einiger der Teilnehmer bereit zu stellen, insbesondere eine digitale Signierung des Protokolldokuments. Die zentrale Steuerung der dem Videokonferenz-System zugrunde liegenden Befehle wird hierbei durch den Zentralserver, auch CORE-Server genannt, vorgenommen. Der Konferenzserver ist dazu ausgebildet, die Audio-/Videoströme (A/V-Ströme) des Moderators und der übrigen Teilnehmercomputer zu empfangen, aufzubereiten und weiterzuleiten. Zum Empfangen, ggf. Aufbereiten (falls notwendig oder gewünscht) und Weiterleiten von generellen Daten, beispielsweise PowerPoint-Präsentationen eines Vortragenden, Bildern oder pdf-Dokumenten, ist der Datenserver vorgesehen. Das Authentifizierungsmodul, das vorzugsweise ein Signaturmodul umfasst, ist derart ausgebildet, dass es Authentifizierungsinformationen von bestimmten oder allen Teilnehmern anfordert und diese empfängt. Der Moderator der Videokonferenz kann beispielsweise festlegen, von welchem Teilnehmer eine Authentifizierung verlangt wird.
-
Wenn im Rahmen dieser Anmeldung von Daten bzw. generellen Daten die Rede ist, werden hierunter insbesondere pdf-Dokumente, Bilder, Präsentationen, benutzerbezogene Informationen etc. verstanden. Unter Audio/Video-Strömen (A/V-Ströme) werden die digitalisierten und zumeist kontinuierlichen Audio-/Video(daten)ströme verstanden, die durch Audio- und/oder Video-Aufnahmen erhalten werden.
-
Im Rahmen dieser Anmeldung wird unter den Begriffen Zentralserver, Konferenzserver, Datenserver, Authentifizierungsmodul, Signaturmodul, Anmerkungssystem, Protokollserver und Zertifizierungsserver (s. zum Teil weiter unten) jeweils als Software realisierter Programmcode verstanden.
-
Das erfindungsgemäße System umfasst zudem ein Anmerkungssystem, das mit einer Datenbank zusammenarbeitet und Anmerkungen der Teilnehmer entgegennimmt, verwaltet und speichert. Solche Anmerkungen können insbesondere Verpflichtungen(„Commitments”) sein, die ein Teilnehmer während der Videokonferenz übernimmt und die im Protokoll festgehalten werden. Die Datenbank für das Anmerkungssystem ist vorzugsweise in dem Zentralserver, dem Authentifizierungsmodul oder dem Protokollserver integriert.
-
Die Erstellung dieses elektronischen Protokolls übernimmt ein Protokollserver, der die Daten und A/V-Ströme einschließlich der jeweils dazugehörigen Zeitstempel sowie der genannten Anmerkungen in ein Dokument einbaut. Als Dateiformat bietet sich beispielsweise das pdf-Format an. Das Protokoll kann dann elektronisch, z. B. via E-Mail versandt und/oder ausgedruckt werden. Es enthält vorzugsweise auch Informationen zur erwähnten Authentifizierung. Ein Fall einer Authentifizierung ist hierbei eine Signierung des Protokolls, beispielsweise und/oder vorteilhafterweise unter Verwendung von weiteren Elementen, die insbesondere eine Rechtsverbindlichkeit garantieren können. Vorteilhafterweise lässt sich das Protokoll sowohl online als auch offline zur Videokonferenz signieren.
-
Das Protokoll fasst vorteilhafterweise alle Ereignisse einer Videokonferenz zusammen, wie beispielsweise Start der Sitzung, Zeitpunkte des Hinzukommens der Teilnehmer, Teilnehmeraktionen wie Wortbeiträge und schriftliche Anmerkungen. Diese Ereignisse und Daten werden in einer Datenbank gespeichert, so dass am Protokollserver ein Informationsabbild der Videokonferenz entsteht. Ein Protokoll im beispielsweise pdf-Format, ggf. mit Filterung von momentan nicht interessierenden Daten, Beiträgen usw., kann jederzeit aus dieser Datenbank erstellt werden.
-
Vorzugsweise wird das Protokoll automatisch im Hintergrund erstellt, d. h. ohne dass eine Aktion des Moderators oder der Teilnehmer nötig wäre. Es ergibt sich demnach eine Zeit- und Ressourcenersparnis. Auch ist die Fehleranfälligkeit wesentlich geringer.
-
Das Protokoll kann hierbei vorteilhafterweise eine wie folgt aufgebaute Grundstruktur aufweisen:
- – Seite 1: Deckblatt mit den Informationen „Datum” und „Moderator”;
- – Seiten 2 – N: Folienblätter mit den Informationen „Folienbild” bzw. auch kombiniert mit Videobildern, „Foliennummer”, „Folientitel”, „Präsentationsdauer für diese Folie” sowie „Anmerkungen/Kommentare von Teilnehmern”;
- – Seiten N + 1: Teilnehmerblatt mit den Informationen „Teilnehmer” und „Dauer der Anwesenheit”.
-
Der Moderator der Videokonferenz kann beispielsweise noch einen Titel der Videokonferenz eingeben und/oder Titel für die einzelnen Folien vergeben.
-
Während der Videokonferenz kann auch ein Wechsel des Vortragenden stattfinden, wobei dann auch dessen Folien in das Protokoll eingebunden werden.
-
Damit das automatische Prinzip nicht zu schnell neue Seiten mit Folien und dadurch möglicherweise nicht notwendige Seiten generiert, ist vorteilhafterweise ein Mechanismus eingebaut, welcher eine neue automatische Seite erst nach dem Zeigen von beispielsweise 30 Sekunden als gültige Folie bzw. neue Folie identifiziert. Durch diese Maßnahme wird das Protokollieren von digitalen Folien vermieden, die schnell vor und zurück „geblättert” werden.
-
Nach dem Meeting wird das automatisch generierte Protokoll mit vorzugsweise folgenden Inhalten an vorteilhafterweise alle Teilnehmer verteilt:
- – Moderator, Datum und Länge;
- – Folie, Vortragender, Zeitpunkt und Länge, Chatbeitrag, Videoschnappschüsse;
- – Teilnehmerliste und Anwesenheitsliste;
- – Optional mit Eingabe durch beispielsweise den Moderator: Titel und Untertitel.
-
Das erfindungsgemäße Videokonferenz-System unterstützt entsprechend dem Vorgesagten vorzugsweise folgende Aktionen:
- – Speichern der Folien bzw. Screenshots mit Vortragendem und Zeitstempel;
- – Berechnen der Anwesenheiten der Teilnehmer anhand derer Ein/Auslog-Zeiten;
- – Speichern der Teilnehmer und deren Anwesenheitsdaten;
- – Speichern der Chat-Informationen;
- – PDF Generierung.
-
Des Weiteren ist mit dem Protokollserver vorteilhafterweise ein Mailservice verbunden, der die Verteilung des Protokolls an die Teilnehmer übernimmt. Auch ist es vorteilhaft, wenn der Protokollserver einen Link für das pdf-Dokument generiert, damit z. B. Webteilnehmer (d. h. keine aktiven Konferenzteilnehmer) sich das pdf-Dokument, wenn es denn freigegeben ist, ansehen können.
-
Gemäß einer vorteilhaften Weiterbildung der Erfindung kann der Moderator dem Protokoll eine Verpflichtung („Commitment”) für einen oder mehrere Teilnehmer hinzufügen. Eine solche Verpflichtung wird vorzugsweise mittels des Anmerkungssystems erstellt (s. o.). Der Verpflichtung kann beim Anlegen eine laufende Nummer zugeordnet werden; dann fügt der Moderator zweckmäßigerweise einen Text, den oder die Teilnehmernamen, für den bzw. die die Verpflichtung gilt, und/oder einen Termin zur Erfüllung der Verpflichtung hinzu. Der Moderator verschickt vorteilhafterweise die Verpflichtung dem oder den Teilnehmern mit der Möglichkeit, dass diese/r die Verpflichtung annimmt oder ablehnt. Bei einer Ablehnung kann der Moderator die im Protokoll aufgenommen Verpflichtung vorzugsweise wieder löschen. Vorteilhafterweise wird jede Verpflichtung in der dem Protokollserver zugeordneten Datenbank einem Zeitpunkt und somit einer zu diesem Zeitpunkt der Videokonferenz gehörigen Folie zugeordnet.
-
Das Protokoll kann vorzugsweise derart erstellt werden, dass es individualisiert für die Teilnehmer angezeigt wird. Beispielsweise zeigt ein Protokoll für einen Teilnehmer, der eine Verpflichtung übernommen hat, diese Verpflichtung an, während das Protokoll für einen anderen Teilnehmer, der nichts mit dieser Verpflichtung zu tun hat, diese Verpflichtung nicht ausweist. Mit anderen Worten kann das Informationsabbild alle Informationen einschließlich aller Verpflichtungen enthalten, während das den Teilnehmern vorgelegte bzw. übermittelte Protokoll gefiltert sein kann.
-
Eine Weiterbildung der Erfindung sieht vor, dass – beispielsweise auf Basis des zuvor beschriebenen Verpflichtungssystems aber auch unabhängig davon – eine rechtsgültige Unterschrift in das erstellte Protokoll eingebaut wird. Hierzu ist das Authentifizierungsmodul vorgesehen, welches vorteilhafterweise in dem Zentralserver, dem Konferenzserver, dem Protokollserver oder in einem externen Zertifizierungsserver vorgesehen sein kann.
-
Für eine digitale Signierung, welche im Sinne dieser Erfindung ein Beispiel einer Authentifizierung darstellt oder ein Teil eines mehrere Schritte umfassenden Authentifizierungsprozesses ist, wird das Protokoll vorzugsweise zunächst an alle Teilnehmer verteilt. Wenn Einvernehmen zwischen dem Moderator und den (betreffenden) Teilnehmern herrscht, kann gemäß der Weiterbildung der Erfindung der Moderator einen Unterschriftenprozess starten, d. h. die Umsetzung einer digitalen Signatur auf das vorliegende Protokoll. Für die digitalen Signaturen müssen vorzugsweise alle Teilnehmer ausgehend vom Moderator den Signaturprozess durchlaufen. Dabei wird beispielsweise das Protokoll als PDF über den Protokollserver mit der Unterschriftskennung desjenigen, der die Unterschrift leisten möchte, übermittelt. Als Bestätigung erhält beispielsweise das Mobiltelefon des betreffenden Teilnehmers eine SMS mit einem Code als Signaturbestätigung, die der Teilnehmer in sein Mobiltelefon eingibt und zu einem Signaturserver übermittelt. Hierdurch wird die Unterschrift dieser Person legal bestätigt, woraufhin der nächste Teilnehmer unterzeichnen kann. Für die Verschlüsselung können bekannte ID-Karten verwendet werden, die beispielsweise von akkreditierten Trustcentern, die externe Zertifizierungsserver unterhalten, ausgegeben werden. Die digitalen Signaturen bzw. eine Gesamtsignatur, welche als Bestätigung aller einzelnen digitalen Signaturen gilt, wird schließlich dem Protokoll hinzugefügt und auf einem Extrablatt hinten angehängt, wobei somit das Protokolldokument zusätzlich zu den oben genannten Seiten 1 bis N + 1 noch folgende Blätter beinhalten kann:
- – Seiten N + 2: Verpflichtungsblatt mit Informationen „Verpflichtungsnummer”, „Teilnehmer”, „Status” und „Folie”;
- – Seite N + 3: Signaturblatt mit digitalen Signaturen.
-
Mit dem digital signierten Protokoll können in Videokonferenzen verbindlich Verträge verhandelt, Sachbestände beschlossen, nächste Schritte definiert oder Budgets vergeben werden. Vorteilhafterweise haben dabei alle beteiligten Teilnehmer vorab in der Registrierung im Videokonferenz-System die Erlaubnis erteilt, dass sie in den digitalen Signaturprozess eingebunden werden können. Durch diese Erlaubnis wird auch die Mobilnummer gespeichert, damit der Signaturbestätigungscode im Signaturprozess per SMS an das Mobiltelefon des betreffenden Teilnehmers übermittelt werden kann.
-
Vor Unterzeichnung des Protokolls oder sogar vor Erstellung des Protokolls, beispielsweise im pdf-Format, könnte das Informationsabbild des Protokollservers an den Bildschirmen der Teilnehmercomputer erscheinen, so dass noch eine gemeinsame Durchsicht und ggf. Korrektur bzw. Ergänzung, vorzugsweise initiiert vom Moderator, erfolgen kann.
-
Das Protokoll kann vorteilhafterweise durch Videoinformationen ergänzt werden. Als Input dient hierbei vorzugsweise der Videostrom einzelner Teilnehmer und/oder des Vortragenden. Aus dem Videostrom können zu gewissen Zeitpunkten Screenshots bzw. Miniaturansichten („Thumbnails”), beispielsweise des Gesichts des Vortragenden, erzeugt werden, welche mit Zeitstempel in der Datenbank – zufällig oder nach einem bestimmten Algorithmus – einer Folie des Vortragenden zugeordnet werden. Hierdurch ergibt sich ein besserer Überblick über das Protokoll.
-
Eine diesbezügliche Möglichkeit sieht vor, nach einem verifizierten Folienwechsel (nach beispielsweise 30 Sekunden) im 10-Sekunden-Takt einige Schnappschüsse des Vortragenden zu machen und auf dem Folienblatt sichtbar anzuhängen. Im Fall einer digitalen Podiumsdiskussion könnten alle Podiumsmitglieder aufgenommen werden. In diesem Fall könnte das Podiumsmitglied kurz nach dem Hinzukommen sowie gleichzeitig der Vortragende aufgenommen werden. Alle Podiumsmitglieder könnten dann gemeinsam auf den Bildschirmen der Teilnehmercomputer dargestellt werden. Auch kann die Möglichkeit vorgesehen sein, den Podiumssprecher dynamisch aufzunehmen und Zeitstempel einzubauen. Somit wären beispielsweise folgende Informationen im Protokoll verzeichnet:
- – Verifizierter Folienwechsel (nach beispielsweise 30 Sekunden);
- – Schnappschuss vom Vortragenden;
- – Schnappschuss vom Vortragenden wiederholt nach x Sekunden (bis zu einer maximalen Anzahl z);
- – Wechsel zu einem Podium, wenn vorhanden;
- – Merken der Podiumsmitglieder und deren Dauer im Podium;
- – Schnappschuss der Podiumsmitglieder bei Hinzukommen zum Podium (nach y Sekunden) mit gleichzeitigem Schnappschuss des Vortragenden.
-
Die genannten Videoinformationen ermöglichen demnach eine entsprechende Erweiterung des automatisch erstellten Protokolls.
-
Eine andere Weiterbildung der Erfindung sieht die Aufnahme von Videos während einer Videokonferenz vor, welche durch definierte Ereignisse in kleinere Videoszenen geschnitten und einer Folie zugeordnet werden können. Diese Videoszenen können mit allen Daten aus der vorgenannten Datenbank gekoppelt werden. Dazu wird das Protokoll beispielsweise als Webseite generiert, wobei jeder Folie ein zugehöriges Kurzvideo bzw. einen Ausschnitt aus dem Gesamtvideo zugeordnet werden kann. Auf diese Weise ist es z. B. möglich, auf einfache Weise zu speziellen Stellen des Protokolldokuments zu springen und sich das entsprechend zugeordnete bzw. eingebundene Video anzusehen. Es ist vorteilhafterweise ebenfalls vorgesehen, die Videosequenzen bzw. das gesamte Video auch vom Protokoll getrennt verwenden zu können.
-
Die beschriebene Videoausführung ergibt den Vorteil, dass die Besprechung bzw. Konferenz insgesamt in einem Video aufgenommen werden kann. Um Speicherplatz zu sparen, kann man die Kurzvideos, welche einer Folie zugeordnet wurden, auf ein Internet-Videoportal wie beispielsweise YouTube oder andere Streaming-Plattformen hochladen.
-
Das erfindungsgemäße Videokonferenz-System umfasst vorzugsweise einen Übertragungsserver (Broadcastserver), der mit dem Konferenzserver verbunden ist. Dieser Übertragungsserver ist vorzugsweise derart eingerichtet, dass er vom Konferenzserver empfangene Audio-/Video-Datenströme in Form von A/V-Strömen an die Teilnehmercomputer und zudem vorzugsweise über das Internet an nicht aktiv an der Konferenz teilnehmende Internetnutzer (im Folgenden auch Webteilnehmer genannt) zu übertragen vermag. Alternativ übernimmt der Übertragungsserver lediglich die Übertragung der A/V-Ströme an die Webteilnehmer, während die A/V-Ströme an die Konferenzteilnehmer separat, veranlasst vom Konferenzserver, übermittelt werden.
-
Für die Übertragung von Daten (PowerPoint-Präsentationen, pdf-Dokumente, etc.) ist vorzugsweise der oben genannte Datenserver zuständig, der hierzu derart eingerichtet, dass er mit dem Teilnehmercomputer des Moderators bzw. Vortragenden verbunden ist und von diesem Teilnehmercomputer empfangene Daten in Form von entsprechenden Datenströmen über das Internet ebenfalls an Internetnutzer zu übertragen vermag.
-
Der Datenserver, der Übertragungsserver, der Konferenzserver, das Signaturmodul und/oder der Protokollserver können zum Teil oder allesamt als dezentralisierte Speicherprogramme im Internet (in der sog. Cloud) oder auf fest installierten Hardware-Servern installiert sein. Die erstgenannte Maßnahme reduziert den finanziellen und technischen Aufwand und erlaubt eine einfache Handhabung. Wichtig ist die Erreichbarkeit dieser Server über das Internet von allen Orten.
-
Um ein Protokoll erzeugen zu können, müssen auf einem Hardware-Server Ereignisse (z. B. „nächste Folie”) und Daten, die durch Interaktion der Teilnehmer einschließlich des Moderators während einer Videokonferenz erzeugt bzw. eingespeist werden (z. B. Präsentationen), gespeichert werden. Diese Ereignisse und Daten spiegeln den zeitlichen Idealzustand einer Datenverteilung wieder, welcher jedoch in Realität durch Verteilungsverzögerungen nicht eingehalten werden kann. Insbesondere sind häufig Audio-/Videodatenströme mit der Verteilung der (generellen) Daten nicht synchron, sondern manchmal schneller, manchmal langsamer. Dieses Problem tritt insbesondere dann auf, wenn es eine Vielzahl von Teilnehmern gibt. Nicht nur kann hierdurch der Vortragende irritiert werden; auch ist eine realitätsgetreue Aufzeichnung des Protokolls beeinträchtigt. Somit verursacht diese Echtzeitproblematik einen entsprechenden durch Software zu realisierenden Synchronisationsbedarf insbesondere in den folgenden Punkten:
- – Synchronisation Audio/Video: Sprache folgt dem Videobild des Sprechenden;
- – Synchronisation Audio/Daten: Daten folgen dem Sprechenden bzw. der Sprechende folgt den Daten.
-
Um die Synchronität zu garantieren, wird gemäß einer Weiterbildung der Erfindung mittels eines Feedbackprotokolls die Systemdatenverteilungsverzögerung („System Data Distribution Delay”, SDDD) bestimmt und diese dann – mittels eines oder mehrerer der beschriebenen, durch Software realisierten Server – durch Synchronisation beseitigt. Bei dem Zeitverhalten gibt es grundsätzlich zwei Schritte, welche das Gesamtsystemverhalten beeinflussen:
- – Verarbeitungszeit („Processing Time”), d. h. die Zeit zwischen dem vom Moderator gesetzten Ereignis (z. B. Zeigen einer neuen Folie oder Ausgabe einer neuen Verpflichtung) und dem Abschluss der dadurch am Hardware-Server entstandenen Prozesse. Diese Zeitspanne wird hauptsächlich durch den Prozess am Server bestimmt und hängt somit auch direkt von der Prozessorkapazität des Servers ab.
- – Verteilungszeit („Distribution Time”), d. h. die Zeit des Verteilens aller Ereignisse und Daten vom Hardware-Server zu allen Teilnehmern bzw. der Rückübermittlung der Antworten zum Moderator. Diese Zeitspanne hängt hauptsächlich von der Anzahl der Teilnehmer ab sowie von der dem Server zur Verfügung stehenden Bandbreite sowie der den Teilnehmern zur Verfügung stehenden Bandbreite.
-
Die gesamte Reaktionszeit der Echtzeitdatenverteilung ergibt sich somit zu: Verzögerung der Systemdatenverteilungsverzögerung (SDDD)
= Verarbeitungszeit + Verteilungszeit
= f (Serverbandbreite, CPU des Servers, Teilnehmerzahl, Teilnehmer-Bandbreite, Datenmenge)
-
Sobald das SDDD in Bereiche von mehreren Sekunden kommt, entspricht das Gesamtsystemverhalten für den Moderator wahrnehmbar nicht mehr den Echtzeitaspekten der in dem Protokoll aufgezeichneten Daten und Ereignissen. Um diesen Effekt in den Griff zu bekommen, sind verschiedene Algorithmen einsetzbar:
- – Reduzieren der Daten (wenn möglich): Im Falle eines Bildes könnten mehrere JPG-Qualitäten angeboten werden, wodurch das SDDD proportional sinken würde. Auch sind Kompressionsprotokolle für jegliche Datentypen einsetzbar. Es ist hierdurch eine Leistungssteigerung um den Faktor 2–3 realisierbar. Mit der Reduktion der Daten (im Falle des Beispiels der Präsentationsbilder) ist es möglich, bei sehr vielen Zusehern bzw. Webteilnehmern (beispielsweise 1.000–1.250 im Internet) im Bereich eines noch tolerablen 2–3 Sekundenintervalls zu bleiben, in dem also keine wirkliche Verzögerung zwischen Vortrag und Wechsel der Präsentation bemerkt wird. Eine übermäßige Datenreduktion kann durch Bandbreitenerhöhung vermieden werden, beispielsweise durch Parallelisierung des Servers.
- – Feedbackprotokolle für den Vortragenden: Der Vortragende kann hierbei sehen, wie viel Prozent aller Zuseher bereits die verteilten Daten empfangen haben. Er kann dann seinen Vortrag entsprechend anpassen und beispielsweise warten, bis alle Teilnehmer die Daten empfangen haben. Zusammen mit der genannten Datenreduktion ist eine Leistungssteigerung um einen Faktor 5 möglich. Durch das Feedbackprotokoll wird dem Vortragenden im Weiteren bewusst, dass seine Präsentation gerade im Zustand des Verteilens ist. Somit hat er die Möglichkeit, eine kurze Pause einzulegen. Dabei sollte eine Wartezeit von 6 Sekunden realisierbar sein, welche somit eine Verteilung der Daten an beispielsweise 2.000–2.500 Zuseher bzw. Webteilnehmer ermöglicht.
-
Das Feedbackprotokoll könnte in einer Anzeige von 0–100% bestehen, welche darstellt, wie viele Zuseher die Daten bereits vollständig empfangen haben. Diese Methode erlaubt ebenfalls das notwendige Feedback, ob alle Zuseher auf dem gleichen Informationsstand sind bzw. welche Zuseher möglichweise durch Bandbreitenprobleme nicht auf dem gleichen Informationstand sind.
- – Parallelisieren auf mehreren Hardware-Servern: Im Cloud Processing können mehrere Images hochgefahren werden, wodurch die Gesamtbandbreite steigt und das SDDD sinkt. Zwar ist die Verzögerung („Delay”) des Hochfahrens eines Cloud Images zu berücksichtigen, aber das Hochfahren ist demgegenüber nahezu beliebig häufig parallel durchführbar. Somit können ein Vielfaches von 2.500 Zusehern bzw. Webteilnehmern mit Daten unter den Aspekten der Echtzeitbedingungen bedient werden.
-
Das SDDD kann somit durch technische Lösungen, kombiniert mit Feedbackfunktionen, optimiert werden und für das Protokoll als Echtzeitbedingung miteingebaut werden. Es kann zudem eine Statistik des SDDD verwendet werden, um den Beweis der Datenverteilung festzuhalten. Auch könnten Verletzungen der Echtzeitbedingung – d. h. einer Überschreitung der Verteilung innerhalb von ca. 6 Sekunden bei Bildern – in einem Protokollanhang oder Spezialprotokoll festgehalten werden und für Auswertungen oder Irrtümer herangezogen werden.
-
Analog zu den Bilddaten (welche für den Echtzeitgebrauch die größte Datenmenge darstellen) können nach diesem Schema auch andere Daten verteilt werden. Dies inkludiert vor allem Texte, Chat, Systeminformationen, Netzwerkinformationen, Userinformationen, u. v. m.
-
Komplizierter wird das System, wenn das SDDD durch eine Interaktion (im Folgenden auch Userinteraktion genannt) von Teilnehmern (Usern), d. h. Konferenzteilnehmern und/oder Webteilnehmern, beeinflusst wird. Die Systemdatenverteilungsverzögerung wird dann zur Userdatenverteilungsverzögerung („User Data Distribution Delay”, UDDD). Dabei ändert sich die oben genannte SDDD-Formel um den Parameter „Userinteraktionszeit”: User Data Distribution Delay (UDDD)
= Verarbeitungszeit + Verteilungszeit + Userinteraktionszeit
= f (Serverbandbreite, CPU des Servers, Teilnehmerzahl, Teilnehmer-Bandbreite, Datenmenge, Userinteraktionszeit)
-
Die beiden ersten Summanden (Verarbeitung und Verteilung) des UDDD können wie das SDDD zuvor behandelt werden. Dabei erhält der Vortragende vorzugsweise die Information, wie viele Prozent der Zuseher bereits seine Daten empfangen haben. Beispielsweise könnte dies über eine Frage-Antwort-XML-Datei realisiert werden. Der dritte Summand (Userinteraktion) ist an sich unbestimmt, kann jedoch im Sinne eines definierten Echtzeitverhaltens festgelegt werden. Dazu setzt der Vortragende eine limitierte Zeitspanne mit einer Obergrenze, welche vom System vorgegeben wird. Somit hat der Vortragende Zeit, den Zusehern bzw. Webteilnehmern noch Erklärungen zu geben, und die Zuseher haben Zeit, auf die angeforderte Interaktion (Userinteraktion) zu reagieren. Falls die Zeitspanne abläuft, empfängt der Vortragende die Liste aller User, welche keine Interaktion durchgeführt haben.
-
Dieser Prozess kann vor allem für Fragen und Antworten, Verpflichtungen („Commitments”) (s. o.) und Signaturen (s. o.) genutzt werden. Wichtig dabei ist, dass der Vortragende die Information erhält, wann alle Zuseher ihrerseits die Daten erhalten haben. Dadurch wird der Vortragende in die Lage versetzt, präzise zu einer Userinteraktion aufzufordern. Außerdem sieht er, wie lange eine Interaktion möglich ist.
-
Eine weitere Ausbildung der Erfindung hat die oben schon angesprochene Synchronisation der Audio-, Video- und übrigen Datenströme (z. B. Power-Point-Präsentationen) zum Inhalt. Hierzu werden diese Datenströme (Audio, Video, generelle Daten) mit Hilfe von Datenreduktionen, Feedbackprotokollen und/oder Bandbreitenadaptierungsalgorithmen miteinander synchronisiert, wie anhand der Figuren weiter unten erläutert wird. Zum synchronen Empfang auf Seiten der Teilnehmercomputer ist es beispielsweise bevorzugt, die Downloadzeiten der Daten vom Datenserver und/oder die Übertragung der A/V-Ströme zu regeln.
-
Vorzugsweise wird die oben beschriebene Synchronisation im Protokollserver mit Hilfe von Synchronisationsprotokollen realisiert.
-
Die Erfindung betrifft ebenfalls ein Verfahren zum Durchführen einer Videokonferenz, wobei hierzu das erfindungsgemäße Videokonferenzsystem verwendet wird.
-
Vorteilhafte Weiterbildungen der Erfindung sind durch die Merkmale der Unteransprüche gekennzeichnet.
-
Im Folgenden wird die Erfindung anhand von Figuren näher erläutert. Es zeigen:
-
1 ein Blockdiagramm des erfindungsgemäßen Systems;
-
2 eine Übersicht über wesentliche Neuerungen des Systems;
-
3 die Verteilung von Daten (Ereignissen);
-
4 eine alternative zeitliche Darstellung zu der 3;
-
5 die auftretenden Zeitverzögerungen bei der Verteilung von Daten und A-/V-Strömen;
-
6 ein Blockdiagramm zur 5, und
-
7 die Protokollerstellung mit synchroner Datenverteilung.
-
In der 1 ist das erfindungsgemäße Videokonferenz-System in Form eines Blockdiagramms dargestellt. Entsprechend der 1 ist ein das gesamte System steuernder Zentralserver 1 dargestellt, der mit den wesentlichen, nachfolgend genauer erläuterten Systemeinrichtungen verbunden ist. Ein Computer 20a eines Moderators und/oder Vortragenden ist einerseits mit einem Konferenzserver 3 verbunden, der digitalisierte Audio- und Video-Ströme (A/V-Ströme) empfangen, ggf. (falls notwendig oder gewünscht) aufbereiten und übertragen kann. Der Konferenzserver 3 ist ebenfalls mit einer Mehrzahl von Teilnehmercomputern 20b (Clients) von Teilnehmern einer Videokonferenz verbunden. Sowohl der Teilnehmercomputer 20a des Moderators bzw. Vortragenden als auch die übrigen Teilnehmercomputer 20b können sowohl A/V-Ströme vom Konferenzserver 3 empfangen als auch entsprechende A/V-Ströme an diesen übermitteln.
-
Im Konferenzserver 3 ist eine Transcoding-Funktionalität (direkte digital-zu-digital Konversion von A/V-Strömen) implementiert, mit deren Hilfe verschiedenste Endgeräte die so konvertierten A/V-Ströme empfangen können, so z. B. unterschiedlichste Smartphones, Laptops, Tablets, PCs etc.
-
Der Teilnehmercomputer 20a des Moderators bzw. Vortragenden ist andererseits mit einem Datenserver 5 verbunden, der (generelle) Daten (beispielsweise eine PowerPoint-Präsentation oder eine pdf-Datei) des Moderators bzw. Vortragenden empfängt, verarbeitet und an die Teilnehmercomputer 20b der Konferenzteilnehmer weiterverteilt.
-
Zudem ist gemäß der 1 ein Broadcastserver 13 vorgesehen, der die transkodierten A/V-Ströme vom Konferenzserver 3 empfängt und an Computer 22 von Webteilnehmern, d. h. über das Internet verbundene Teilnehmer, die keine aktiven Konferenzteilnehmer sind, überträgt. Die Teilnehmercomputer 22 der Webteilnehmer können zudem entsprechend der 1 vom Datenserver 5 die entsprechenden Daten (beispielsweise PowerPoint-Präsentationen) erhalten.
-
Ein Protokollserver 11 als Teil der Erfindung empfängt vom Teilnehmercomputer 22a des Moderators bzw. Vortragenden die A/V-Ströme und die generellen Daten (z. B. einen PowerPoint-Vortrag). Außerdem werden vorliegend die Informationen des Transcodings vom Konferenzserver 3 und die Daten des Datenservers 5 an den Protokollserver 11 übermittelt. Zudem ist der Protokollserver 11 mit den Computern 20a, 20b bzw. 22 der Konferenzteilnehmer und der Webteilnehmer verbunden. Zudem existiert eine Verbindung zu einem Authentifizierungsserver 7 (Genaueres hierzu weiter unten).
-
Der Protokollserver 11 ist derart ausgelegt und eingerichtet, dass er ein elektronisches Dokument, vorzugsweise ein Protokoll der Videokonferenz, anhand der Daten und vorzugsweise einschließlich der Audio- und/oder Video-Ströme erstellt. Das Dateiformat dieses Protokolls ist beispielsweise das bekannte pdf-Format. Hierzu verarbeitet der Protokollserver 11 die empfangenen A/V-Ströme und Daten der Computer 20a des Moderators bzw. Vortragenden, der Computer 22b der Konferenzteilnehmer, der Computer 22 der Webteilnehmer, des Konferenzservers 3 und/oder des Datenservers 5.
-
Verbindungen vom und zum Protokollserver 11 sind vorliegend bidirektional ausgebildet, so dass der Protokollserver 11 nicht nur die verschiedenen A/V-Ströme und Daten empfängt, sondern solche z. B. auch anfordern kann.
-
Entsprechend der 1 ist ein Authentifizierungsmodul 7 vorgesehen, das mit dem Computer 20a des Moderators bzw. Vortragenden, dem Protokollserver 11 und den Computern 20b der übrigen Konferenzteilnehmer bidirektional verbunden ist. Der Moderator kann beispielsweise vom Authentifizierungsmodul 7 eine Unterschrift einiger oder aller Konferenzteilnehmer unter das Protokoll anfordern. Das Authentifizierungsmodul 7 kommuniziert entsprechend mit den Computern 22b Konferenzteilnehmern, wobei am Ende des Authentifizierungsprozesses (s. u.) die Konferenzteilnehmer das Protokoll signieren, was vom Protokollserver 11 auf dem Protokoll vermerkt wird.
-
Der Konferenzserver 3, der Datenserver 5, der Protokollserver 11 sowie der Broadcastserver 13 können einzeln, zu mehreren oder alle in der sog. Cloud implementiert sein, wie in 1 angedeutet.
-
In der 2 sind der Einfachheit halber der Zentralserver 1, der Konferenzserver 3, der Datenserver 5 sowie der Broadcastserver 13 zusammengefasst dargestellt. Entsprechend der 1 kommuniziert in der gezeigten Ausführungsform der Konferenzserver 3 bidirektional mit den Konferenzteilnehmern, deren Computer 22a, 22b hierfür über geeignete Schnittstellen verfügen. Eine unidirektionale Verbindung besteht vorliegend zwischen dem Datenserver 5 und den Konferenzteilnehmern.
-
Die 2 zeigt insbesondere ein Authentifizierungsmodul 7, das mit dem Protokollserver 5 verbunden ist (kann auch in diesen integriert sein) und von diesem das Protokoll, das vorliegend ein pdf-Dokument ist, erhält. Das Authentifizierungsmodul 7 ist zudem mit den Computern 22a, 22b der Konferenzteilnehmer verbunden und kann von diesen Authentifizierungsinformationen anfordern. Eine Authentifizierung kann hierbei derart erfolgen, dass das pdf-Protokoll vom Protokollserver 11 an die Konferenzteilnehmer 22a, 22b versandt wird und die Teilnehmer eine Teilnehmer-individuelle Mitteilung an den Authentifizierungsserver 7 schicken und hierin beispielsweise mitteilen, dass sie mit dem Protokoll einverstanden sind.
-
Das Authentifizierungsmodul 7 kann beispielsweise in dem Zentralserver 1, dem Konferenzserver 3, dem Datenserver 5 oder dem Protokollserver 11 integriert sein. In 2 ist das Authentifizierungsmodul 7 jedoch separat dargestellt. Gemäß einer Ausführungsform der Erfindung übermittelt es beispielsweise eine entsprechende Anforderung an einen zu authentifizierenden Teilnehmer, beispielsweise eine SMS, auf die der Teilnehmer mit einem ihm spezifischen Code antworten muss. Das Authentifizierungsmodul 7 erkennt den Code und kann dann dessen Unterschrift auf dem pdf-Dokument veranlassen bzw. freigeben bzw. bestätigen. Um eine höhere oder rechtlich verbindliche Unterschrift zu gewährleisten, kann der Authentifizierungsserver 7 auch mit einem externen und in 2 ebenfalls dargestellten Zertifizierungsserver 15 kommunizieren, deren Funktionsweise allgemein bekannt ist, beispielsweise von Banktransaktionsgeschäften.
-
Die Protokolle werden vom Protokollserver 11 sowohl durch von Teilnehmern ausgelöste als auch automatische Ereignisse erstellt. Dabei werden alle Daten und Ereignisse in einer Datenbank 12 auf einem Server, beispielsweise dem Protokollserver 11 (s. 1), gespeichert. Wichtig beim Speichern der Ereignisse ist u. a. der Echtzeitaspekt, welcher die Synchronität der Inhalte garantiert.
-
Bei der Echtzeit-Datenverteilung gilt es, vor allem zwei Parameter abzusichern:
- – System Data Distribution Delay (SDDD, s. o.): Dies garantiert, dass der Vortrag synchronisiert gehalten wird;
- – User Data Distribution Delay (UDDD, s. o.): Dies garantiert, dass alle Userinteraktionen in einem definierten Zeitverhalten umgesetzt werden.
-
Das Ablaufprotokoll der Datenverteilung ist beispielsweise der 3 zu entnehmen. Die Zeitachse ist hierbei vertikal dargestellt. Ein von einem User X, insbesondere einem Vortragenden mit Hilfe seines Computers 22a, ausgelöstes Ereignis wird an einen Server, beispielsweise den Datenserver 5, geschickt, dort verarbeitet und ein entsprechendes Update-Signal an den User X zurückgeschickt. Auf Seiten des Datenservers 5 dauert diese Verarbeitung eine gewisse Zeit, der auf der vertikalen Zeitachse des Datenservers 5 durch den Abstand des obersten, ersten Kreises zum zweiten Kreis symbolisiert ist.
-
Wenn die Verarbeitung auf dem Datenserver 5 beendet ist, wird eine entsprechende Nachricht „Verarbeitung beendet, Verteilung gestartet” an den User X geschickt. Im Anschluss an die Verarbeitung werden vom Datenserver 5 die Daten zum Ereignis, das auf Seiten des Users X initiiert wurde, zu den Usern 1 bis N geschickt, von diesen empfangen und dem Datenserver 5 bestätigt, woraufhin der Datenserver 5 an den User X ein entsprechendes Update hinsichtlich der Verteilung und nach Beendigung der Verteilung eine entsprechende Nachricht schickt. Die Verteilungszeit wird durch den Abstand auf der dem Datenserver 5 zugeordneten vertikalen Achse vom zweiten zum dritten Kreis symbolisiert. Die beiden Schritte „Verarbeitung” und „Verteilen” sind im Einklang mit dem oben Gesagten am linken Bildrand mit „SDDD” markiert.
-
An die Verteilung schließt sich in diesem Beispiel eine Userinteraktion an. Hierbei wird ein Userereignis auf Seiten eines der User 1 bis N an den Datenserver 5 geschickt, der ein Update zum Userinput und schließlich ein Signal „Userereignis beendet” an den User X schickt. Die Dauer der Userinteraktion („UDDD” minus „SDDD” auf der linken Bildhälfte, s. o.) ist auf der dem Datenserver 5 zugeordneten Vertikalen durch den Abstand des dritten vom vierten Kreis symbolisiert.
-
In der 4 ist der gleiche Sachverhalt auf einem üblichen horizontalen Zeitstrahl dargestellt. Hier ist zudem beispielhaft angeführt, dass vom Moderator eine Frage „Q” als Ereignis an die Konferenzteilnehmer gestellt wird, die auf dem Server, beispielsweise dem Datenserver 5, verarbeitet und dort in beispielsweise ein XML-Format eingearbeitet wird. Am Ende der Verteilung wird dem User X die Information mitgeteilt, dass alle Fragen verteilt wurden. Ähnlich wird am Ende der Userinteraktionszeit mitgeteilt, dass alle Fragen und Antworten „Q&A” beantwortet wurden.
-
In der 5 sind die auftretenden Zeitverzögerungen bei der Verteilung von Daten- und A/V-Strömen wiedergegeben. Video- und Audio-Ströme beispielsweise des Vortragenden („Sender”) werden zum Konferenzserver 3 gesendet, dort synchronisiert und an die Computer 22b der Konferenzteilnehmer gesendet. Der Konferenzserver 3 übermittelt die A/V-Ströme zudem an den Broadcastserver 13, der einen entsprechenden A/V-Strom an die Computer 22 der Webteilnehmer sendet. Die vom Vortragenden an den Datenserver 5 gesendeten Daten werden zu den Computers 20b, 22 der Teilnehmer (Konferenzteilnehmer und Webteilnehmer) übermittelt bzw. von diesen heruntergeladen.
-
Die Zeitverzögerung, die auf Seiten der Konferenzteilnehmer zwischen dem Empfang der A/V-Ströme einerseits und der Datenströme andererseits liegt, ist mit T1 bezeichnet, während die entsprechende Zeitverzögerung auf Seiten der Webteilnehmer mit T2 bezeichnet ist. Eine Gesamtsynchronisierung des Systems kann demnach durch jeweilige Synchronisierung der A/V-Ströme und der Datenströme erreicht werden. Hierzu werden vorzugsweise Datenreduktion, Feedbackprotokolle und/oder Bandbreitenadaptierungsalgorithmen eingesetzt. Auch können die Downloadzeiten der Datenströme vom Datenserver und/oder die Übertragung der A/V-Ströme geregelt werden.
-
In der 6 ist die entsprechende Synchronisierungssituation schematisch dargestellt. Demnach sind Regelalgorithmen eingebaut, welche zur Synchronisierung der Audio- und Videoströme als auch der Datenströme dienen. Prinzipiell ist das Zeitverhalten von Verarbeitung (Transcoding usw.) sowie Netzverbindungen (A/V-Ströme, Image Download, usw.) zu synchronisieren. Dazu werden Feedbackinformationen genutzt, welche Buffergrößen sowie Delays verschieben und Visualisierungen im GUI (Graphical User Interface, graphische Benutzeroberfläche) ermöglichen. Da dieses Verhalten auf mehreren Servern aufgeteilt ist sowie mit den Bandbreitenadaptierungsalgorithmen zusammenspielen muss, ist das Gesamtverhalten als Regelsystem höheren Grades anzusehen.
-
In der 7 ist der prinzipielle Datenfluss bei dem erfindungsgemäßen Videokonferenz-System wiedergegeben (hier ohne Übertragung mittels Broadcastserver an Webteilnehmer). Der Vortragende speist hierbei Audio- und Videoinformationen sowie einen Vortrag (Daten in Form beispielsweise einer PowerPoint-Präsentation) in das System ein. Dabei ist an zwei Stellen durch Kreise beispielhaft markiert, wie die zuvor beschriebenen Echtzeitsystemaspekte auf das zu erstellende Protokoll wirken. Der linke Kreis speichert z. B. das Ereignis „Daten verteilt” auf dem Protokollserver 11 (senkrechter Pfeil nach unten) und der rechte Kreis auf dem zum Vortragenden gerichteten Pfeil markiert und verursacht eine entsprechend Speicherung im Protokollserver 11 (senkrechter Pfeil nach unten), dass „alle Daten bei Usern angekommen” sind oder „alle Daten angekommen und User Interaktion durchgeführt”. Diese Informationskorrelationen sind insofern relevant, da in der Protokollierungssoftware zur Protokollerstellung die Datensynchronisation garantiert werden muss, und nicht nur die reine Statusänderung beim Vortragenden.
-
Unter Einhaltung des beschriebenen Ablaufs kann ein Protokoll gemäß der Erfindung unter Echtzeitbedingungen erstellt werden, vorzugsweise veranlasst und geregelt vom Protokollserver, und dem Vortragenden dabei Feedback zur Visualisierung geben. Der Ablauf in 7 kann zudem erweitert werden, indem hinzukommende und verlassende User ebenfalls berücksichtigt, beispielsweise protokolliert, werden können.
-
Entsprechend dem Vorgesagten ermöglicht es die Erfindung, Protokolle als automatisierte Zusammenfassungen von Videokonferenzen unter Verwendung von Daten (Medien) und A/V-Strömen zu erstellen. Diese Protokolle erfüllen Echtzeitbedingungen, sodass die Daten- und Informationssychronisierung unter allen Teilnehmern garantiert ist. Hierbei sind Datenreduktion und Feedbackprotokolle wesentliche Faktoren, um das korrekte SDDD und das definierte UDDD für die Echtzeitbedingungen einzuhalten.
-
Bezugszeichenliste
-
- 1
- Zentralserver
- 3
- Konferenzserver
- 5
- Datenserver
- 7
- Authentifizierungsmodul
- 9
- Anmerkungssystem
- 10
- Datenbank
- 11
- Protokollserver
- 13
- Übertragungsserver
- 15
- Zertifizierungsserver
- 20a, b
- Teilnehmercomputer
- 22
- Webteilnehmer
