DE112021001105T5 - Remote-videozusammenarbeit in echtzeit - Google Patents

Remote-videozusammenarbeit in echtzeit Download PDF

Info

Publication number
DE112021001105T5
DE112021001105T5 DE112021001105.7T DE112021001105T DE112021001105T5 DE 112021001105 T5 DE112021001105 T5 DE 112021001105T5 DE 112021001105 T DE112021001105 T DE 112021001105T DE 112021001105 T5 DE112021001105 T5 DE 112021001105T5
Authority
DE
Germany
Prior art keywords
rtc
video
file
client device
session
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112021001105.7T
Other languages
English (en)
Inventor
Alex Cyrell
Brad Thomas Ahlf
Jon Walkenhorst
Marcie Jastrow
Roger Patrick Barton
Chad Andrew Furman
Steven Barry Cohen
Damien Phelan Stolarz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Evercast LLC
Original Assignee
Evercast LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US16/794,962 external-priority patent/US10887633B1/en
Application filed by Evercast LLC filed Critical Evercast LLC
Publication of DE112021001105T5 publication Critical patent/DE112021001105T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234363—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the spatial resolution, e.g. for clients with a lower screen resolution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234381—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the temporal resolution, e.g. decreasing the frame rate by frame skipping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2387—Stream processing in response to a playback request from an end-user, e.g. for trick-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Studio Circuits (AREA)

Abstract

Beschrieben sind Systeme und Verfahren, die Sitzungen mit sicherer Echtzeit-Kommunikation („RTC“) ermöglichen, die beispielsweise für die Bearbeitung und Filmproduktion verwendet werden können. Client-Vorrichtungen können mit einem RTC-Verwaltungssystem interagieren, um an verschiedenen Dateien zusammenzuarbeiten, die auf den verschiedenen Client-Vorrichtungen gespeichert sind, ohne dass die Dateien von der Client-Vorrichtung hochgeladen werden müssen, auf der sie gespeichert sind. Darüber hinaus kann für jede Client-Vorrichtung einer RTC-Sitzung während der RTC-Sitzung eine fortlaufende Multifaktor-Authentifizierung durchgeführt werden und/oder es kann eine Video-Authentifizierung verwendet werden, um Zugriff auf eine RTC-Sitzung zu gewähren. Weiterhin kann, um die Qualität der ausgetauschten Videoinformationen zu verbessern und die Übertragungsanforderungen zu verringern, als Reaktion auf die Erfassung von Ereignissen, wie z. B. einem Pausenereignis, ein hochauflösendes Bild eines pausierten Videos erzeugt und zur Darstellung auf der Anzeige jeder Client-Vorrichtung gesendet werden, anstatt weiterhin ein angehaltenes Video zu streamen.

Description

  • PRIORITÄTSANSPRUCH
  • Diese Anmeldung beansprucht den Vorteil der US-Anmeldung Nr. 17/179,381 , eingereicht am 18. Februar 2021 und mit dem Titel „Remote Folders for Real Time Remote Collaboration“, vorläufige US-Anmeldung Nr. 62/978,554 , eingereicht am 19. Februar 2020 und mit dem Titel „Real Time Remote Video Collaboration With Feedback“, US-Patentanmeldung Nr. 17/139,472 , eingereicht am 31. Dezember 2020 mit dem Titel „Real Time Remote Video Collaboration“, und die US-Patentanmeldung Nr. 16/794,962 , eingereicht am 19. Februar 2020 und mit dem Titel „Real Time Remote Video Collaboration“, deren Inhalt hierin durch Bezugnahme in ihrer Gesamtheit aufgenommen wird.
  • STAND DER TECHNIK
  • Der Prozess der Erstellung von Film- und Fernsehunterhaltung ist komplex und enthält viele logistische Hindernisse. Bei Produktionen sind oft weit verstreute Drehorte miteinbezogen. Selbst wenn Produktionen an einem einzigen Ort gedreht werden, erfordern die Postproduktionsaufgaben wie Schnitt, Computergrafik, Vertonung, Ton, Farbe und Überprüfung immer, dass sich Menschen verschiedener Orte entweder treffen oder remote zusammenarbeiten. Viele der mit der Medienproduktion verbundenen Kosten und Verzögerungen sind zeitliche und räumliche Barrieren.
  • Die Folge davon ist, dass Telepräsenz-Tools mehr denn je benötigt werden, um die produktionsbedingten zeitlichen und räumlichen Barrieren zu überwinden. Das Problem früherer Tools für Audiokonferenzen, Videokonferenzen und Online-Videozusammenarbeit besteht darin, dass sie ein schlechter Ersatz für die physische Anwesenheit sind. Es gibt verschiedene Mängel bei herkömmlichen Tools, die für Videokonferenzen verwendet werden. Kosten und Komplexität sind große Probleme, da viele Systeme teure Hardwareinstallationen von Kameras und Bildschirmen und die Konfiguration von Netzwerkumgebungen erfordern, um die erforderliche Bandbreite zu unterstützen.
  • Außerdem weisen sowohl softwarebasierte als auch hardwarebasierte Videoübertragungssysteme Latenz- (Verzögerungs-) und Qualitätsprobleme auf. Die Verzögerung manifestiert sich in Netzwerkverzögerungen und Komprimierungsverzögerungen, die dazu führen, dass Übertragungen nicht als sofort wahrgenommen werden, mit Verzögerungen von mehr als einer halben Sekunde bis zu mehr als einer Sekunde.
  • Es gibt noch andere Probleme, die der Remote-Zusammenarbeit innewohnen. Viele Medienproduktionen haben aufgrund der Höhe der Investition hohe Sicherheitsanforderungen. Nur autorisiertes, vertrauenswürdiges Personal sollte an einem Projekt zusammenarbeiten dürfen, aber die Remote-Zusammenarbeit macht die physische Durchsetzung der Sicherheit (verschlossene Türen, physische Zugangskontrollen) unmöglich.
  • Figurenliste
    • 1 ist eine beispielhafte Umgebung für Remote-Videozusammenarbeit gemäß Implementierungen der vorliegenden Offenbarung.
    • 2 ist ein Übergangsdiagramm der Farbkalibrierung von Client-Vorrichtungen an verschiedenen Standorten für die Remote-Videozusammenarbeit, in Übereinstimmung mit Implementierungen der vorliegenden Offenlegung.
    • 3A bis 3B sind ein Übergangsdiagramm zur kontinuierlichen Sicherheitsüberprüfung von Teilnehmern an unterschiedlichen Standorten, die auf ein Echtzeit-Kommunikationssystem für Remote-Videozusammenarbeit zugreifen, gemäß Implementierungen der vorliegenden Offenbarung.
    • 4A bis 4B sind ein Übergangsdiagramm der Remote-Videozusammenarbeit in Echtzeit gemäß Implementierungen der vorliegenden Offenbarung.
    • 5A bis 5B sind ein weiteres Übergangsdiagramm einer anderen Remote-Videozusammenarbeit in Echtzeit gemäß Implementierungen der vorliegenden Offenbarung.
    • 6 ist ein Flussdiagramm eines beispielhaften Farbanpassungsprozesses einer Client-Vorrichtung gemäß Implementierungen der vorliegenden Offenbarung.
    • 7 ist ein Flussdiagramm eines beispielhaften Benutzeridentitätsverifizierungsprozesses gemäß Implementierungen der vorliegenden Offenbarung.
    • 8 ist ein Flussdiagramm eines beispielhaften Kommunikations-Videokollaborationsprozesses in Echtzeit gemäß Implementierungen der vorliegenden Offenbarung.
    • 9 ist ein Flussdiagramm eines weiteren Beispiels für einen Kommunikations-Videokollaborationsprozess in Echtzeit, gemäß Implementierungen der vorliegenden Offenbarung.
    • 10A bis 10G sind Übergangsdiagramme für die entfernte gemeinsame Nutzung von Ordnern während einer Echtzeit-Kommunikationssitzung und einer videobasierten Zugriffsauthentifizierung gemäß Implementierungen der vorliegenden Offenbarung.
    • 11 ist ein beispielhafter Prozess des Remote-Ordners gemäß Implementierungen der vorliegenden Offenbarung.
    • 12 ist ein beispielhafter Seitenkommunikationsprozess gemäß Implementierungen der vorliegenden Offenbarung.
    • 13 ist ein beispielhafter Kommunikationssitzungs-RTC-Raumzugangsprozess in Echtzeit gemäß Implementierungen der vorliegenden Offenbarung.
    • 14A bis 14B ist ein beispielhafter sicherer Dateizugriffsprozess gemäß Implementierungen der vorliegenden Offenbarung.
    • 15 ist ein beispielhafter Kommunikationssitzungsprozess in Echtzeit gemäß Implementierungen der vorliegenden Offenbarung.
    • 16 ist ein beispielhaftes Kommunikationssitzungsüberwachungsverfahren in Echtzeit gemäß Implementierungen der vorliegenden Offenbarung.
    • 17 ist ein Blockdiagramm von Rechenkomponenten, die mit Implementierungen der vorliegenden Offenbarung verwendet werden können.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Wie nachstehend ausführlicher dargelegt wird, richten sich Implementierungen der vorliegenden Offenbarung auf Sitzungen zur Echtzeitkommunikation („RTC“), die beispielsweise eine sichere Zusammenarbeit in Bezug auf Videos zur Bearbeitung und Filmproduktion ermöglichen, an denen Teilnehmer jeweils an unterschiedlichen und getrennten Standorten teilnehmen können. Die Zusammenarbeit zwischen den Teilnehmern bei der Videobearbeitung für die Filmproduktion erfordert eine geringe Latenz und einen qualitativ hochwertigen Videoaustausch zwischen den Client-Standorten sowie eine sichere Umgebung. Wie weiter unten besprochen, können Client-Vorrichtungen mit einem RTC-Verwaltungssystem interagieren, um Farbkalibrierungsinformationen zu erhalten, sodass die auf den verschiedenen Client-Vorrichtungen präsentierte Farbe miteinander konsistent ist und der beabsichtigten Farbe des Videos entspricht, für das eine Zusammenarbeit durchgeführt werden soll. Das Anpassen von Farben zwischen verschiedenen Orten ermöglicht die Wahrung der kreativen Absicht der Ersteller von Inhalten. Darüber hinaus ermöglichen die offenbarten Implementierungen eine fortlaufende Multifaktor-Authentifizierung für jeden Teilnehmer, um sicherzustellen, dass der Teilnehmer am Client-Standort bleibt und das auf der Client-Vorrichtung präsentierte Video ansieht. Weiterhin kann, um die Qualität der ausgetauschten Videoinformationen zu verbessern und die Übertragungsanforderungen zu verringern, als Reaktion auf die Erfassung von Ereignissen, wie z. B. einem Pausenereignis, ein hochauflösendes Bild eines pausierten Videos erzeugt und zur Darstellung auf der Anzeige jeder Client-Vorrichtung gesendet werden, anstatt weiterhin ein angehaltenes Video zu streamen.
  • 1 ist eine beispielhafte Umgebung für Remote-Videozusammenarbeit gemäß Implementierungen der vorliegenden Offenbarung.
  • Wie dargestellt, kann eine beliebige Anzahl von Client-Standorten, wie z. B. die Client-Standorte 100-1, 100-2 bis 100-N, miteinander kommunizieren und interagieren und/oder einem Echtzeit-Kommunikations („RTC“)-Verwaltungssystem 101, das auf einer oder mehreren Remote-Rechenressourcen 103 ausgeführt wird. Jeder der Client-Standorte 100 und das RTC-Verwaltungssystem 101 können über ein Netzwerk 150 wie etwa das Internet kommunizieren.
  • Jeder Client-Standort 100 kann eine Client-Vorrichtung 102, eine oder mehrere tragbare Vorrichtungen 104, die einem Teilnehmer 107 gehören, von ihm kontrolliert und/oder betrieben werden, und/oder eine oder mehrere am Körper tragbare Vorrichtungen 106, die dem Teilnehmer 107 gehören, von ihm kontrolliert und/oder betrieben werden, einschließen. Eine Client-Vorrichtung 102, wie sie hierin verwendet wird, ist jede Art von Computersystem oder -komponente, die mit anderen Vorrichtungen kommunizieren und/oder interagieren kann (z. B. andere Client-Vorrichtungen, tragbare Vorrichtungen, am Körper tragbare Vorrichtungen, RTC-Verwaltungssystem usw.) und kann einen Laptop, einen Desktop usw. einschließen. Eine tragbare Vorrichtung 104, wie sie hierin verwendet wird, schließt jede Art von Vorrichtung ein, die typischerweise getragen wird oder sich im Besitz eines Benutzers befindet. Eine tragbare Vorrichtung 104 kann zum Beispiel ein Mobiltelefon oder Smartphone, ein Tablet, ein Laptop, eine Webkamera, eine Digitalkamera usw. sein. Eine am Körper tragbare Vorrichtung 106, wie sie hierin verwendet wird, ist jede Art von Vorrichtung, die typischerweise von einem Benutzer getragen wird, und kann unter anderem eine Uhr, eine Halskette, ein Ring usw. sein.
  • In dem veranschaulichten Beispiel schließt der Client-Standort 100-1 eine Client-Vorrichtung 102-1, eine oder mehrere tragbare Vorrichtungen 104-1, eine oder mehrere tragbare Vorrichtungen 106-1 und einen Teilnehmer 107-1 ein. Ebenso schließt der Client-Standort 100-2 eine Client-Vorrichtung 102-2, eine oder mehrere tragbare Vorrichtungen 104-2, eine oder mehrere am Körper tragbare Vorrichtungen 106-2 und einen Teilnehmer 107-2 ein. Eine beliebige Anzahl von Client-Standorten 100-N mit Teilnehmern 107-N kann mit den offenbarten Implementierungen verwendet werden, und jeder Client-Standort kann eine Client-Vorrichtung 102-N, eine oder mehrere tragbare Vorrichtungen 104-N und eine oder mehrere am Körper tragbare Vorrichtungen 106-N einschließen.
  • Wie weiter unten besprochen, kann jede Client-Vorrichtung 102 von einem jeweiligen Teilnehmer verwendet werden, um auf das RTC-Verwaltungssystem zuzugreifen und an einem oder mehreren Videos zusammenzuarbeiten, die über das RTC-Verwaltungssystem ausgetauscht werden. Ebenso können, wie weiter unten beschrieben, tragbare Vorrichtungen (104) und/oder am Körper tragbare Vorrichtungen (106) miteinander und/oder mit der jeweiligen Client-Vorrichtung (102) kommunizieren und dem RTC-Verwaltungssystem (101) eine laufende oder regelmäßige Überprüfung der Benutzeridentität liefern, die hierin als Identitätsinformationen bezeichnet wird. Beispielsweise kann eine tragbare Vorrichtung 104 drahtlos mit der Client-Vorrichtung über ein Kurzwellen-Kommunikationssystem wie Bluetooth oder Near Field Communication („NFC“) kommunizieren und so die Anwesenheit der tragbaren Vorrichtung in Bezug auf den Standort der Client-Vorrichtung bestätigen. Ebenso können eine oder beide der tragbaren Vorrichtungen 104 und der am Körper tragbaren Vorrichtungen 106 Positionsinformationen bezüglich der Position der tragbaren Vorrichtung 104/der am Körper tragbaren Vorrichtung 106 liefern, und diese Informationen können vom RTC-Verwaltungssystem 101 verwendet werden, um den Standort des Teilnehmers zu überprüfen. Darüber hinaus können eine oder mehrere von Client-Vorrichtung 102, tragbarer Vorrichtung 104 und/oder am Körper tragbare Vorrichtung 106 Bilddaten des Teilnehmers und/oder des Bereichs in unmittelbarer Umgebung des Teilnehmers liefern. Auch hier können diese Informationen verarbeitet werden, um den Standort des Teilnehmers zu bestimmen, die Identität des Teilnehmers festzustellen und/oder zu ermitteln, ob andere Personen am Standort eine Gefahr für die Sicherheit darstellen könnten.
  • Darüber hinaus ermöglichen die Client-Vorrichtungen 102, wie nachstehend erörtert, den Teilnehmern an jedem Standort, an einem Video zusammenzuarbeiten, das von einer der Client-Vorrichtungen 102 oder dem RTC-Verwaltungssystem 101 gestreamt oder anderweitig präsentiert wird. Wie es während der Videozusammenarbeit üblich ist, fordert ein Teilnehmer an, das Video anzuhalten, was hierin als Triggerereignis bezeichnet wird. Anstatt das angehaltene Video weiterhin von einer Client-Vorrichtung zu anderen zu streamen, kann bei Erkennung des Triggereignisses ein hochaufgelöstes Bild, wie etwa ein unkomprimiertes Bild, des angehaltenen Videos erhalten oder erzeugt und an Ziel-Client-Vorrichtungen gesendet und präsentiert werden auf der Anzeige dieser Vorrichtungen statt oder über dem angehaltenen Video. Eine solche Implementierung stellt ein Bild des Videos mit höherer Auflösung bereit und reduziert die Übertragungsanforderungen zwischen Client-Vorrichtungen und/oder dem RTC-Verwaltungssystem. Wenn das Video fortgesetzt wird, wird ein weiteres Triggerereignis, das hochaufgelöste Bild von der Anzeige entfernt und die Präsentation des gestreamten Videos wird auf jeder der Client-Vorrichtungen fortgesetzt.
  • In einigen Implementierungen kann das RTC-Verwaltungssystem eine Videodatei streamen und das aktuelle Einzelbild der Datei, das gestreamt wird, und bei welchem Einzelbild die visuelle Anzeige pausiert ist, kennen. Beim Empfang eines Triggerereignisses kann das System ein hochaufgelöstes Bild des aktuellen Frames sowie Frames vor und nach dem aktuellen Frame erzeugen und senden. Beispielsweise kann das System unter Verwendung des Triggerereignisses als Angabe eines interessierenden Bereichs in der Datei eine definierte Anzahl von hochaufgelösten Bildern (erste Vielzahl von hochaufgelösten Bildern), die aus vorangehenden Einzelbildern erzeugt wurden, erzeugen und senden. Indem eine definierte Anzahl von Frames vor und nach dem aktuellen Frame bereitgestellt wird, stehen die hochaufgelösten Frames zur Präsentation zur Verfügung, wenn ein Client wünscht, mehrere Frames vorwärts oder rückwärts zu navigieren. Wenn der Client einen Clip abspielt, der das angehaltene Einzelbild enthält, kann der Clip in ähnlicher Weise mit hoher Auflösung wiedergegeben werden, wobei zumindest alle Einzelbilder verwendet werden, die in hoher Auflösung gesendet wurden. Das System kann weiterhin hochaufgelöste Einzelbilder um den interessierenden Bereich herum an den Client herunterladen, solange die Datei angehalten ist.
  • Der Rec. 709-Farbraum, der üblicherweise in HDTV verwendet wird, verfügt bekanntlich über einen erweiterten Farbbereich, der dargestellt werden kann, und der Rec. 2020-Farbraum, der üblicherweise für Ultra HD verwendet wird, schließt einen noch breiteren Farbbereich ein, den er darstellen kann. Je weiter der Farbraum ist, desto mehr Farben können dargestellt werden und desto größer ist die Datenmenge, die zu ihrer Darstellung benötigt wird. In den offenbarten Implementierungen können mehr Bits für jeden Farbkanal verwendet werden. Beispielsweise können die offenbarten Implementierungen statt eines 8-Bit-RGB-Farbkanals 10 Bits oder 12 Bits pro Kanal verwenden, um die roten, grünen und blauen Komponenten eines Pixels darzustellen. Diese höheren Bit-pro-Kanal-Zuweisungen können verwendet werden, um sogenannte „High Dynamic Range“ (HDR)-Inhalte für Anzeigen darzustellen, die ihn wiedergeben können.
  • In einigen Implementierungen kann ein Benutzer an einer Vorrichtung mit einem Farbraumauswahldialog interagieren, um eines von vielen verschiedenen zu verwendenden Anzeigeprofilen auszuwählen. Die Anzeigeprofile können eine Farbnachschlagetabelle bereitstellen, die Farben aus einem vorrichtungsunabhängigen Farbraum auf den Monitor übersetzt oder abbildet, der zum Betrachten des Bilds verwendet wird, und die bestmögliche Arbeit leistet, um die beabsichtigten Farben genau darzustellen. Je besser der Farbwiedergabebereich des Zielmonitors ist, desto treuer ist die Abbildung zwischen dem Quellbild und dem Bildraum. Der gesamte Bereich der menschlichen Farbwahrnehmung kann in einem vorrichtungsunabhängigen Farbraum dargestellt werden, wie er in ACES 1.0 (Academy Color Encoding System) spezifiziert ist, das von der Academy of Motion Picture Arts and Sciences entwickelt wurde.
  • Beim Verfassen von Inhalten mit hoher Auflösung, hohem Dynamikbereich und tiefen Farben ist es oft wünschenswert, dass Benutzer an verschiedenen Orten eine Referenz haben, damit sie sich einig sind, was sie sehen. Infolgedessen können die Benutzer farbkalibrierte Monitore desselben Herstellers und/oder Monitore, die denselben Farbraum genau darstellen können, verwenden. Wenn also zwei voneinander entfernte Produktionsmitarbeiter in einem vereinbarten Farbraum, beispielsweise P3, arbeiten, könnten sie Bilder in P3 über eine Entfernung übertragen und an beiden Enden wiedergeben. Alternativ könnten sie das P3-Bild im Rec. 2020-Farbraum (von dem P3 eine Untermenge ist) darstellen und in Rec. 2020 als vereinbartem Referenzraum übertragen und das Bild dann auf einem geeigneten, vereinbarten Referenzbildschirm anzeigen.
  • Ein Problem, das beim Teilen von Inhalten aus der Ferne auftritt, ist, dass die Inhalte oft komprimiert sind. Neben der räumlichen und zeitlichen Komprimierung, bei der die Größe reduziert und Informationen auf der Grundlage von Änderungen entfernt werden, besteht ein weiterer gängiger Ansatz zur Bildkomprimierung in der Unterabtastung von Teilen des Bildchromas, d. h., dem Luminanzanteil eines Bildes (im grünen Spektrum) wird eine höhere Auflösung und den blauen und roten Kanälen eine geringere Auflösung zugewiesen. Beim so genannten „4:2:2“-Unterabtasten wird die Hälfte der Pixelauflösung für Rot und Blau verwendet. Im Vergleich, 4:4:4, ohne Unterabtastung, führt keine Unterabtastung an Pixeln durch.
  • Um das Maximum an visueller Qualität, Farbpräzision und Farbbereich in einem Bild zu bewahren, ist es vorzuziehen, Bilddaten mit so wenig verlustbehafteter Bildkomprimierung wie möglich zu übertragen, idealerweise ohne (d.h. ein Rohbild).
  • 2 ist ein Übergangsdiagramm der Farbkalibrierung von Client-Vorrichtungen 202 an verschiedenen Client-Standorten 200 für die Remote-Videozusammenarbeit, in Übereinstimmung mit Implementierungen der vorliegenden Offenlegung. Um eine konsistente und genaue Farbdarstellung des Videos zwischen jeder Client-Vorrichtung 202 an den verschiedenen Client-Standorten, wie z. B. Client-Standort 200-1 und 200-2, zu ermöglichen, kann eine physische Farbkarte, wie z. B. die Farbkarten 211-1 und 211-2, neben eine Anzeige 207-1/207-2 der Client-Vorrichtung 202-1/202-2 gehalten werden, das eine Reihe von Farbbalken 213-1/213-2 und ein Bild der Farbkarte 211-1/211-2 und des Displays 207-1/207-2 mit den dargestellten Farbbalken 213-1/213-2 darstellt, das von einer Kamera 205-1/205-2 oder einem anderen Bildelement einer tragbaren Vorrichtung 204-1/204-2 erzeugt wird. Beispielsweise kann das Bild/die Bilder von jedem Client-Standort 200-1/200-2 über das Netzwerk 250, z. B. das Internet, an das RTC-Verwaltungssystem 201 gesendet werden, das auf einer oder mehreren Rechenressourcen 203 läuft.
  • Das RTC-Verwaltungssystem 201 kann beim Empfangen des Bildes/der Bilder von den tragbaren Vorrichtungen 204 jedes Bild verarbeiten, um Unterschiede zwischen der Farbkarte 211 und den in den Bildern dargestellten Farbbalken 213 zu bestimmen. Beispielsweise kann ein von der tragbaren Vorrichtung 204-1 empfangenes Bild verarbeitet werden, um einen Unterschied in der Farbe der Farbkarte 211-1 und der auf der Anzeige 207-1 der Client-Vorrichtung 202-1 dargestellten Farbbalken 213-1 zu bestimmen, wie im Bild dargestellt. Ebenso kann ein von der tragbaren Vorrichtung 204-2 empfangenes Bild verarbeitet werden, um einen Unterschied in der Farbe der Farbkarte 211-2 und der auf der Anzeige 207-2 der Client-Vorrichtung 202-2 dargestellten Farbbalken 213-2 zu bestimmen, wie im Bild dargestellt. Die Farbkarte wird, wenn sie von der Kamera des Mobilgeräts erfasst wird, mit einem Referenzbild verglichen und verwendet, um ein Beleuchtungsprofil zu erstellen, das verwendet werden kann, um alle Lichtverhältnisse auszugleichen und den Wertebereich zu bestimmen, der mit dieser bestimmten Kamera genau erfasst werden kann. Außerdem kann dieselbe Kamera verwendet werden, um ein Bild von Farbbalken zu erfassen, die auf dem Bildschirm wiedergegeben werden, und zwar unter denselben Lichtbedingungen (aber unter Verwendung von projiziertem, nicht reflektiertem Licht wie bei der Karte). Das RTC-Verwaltungssystem 201 kann dann die Wahrnehmung der Fähigkeiten der Kamera nutzen, um zu wissen, wie die Kamera die Farben ändert, um durch die Kamera und/oder die Lichtverhältnisse.eingeführte Wiedergabetreueprobleme zu kompensieren oder aufzuheben.
  • Die Farbkarte 211 kann eine passive, physische Karte sein, wie beispielsweise ein mattes oder glänzendes bedrucktes Medium. Die Farbkarte kann verschiedene Formen annehmen und Farbe, Farbstoff usw. einschließen, die auf eine poröse Oberfläche wie Papier oder Pappe aufgebracht werden. Die Farbkarte kann mit einer matten oder reflektierenden Beschichtung beschichtet sein. In einigen Implementierungen kann die Farbkarte eine passive Karte ohne Stromversorgung sein, die eine reflektierende Farbreaktion erzeugt und Informationen über das Umgebungslicht im Raum in der Nähe des Bildschirms bereitstellt. Alternativ kann die Farbkarte in Form eines durchscheinenden Bildes wie etwa eines „Gels“ mit Hintergrundbeleuchtung vorliegen. Eine durchscheinende hintergrundbeleuchtete Karte ermöglicht eine durchlässige Farbe, die repräsentativer für die durchlässige Farbe einer Anzeige sein kann, wie z. B. einer LED- oder OLED-Anzeige. In noch anderen Beispielen kann die Farbkarte ein digitales Bild sein, das auf eine Vorrichtung wie etwa ein Tablet oder Smartphone projiziert wird.
  • In einigen Implementierungen kann die Verarbeitung des Bildes zu einer Gamma-Anpassungsanweisung führen, die der Client-Vorrichtung 202 bereitgestellt wird, um das Gamma der Anzeige 207 der Client-Vorrichtung 202 so einzustellen, dass die von der Anzeige 207 präsentierten Farbbalken 213 den Farben der Farbkarte 211 entsprechen. Beispielsweise kann das von der tragbaren Vorrichtung 204-1 am Client-Standort 200-1 empfangene Bild verarbeitet werden, um eine erste Gamma-Anpassungsanweisung zu bestimmen, und diese erste Gamma-Anpassungsanweisung kann von dem RTC-Verwaltungssystem 201 an die Client-Vorrichtung gesendet werden 202-1, um die Client-Vorrichtung 202-1 anzuweisen, ein Gamma der Anzeige 207-1 einzustellen. Ebenso kann das von der tragbaren Vorrichtung 204-2 am Client-Standort 200-2 empfangene Bild verarbeitet werden, um eine zweite Gamma-Anpassungsanweisung zu bestimmen, und diese zweite Gamma-Anpassungsanweisung kann von dem RTC-Verwaltungssystem 201 an die Client-Vorrichtung gesendet werden 202-2, um die Client-Vorrichtung 202-2 anzuweisen, ein Gamma der Anzeige 207-2 einzustellen. Diese Prozesse können viele Male für jede Client-Vorrichtung 202 an jedem Client-Standort durchgeführt werden, bis die Farbbalken, die auf der Anzeige jeder Client-Vorrichtung 202 dargestellt werden, den Farben der jeweiligen Farbkarten 211 entsprechen.
  • In einigen Implementierungen kann das RTC-Verwaltungssystem 201 zur Erzielung von Konsistenz zwischen Client-Vorrichtungen an verschiedenen Standorten zusätzlich oder alternativ zur Einstellung der Anzeige jeder Client-Vorrichtung 202, so dass die auf der Anzeige 207 der Vorrichtung dargestellten Farbbalken den Farben der jeweiligen Farbkarte 211 entsprechen, auch die auf den Anzeigen der verschiedenen Client-Vorrichtungen dargestellten Farbbalken vergleichen, um Farbunterschiede zwischen diesen Client-Vorrichtungen zu ermitteln. Nachdem beispielsweise das Gamma der Client-Vorrichtung 202-1 und das Gamma der Client-Vorrichtung 202-2 so eingestellt wurden, dass die Farbbalken dieser Client-Vorrichtungen so genau wie möglich den Farben der Farbkarten 211-1 und 211-2 entsprechen, kann das RTC-Verwaltungssystem die von jeder Client-Vorrichtung 202-1 und 202-2 dargestellten Farbbalken vergleichen, um etwaige Unterschiede zwischen den dargestellten Farben dieser Vorrichtungen zu ermitteln. Wenn ein Unterschied festgestellt wird, können eine oder beide Client-Vorrichtungen angewiesen werden, das Gamma der Anzeige 207 weiter anzupassen, bis die auf den Anzeigen 207-1/207-2 dargestellten Farbbalken 213-1/213-2 korreliert sind.
  • Es versteht sich, dass die Farbanpassung zwischen Farbkarten und Farbbalken, wie hierin erörtert, für eine einzelne Vorrichtung durchgeführt werden kann, das mit dem RTC-Verwaltungssystem kommuniziert, oder für eine beliebige Anzahl von Client-Vorrichtung, die mit dem RTC-Verwaltungssystem kommunizieren. Während das obige Beispiel beschreibt, dass das RTC-Verwaltungssystem 201, das auf den Rechenressourcen 203 ausgeführt wird, Bilder von tragbaren Vorrichtungen 204 an den verschiedenen Client-Standorten empfängt und diese Bilder verarbeitet, um Gamma-Anpassungsanweisungen zu bestimmen, können in anderen Implementierungen die Bilder von der tragbaren Vorrichtung 204 verarbeitet werden, die das Bild erzeugt hat, und die tragbare Vorrichtung 204 kann die Gamma-Anpassungsanweisung bestimmen und an die Client-Vorrichtung 202 weiterleiten. In noch anderen Beispielen kann die tragbare Vorrichtung 204 nach der Erzeugung des Bildes der Farbkarte 211 und der Farbbalken 213, die auf einem Display 207 der Client-Vorrichtung 202 dargestellt werden, das Bild an die Client-Vorrichtung 202 übermitteln, und die Client-Vorrichtung 202 kann das Bild verarbeiten, um Anweisungen zur Gamma-Einstellung zu bestimmen. Darüber hinaus kann es neben Gamma auch andere Einstellparameter geben, die die Farbtreue verbessern, und das System kann Einstellanweisungen für andere einstellbare Parameter der Konfiguration der Client-Vorrichtung bereitstellen, wie z. B. Farbtiefe, Farbnachschlagetabelle, Auflösung, Unterabtastfrequenz, Helligkeit, Sättigung, Farbton, Weißpunkt, Dynamikbereich usw.
  • In einigen Implementierungen verwenden die beiden Enden, um Konsistenz zwischen Client-Vorrichtungen an unterschiedlichen Standorten zu erhalten, zusätzlich oder als Alternative zum Anpassen der Anzeige jeder Client-Vorrichtung 202 an beiden Enden eine identisch konfigurierte tragbare Vorrichtung 204, wobei die tragbaren Vorrichtungen automatisch eigene Gamma-, Helligkeits- oder andere Parameter anpassen. Die tragbaren Vorrichtungen können dann einen „Augmented Reality“-Ansatz mit einer integrierten Kamera verwenden, um das Bild, das auf der Client-Vorrichtung angezeigt wird, zu erfassen und zu identifizieren, und dann eine Verbindung mit dem RTC-Verwaltungssystem 201 herstellen, um das gleiche Bild abzurufen, das auf den Client-Vorrichtungen 202-1 und 202-2 angezeigt wird. Jede tragbare Vorrichtung 204 rendert einen Teil des Bildes, das auf der Client-Vorrichtung 202 betrachtet wird, ähnlich wie eine „Lupe“. Ein Benutzer kann das Bild auf der tragbaren Vorrichtung „aufziehen/zoomen“. Die tragbaren Vorrichtungen desselben Herstellers haben oft kleinere Bildschirme zum Abspielen von Bildern mit hoher Auflösung unter Verwendung von Anzeigetechnologien, z. B. organische LED (OLED), und haben einen höheren Dynamikbereich unter Verwendung von Anzeigemerkmalen wie High Dynamic Range (HDR). Beispielsweise können beide Enden unterschiedliche Arten von Anzeigen auf den Client-Vorrichtungen 202 haben, aber das gleiche Modell moderner Smartphones wie die tragbaren Vorrichtungen 204 haben. Somit können die Smartphones als ein automatisch kalibrierendes, konsistentes Farbwiedergabesystem an beiden Enden einer Fernverbindung arbeiten und einen Teil des Bildes anzeigen, der dem entspricht, worauf auf den Client-Vorrichtungen 202 gezeigt wird.
  • In einigen Implementierungen kann das Mobilgerät auch die gleichen manuellen Kalibrierungsschritte unter Verwendung von Farbbalken und/oder Farbkarten durchführen, wie sie für die Client-Vorrichtungen verwendet werden. Das Mobilgerät kann auch eine nach vorne gerichtete Kamera (auch als „Selfie“-Kamera bekannt) verwenden, um das Umgebungslicht zu messen und die Helligkeit und Farbe des Bildes auf dem Bildschirm entsprechend anzupassen, um Referenzwerte für die Farbkalibrierung zu erzeugen, die zu den gleichen Farbeinstellungen an beiden Enden einer Konferenz führen.
  • In einigen Beispielen kann eine „Blaufilter“-Technik zur Kalibrierung verwendet werden. In solchen Beispielen können die offenbarten Implementierungen Farbbalken anzeigen und dann die anderen Farbkanäle auf dem System auf Betriebssystemebene oder durch Kommunikation mit dem Monitor deaktivieren. Ein externer Blaufilter kann zwischen einer Kamera der tragbaren Vorrichtung 204 und der entsprechenden Client-Vorrichtung 202 angebracht werden, und die tragbare Vorrichtung 204 (oder die Client-Vorrichtung 202) kann den Benutzer anweisen, Helligkeit und Kontrast einzustellen, bis die auf der Anzeige angezeigten Balken übereinstimmen. Auf diese Weise kann ein Teil der Subjektivität oder menschlichen Fehler eliminiert werden. Die tragbare Vorrichtung 204 kann auch seine eigene interne Fähigkeit verwenden, um nur den blauen Farbkanal aus den erfassten Bildern zu filtern, und dann den Benutzer anweisen, Helligkeit und Kontrast anzupassen, bis sie sich in der richtigen Position für eine optimale Farbanpassung befindet.
  • In einigen Beispielen kann auf der tragbaren Vorrichtung 204 eine Anwendung laufen, die mit einer auf der zu kalibrierenden Client-Vorrichtung 202 laufenden Anwendung kommuniziert, die wiederum Befehle an das Betriebssystem oder den angeschlossenen Monitor sendet, um die Helligkeit und den Kontrast über eine digitale Schnittstelle automatisch anzupassen, bis eine der oben beschriebenen Farbanpassungstechniken korrekt kalibriert ist. Alternativ oder zusätzlich dazu kann die tragbare Vorrichtung 204 Anweisungen an den Benutzer liefern, um dasselbe zu erreichen. Alternativ kann die tragbare Vorrichtung 204 die Software auf der Client-Vorrichtung 202 anweisen, programmgesteuert automatisch einen anderen Farbraum oder eine andere Farbkonfiguration auszuwählen.
  • 3A bis 3B sind ein Übergangsdiagramm für die fortlaufende Sicherheitsüberprüfung von Teilnehmern 307 an verschiedenen Client-Standorten 300, die auf ein Echtzeit-Kommunikationssystem 301 für Remote-Videozusammenarbeit zugreifen, gemäß Implementierungen der vorliegenden Offenbarung. Das dargestellte Beispiel wird in Bezug auf zwei Client-Standorte 300-1 und 300-2 diskutiert. Es versteht sich jedoch, dass eine beliebige Anzahl von Client-Standorten in die RTC-Kommunikationssitzung eingeschlossen werden kann und eine fortlaufende Sicherheitsüberprüfung an jedem dieser Standorte durchgeführt werden kann.
  • Wie besprochen verwendet die fortlaufende Sicherheit eine Multifaktor-Authentifizierung und mehrere Vorrichtungen, um Teilnehmer eines RTC-Verwaltungssystems 301 kontinuierlich oder periodisch zu verifizieren. Im dargestellten Beispiel greift ein Teilnehmer 307-1/307-2 über eine Client-Vorrichtung 302-1/302-2 an den jeweiligen Client-Standorten 300-1/300-2 auf das RTC-Verwaltungssystem 301 zu und meldet sich bei diesem an, das auf einer oder mehreren Rechenressourcen 303 ausgeführt werden kann. Jede Form der Authentifizierung, wie z. B. Benutzername und Passwort, Passphrase, biometrische Sicherheit, USB YubiKey oder eine andere Technik, kann verwendet werden, um einem Teilnehmer den Zugriff oder die Anmeldung bei dem RTC-Verwaltungssystem 301 zu ermöglichen.
  • Zusätzlich zur Anmeldung eines Teilnehmers am RTC-Verwaltungssystem 301 über eine Client-Vorrichtung 302-1/302-2 kann sich der Benutzer auch selbst auf einer tragbaren Vorrichtung 304-1/304-2 authentifizieren, die sich im Besitz des Teilnehmers befindet und lokal zu der Client-Vorrichtung 302-1/302-2 ist, die der Teilnehmer zur Anmeldung am RTC-Verwaltungssystem 301 verwendet. Die Selbstauthentifizierung auf der tragbaren Vorrichtung 304-1/304-2 kann mit einem oder mehreren Selbstauthentifizierungsprotokollen durchgeführt werden, die für die tragbare Vorrichtung typisch sind, z. B. Gesichtserkennung, Fingerabdruck oder andere biometrische Verifizierung, Passcode usw.
  • Nach der Selbstauthentifizierung können die tragbare Vorrichtung 304 und die Client-Vorrichtung 302 miteinander verbunden werden, zum Beispiel über eine drahtlose Kurzstrecken-Kommunikationsverbindung wie Bluetooth, NFC usw. So kann der Teilnehmer beispielsweise eine in einem Speicher der tragbaren Vorrichtung gespeicherte Anwendung starten oder anderweitig ausführen, und die Anwendung kann eine Kommunikationsverbindung mit einer Anwendung herstellen, die auf der Client-Vorrichtung 302 ausgeführt wird. Während der RTC-Sitzung kann die auf der Client-Vorrichtung 302 ausgeführte Anwendung in regelmäßigen Abständen oder kontinuierlich Informationen (z. B. Keepalives oder kryptografische Handshakes) von der auf der tragbaren Vorrichtung 304 ausgeführten Anwendung abfragen oder erhalten, um zu überprüfen, ob sich die tragbare Vorrichtung innerhalb einer bestimmten Entfernung oder Reichweite der Client-Vorrichtung 302 befindet.
  • Darüber hinaus kann im Rahmen des Aufbaus der RTC-Kommunikationssitzung und der laufenden Überprüfung ein Bild des Teilnehmers von einer Kamera 305-1/305-2 der tragbaren Vorrichtung 304-1/304-2 erzeugt und an die Client-Vorrichtung 302-1/302-2 und/oder das RTC-Verwaltungssystem 301 gesendet werden. Das Bild kann verarbeitet werden, um die Identität des im Bild dargestellten Teilnehmers zu überprüfen, um zu bestätigen, dass sich der Teilnehmer innerhalb des definierten Abstands zu der Client-Vorrichtung befindet, und/oder um zu bestätigen, dass sich keine anderen Personen in einem Sichtfeld der Kamera der tragbaren Vorrichtung 304-1/304-2 befinden. Darüber hinaus können Standortinformationen, die von einem oder mehreren Elementen zur Standortbestimmung, wie z. B. einem GPS-Empfänger (Global Positioning Satellite) der tragbaren Vorrichtung 304-1/304-2, erhalten werden, auch zur Überprüfung des Standorts des Teilnehmers verwendet werden. Bilddaten, Standortdaten und/oder andere Informationen, die der Identität und/oder dem Standort eines Teilnehmers entsprechen oder dazu verwendet werden, diese zu verifizieren, werden hierin als Identitätsinformationen bezeichnet.
  • Bei der Initiierung und während einer RTC-Sitzung können Identitätsinformationen des Teilnehmers bereitgestellt werden, um den Standort und die Identität des Teilnehmers zu verifizieren. Nach der Verifizierung wird die RTC-Sitzung zwischen dem RTC-Verwaltungssystem 301 und der Client-Vorrichtung 302 aufgebaut oder ihre Fortsetzung zugelassen. Bewegt sich der Standort der tragbaren Vorrichtung jedoch über eine definierte Entfernung von einem Standort der Client-Vorrichtung 302 hinaus und/oder kann die Identität des Teilnehmers nicht anhand der Identitätsinformationen überprüft werden, wird die RTC-Sitzung für die Client-Vorrichtung 302 beendet.
  • In noch anderen Beispielen können die Identitätsinformationen weiterverarbeitet werden, um zu bestimmen, ob andere Personen an der Client-Vorrichtung 302 anwesend sind. Wenn andere Personen anwesend sind, die nicht ebenfalls Teilnehmer sind, wird die RTC-Verwaltungssitzung mit der Client-Vorrichtung 302 beendet.
  • In einigen Implementierungen können als eine weitere Form der Verifizierung auch Positionsinformationen und/oder Bewegungsdaten von einer oder mehreren am Körper tragbaren Vorrichtungen 306 in den Identitätsinformationen enthalten sein und verwendet werden, um den Standort und/oder die Identität des Teilnehmers 307 zu verifizieren. Beispielsweise können Standortinformationen, die von einer am Körper tragbaren Vorrichtung des Teilnehmers erhalten werden, als weiterer Verifizierungspunkt verwendet werden. In anderen Beispielen können Bewegungsdaten, Herzfrequenz, Blutdruck, Temperatur usw. als weitere Eingaben verwendet werden, um den Standort, die Anwesenheit und/oder die Identität des Teilnehmers 307 zu überprüfen.
  • Wie in 3B dargestellt, werden nach dem Aufbau der RTC-Sitzung kontinuierlich oder periodisch Identitätsinformationen von einer oder mehreren der Client-Vorrichtungen 302, tragbaren Vorrichtungen 304 und/oder am Körper tragbaren Vorrichtungen 306 gesendet und vom RTC-Verwaltungssystem 301 verarbeitet, um die Identität und den Standort des Teilnehmers 307 weiter zu überprüfen und entweder die RTC-Sitzung weiter zu aktivieren oder die RTC-Sitzung zu beenden. Zum Beispiel kann eine oder mehrere der Client-Vorrichtung 302-1, tragbare Vorrichtung(en) 304-1, und/oder am Körper tragbare Vorrichtung(en) 306-1 kontinuierlich oder periodisch Identitätsinformationen senden, die dem Teilnehmer 307-1 am Client-Standort 300-1 entsprechen, und das RTC-Verwaltungssystem 301, das auf der/den Rechenressource(n) 303 ausgeführt wird, kann die Identitätsinformationen verarbeiten, um die Identität und den Standort des Teilnehmers 307-1 zu verifizieren, so dass die RTC-Sitzung zwischen dem RTC-Verwaltungssystem 301 und der Client-Vorrichtung 302-1 fortgesetzt werden kann. Ebenso kann eine oder mehrere der Client-Vorrichtung 302-2, tragbare Vorrichtung(en) 304-2, und/oder am Körper tragbare Vorrichtung(en) 306-2 kontinuierlich oder periodisch Identitätsinformationen senden, die dem Teilnehmer 307-2 am Client-Standort 300-2 entsprechen, und das RTC-Verwaltungssystem 301, das auf der/den Rechenressource(n) 303 ausgeführt wird, kann die Identitätsinformationen verarbeiten, um die Identität und den Standort des Teilnehmers 307-2 zu verifizieren, so dass die RTC-Sitzung zwischen dem RTC-Verwaltungssystem 301 und der Client-Vorrichtung 302-2 fortgesetzt werden kann. Wenn die Identitätsinformationen entweder zwischen dem Client-Standort 300-1 und/oder dem Client-Standort 300-2 nicht verifiziert werden können, wird die RTC-Sitzung mit diesem Standort beendet, wodurch die Sicherheit zwischen dem RTC-Verwaltungssystem 301 und den anderen Client-Standorten aufrechterhalten wird.
  • In einigen Implementierungen können die offenbarten Implementierungen auch verwendet werden, um die Identität und den Standort eines Teilnehmers zu verifizieren, der auf das RTC-Verwaltungssystem 301 zugreift, so dass dem Teilnehmer aufgezeichnete oder gespeicherte Videodaten zur Betrachtung bereitgestellt werden können. Beispielsweise kann ein Redakteur ein Videosegment erzeugen und angeben, dass das Videosegment von einem Produzenten angesehen werden soll. Dieses Videosegment und der beabsichtigte Empfänger können vom RTC-Verwaltungssystem 301 verwaltet werden. Zu einem späteren Zeitpunkt, wenn der Produzent mit einer Client-Vorrichtung 302, einem tragbaren Vorrichtung 304 und/oder einer am Körper tragbaren Vorrichtung 306, wie oben beschrieben, auf das RTC-Verwaltungssystem 301 zugreift, so dass die Identität und der Standort des Produzenten verifiziert werden, kann das RTC-Verwaltungssystem 301 den Zugriff auf das Videosegment durch den Produzenten erlauben und die Identität und den Standort des Produzenten kontinuierlich verifizieren, während der Produzent das Inhaltssegment betrachtet.
  • In weiteren Beispielen kann eine Anwendung, die auf der Client-Vorrichtung ausgeführt wird, nach der Authentifizierung des Benutzers über die Client-Vorrichtung für den Zugriff auf das RTC-Verwaltungssystem auf unbefugte Aktivitäten überwachen und diese Aktivitäten unterbinden. So kann das RTC-Verwaltungssystem beispielsweise festlegen, dass Client-Vorrichtungen in einer RTC-Sitzung die Sitzung nicht aufzeichnen oder aufzeichnen können, was auf der Anzeige der Client-Vorrichtung angezeigt wird, usw. Während der Sitzung überwacht die Anwendung die Client-Vorrichtung auf derartige Aktivitäten und unterbindet diese. Wenn in anderen Beispielen die Aktivität versucht wird, kann die Anwendung, die auf der Client-Vorrichtung ausgeführt wird, die Aktivität verbieten und eine Benachrichtigung an das RTC-Verwaltungssystem senden. Das RTC-Verwaltungssystem kann nach Erhalt der Benachrichtigung die RTC-Sitzung mit dieser Client-Vorrichtung beenden und/oder andere Aktionen ausführen.
  • 4A bis 4B sind ein Übergangsdiagramm der Remote-Videozusammenarbeit in Echtzeit gemäß Implementierungen der vorliegenden Offenbarung. Der in den 4A bis 4B beschriebene Beispielübergang kann während einer beliebigen RTC-Sitzung und/oder eines anderen Austauschs zwischen zwei oder mehr Client-Vorrichtungen 402 und/oder einem RTC-Verwaltungssystem 401, das auf den Rechenressourcen 403 ausgeführt wird, durchgeführt werden. Auch wenn das in den 4A bis 4B beschriebene Beispiel eine Remote-Videozusammenarbeit in Echtzeit zwischen zwei Client-Vorrichtungen 402-1, 402-2 an verschiedenen Client-Standorten 400-1 und 400-2 und über ein Netzwerk 450 beschreibt, kann eine beliebige Anzahl von Client-Vorrichtungen 402 und Client-Standorten 400 in die offenbarten Implementierungen einbezogen und verwendet werden.
  • In dem beschriebenen Beispiel streamt die Client-Vorrichtung 402-1 ein Video, z. B. ein Vorab-Filmproduktionsvideo, von der Client-Vorrichtung 402-1, die hierin als Quellvorrichtung bezeichnet wird, zur Client-Vorrichtung 402-2, die hierin als Zielvorrichtung bezeichnet wird. Wie im Stand der Technik bekannt ist, ermöglichen bestehende Systeme die entfernte Zusammenarbeit oder gemeinsame Nutzung von Videos von einer Vorrichtung zu einem anderen unter Verwendung von beispielsweise webRTC. Beispielsweise kann sich während der Filmproduktion ein Redakteur an einer Quell-Client-Vorrichtung 402-1 remote mit einem Produzenten an einer Ziel-Client-Vorrichtung 402-2 verbinden und der Redakteur kann Videosegmente mit einer ersten Framerate und einer ersten Komprimierung unter Verwendung eines ersten Videokanals zwischen der Quell-Client-Vorrichtung und der Ziel-Client-Vorrichtung zur Überprüfung und Zusammenarbeit mit dem Produzenten streamen. Auf der Client-Vorrichtung 402-1 kann Streamer-Software eigenständig oder in einen Webbrowser eingebettet ausgeführt werden. Diese Streamer-Software kann eine Datei direkt streamen, kann ein Video streamen, das von einem externen Aufnahmegerät aufgenommen wurde, das mit einer Videoquelle verbunden ist, oder kann eine Live-Aufnahme eines Bildschirms, eines Teils eines Bildschirms oder eines Fensters einer laufenden Anwendung auf dem Bildschirm streamen.
  • Wie bei dieser Zusammenarbeit üblich, können der Produzent und/oder der Redakteur verlangen oder veranlassen, dass das Video an einem bestimmten Punkt im Video angehalten wird, was hierin als Trigger-Ereignis bezeichnet wird. Beispielsweise kann der Produzent dem Editor sagen, dass er das Video pausieren soll. Während das Video angehalten ist, können der Produzent und der Redakteur zusammenarbeiten und das Video diskutieren, visuelle Illustrationen auf dem angehaltenen Video präsentieren, die über einen zweiten Videokanal übertragen und als Überlagerungen auf dem Streaming-Video präsentiert werden können usw. In Bei bestehenden Systemen streamt die webRTC-Sitzung das angehaltene Video weiterhin über den ersten Videokanal und mit derselben Framerate und Komprimierung, auch wenn das Video angehalten ist und sich nicht ändert.
  • Im Vergleich dazu wird bei den offenbarten Implementierungen bei der Erkennung eines Triggerereignisses, z. B. einer Pause des Videos, wie in 4A dargestellt, ein hochaufgelöstes Bild des angehaltenen Videos auf der Quell-Client-Vorrichtung 402-1 erzeugt und von der Quell-Client-Vorrichtung 402-1 an die Ziel-Client-Vorrichtung 402-2 gesendet, und das Streaming des Videos mit der Framerate und Komprimierung wird beendet. Beispielsweise kann ein Screenshot mit hoher Auflösung der Anzeige des angehaltenen Videos auf der Anzeige der Quellen-Client-Vorrichtung 402-1 als Bild mit hoher Auflösung erhalten werden. In einem anderen Beispiel kann eine Anwendung, die auf der Quell-Client-Vorrichtung ausgeführt wird, mit einem Videoplayer oder einer Editor-Anwendung auf der Quell-Client-Vorrichtung 402-1 kommunizieren, die das Video streamt, und der Videoplayer oder die Editor-Anwendung kann ein hochaufgelöstes Bild der angehaltenen Instanz des Videos erzeugen und bereitstellen. In einigen Implementierungen kann das hochaufgelöste Bild ein unkomprimiertes oder Rohbild eines Frames des Videos sein, das auf der Anzeige dargestellt wird, wenn das Video angehalten wird.
  • Fortfahrend mit dem Beispiel wird das hochaufgelöste Bild von der Quellen-Client-Vorrichtung 402-1 an die Ziel-Client-Vorrichtung 402-2 gesendet, zum Beispiel durch das RTC-Verwaltungssystem 401, das auf Rechenressource(n) 403 ausgeführt wird, wodurch die Sicherheit der RTC-Sitzung, wie oben beschrieben, aufrechterhalten wird, und die Ziel-Client-Vorrichtung 402-2 oder eine darauf ausgeführte Anwendung kann das hochaufgelöste Bild auf der Anzeige der Client-Vorrichtung anzeigen, anstatt das angehaltene Video anzuzeigen. Als Ergebnis wird dem Teilnehmer, wie beispielsweise dem Produzenten, ein hochaufgelöstes Bild des angehaltenen Videos statt des im Videostream enthaltenen komprimierten Bildes präsentiert. Außerdem entfällt das kontinuierliche Streamen des Videos mit der ersten Framerate und ersten Komprimierung, wodurch Rechen- und Netzwerkkapazität frei werden. Die Teilnehmer können dann an dem hoch aufgelösten Bild arbeiten, als ob es sich um das angehaltene Video handeln würde, z. B. indem sie über das hoch aufgelöste Bild diskutieren und/oder es mit visuellen Anmerkungen versehen.
  • Mit Bezug auf 4B, wenn ein zweites Triggerereignis, z. B. das Abspielen des Videos, erkannt wird, setzt die Quell-Client-Vorrichtung 402-1 das Streaming des Videos mit der ersten Framerate und der ersten Komprimierung fort. Gleichermaßen entfernt die Ziel-Client-Vorrichtung 402-2 beim Empfangen des wiederaufgenommenen Videostreams das hochaufgelöste Bild von der Anzeige der Ziel-Client-Vorrichtung 402-2 und nimmt die Präsentation des fortgesetzten Videostreams wieder auf, sobald er empfangen wird.
  • Der Wechsel zwischen Videostreaming und der Darstellung eines hochaufgelösten Bildes kann bei jedem Triggerereignis (z. B. Pause/Wiedergabe) erfolgen und mehrmals während einer RTC-Sitzung auftreten.
  • 5A bis 5B sind ein weiteres Übergangsdiagramm einer anderen Remote-Videozusammenarbeit in Echtzeit gemäß Implementierungen der vorliegenden Offenbarung. Der in den 5A bis 5B beschriebene Beispielübergang kann während einer beliebigen RTC-Sitzung und/oder eines anderen Austauschs zwischen zwei oder mehr Client-Vorrichtungen 502 und/oder einem RTC-Verwaltungssystem 501 durchgeführt werden. Auch wenn das in den 5A bis 5B beschriebene Beispiel eine Remote-Videozusammenarbeit in Echtzeit zwischen zwei Client-Vorrichtungen 502-1, 502-2 an verschiedenen Client-Standorten 500-1 und 500-2 beschreibt, kann eine beliebige Anzahl von Client-Vorrichtungen 502 und Client-Standorten 500 in die offenbarten Implementierungen einbezogen und verwendet werden.
  • In dem beschriebenen Beispiel streamt die Client-Vorrichtung 502-1 ein Video, z. B. ein Vorab-Filmproduktionsvideo, von der Client-Vorrichtung 502-1, die hierin als Quellvorrichtung bezeichnet wird, zur Client-Vorrichtung 502-2, die hierin als Zielvorrichtung bezeichnet wird. Wie im Stand der Technik bekannt ist, ermöglichen bestehende Systeme die entfernte Zusammenarbeit oder gemeinsame Nutzung von Videos von einer Vorrichtung zu einem anderen unter Verwendung von beispielsweise webRTC. Beispielsweise kann sich während der Filmproduktion ein Redakteur an einer Quell-Client-Vorrichtung 502-1 fern mit einem Produzenten an einer Ziel-Client-Vorrichtung 502-2 verbinden und der Redakteur kann Videosegmente mit einer ersten Framerate und einer ersten Komprimierung unter Verwendung eines ersten Videokanals zwischen der Quell-Client-Vorrichtung und der Ziel-Client-Vorrichtung zur Überprüfung und Zusammenarbeit mit dem Produzenten streamen. Beispielsweise kann die erste Framerate vierundzwanzig Frames pro Sekunde sein und der erste Codec kann beispielsweise H.265, H.264, MPEG4, VP9, AV1 usw. sein.
  • Wie bei dieser Zusammenarbeit üblich, können der Produzent und/oder der Redakteur verlangen oder veranlassen, dass das Video an einem bestimmten Punkt im Video angehalten wird (Triggerereignis). Beispielsweise kann der Produzent dem Editor sagen, dass er das Video pausieren soll. Während das Video angehalten ist, können der Produzent und der Redakteur zusammenarbeiten und das Video diskutieren, visuelle Anmerkungen auf dem angehaltenen Video präsentieren, die über einen zweiten Videokanal übertragen und als Überlagerungen auf dem Streaming-Video präsentiert werden können usw. Bei bestehenden Systemen streamt die webRTC-Sitzung das angehaltene Video weiterhin über den ersten Videokanal und mit der ersten Framerate und der ersten Komprimierung, auch wenn das Video angehalten ist und sich nicht ändert.
  • Im Vergleich dazu kann bei den offenbarten Implementierungen bei Erkennung eines Triggerereignisses, z. B. einer Pause des Videos, wie in 5A dargestellt, das Videostreaming auf eine zweite Framerate und einen zweiten Codec mit einer anderen Komprimierung umgestellt werden, und das angehaltene Video kann mit der zweiten Framerate und der zweiten Komprimierung gestreamt werden, während es angehalten ist. Beispielsweise kann die zweite Framerate niedriger sein als die erste Framerate und die zweite Komprimierung kann niedriger sein als die erste Komprimierung. In einigen Implementierungen kann die zweite Komprimierung keine Komprimierung sein, sodass das Video unkomprimiert mit der zweiten Framerate gestreamt wird, die eine sehr niedrige Framerate sein kann. Beispielsweise kann die zweite Framerate fünf Frames pro Sekunde sein. Das Verringern der Framerate und der Komprimierung führt zu einer höher aufgelösten Darstellung des angehaltenen Videos auf der Zielvorrichtung. Wie oben diskutiert, ist das Ändern der Framerate und Komprimierung eine Reaktion auf ein Triggerereignis. In einem solchen Fall kann die verfügbare Bandbreite unverändert bleiben.
  • Um mit dem Beispiel fortzufahren, wird das Video mit niedrigerer Framerate und niedrigerer Komprimierung von der Quell-Client-Vorrichtung 502-1 zur Ziel-Client-Vorrichtung 502-2 gestreamt, zum Beispiel durch das RTC-Verwaltungssystem 501, das auf der/den Rechenressource(n) 503 ausgeführt wird, wodurch die Sicherheit der RTC-Sitzung aufrechterhalten wird, kann die Ziel-Client-Vorrichtung 502-2 oder eine darauf ausgeführte Anwendung beim Empfang des gestreamten Videos das gestreamte Video auf der Anzeige der Ziel-Client-Vorrichtung darstellen. Bei einer solchen Implementierung muss die Ziel-Client-Vorrichtung sich keiner Änderung bewusst sein und fährt einfach damit fort, das gestreamte Video so zu präsentieren, wie es empfangen wird. Da das Video eine niedrigere Komprimierung aufweist, wird dem Teilnehmer, wie beispielsweise dem Produzenten, eine Präsentation des angehaltenen Videos mit einer höheren Auflösung präsentiert. Da das Video angehalten ist und sich nicht ändert, verursacht die niedrigere Framerate außerdem keine Pufferung und/oder andere negative Auswirkungen. Die Teilnehmer können an dem gestreamten Video mit höherer Auflösung zusammenarbeiten, indem sie beispielsweise über das hochaufgelöste Bild diskutieren und/oder es mit visuellen Anmerkungen versehen.
  • Mit Bezug auf 5B, wenn ein zweites Triggerereignis, z. B. das Abspielen des Videos, erkannt wird, setzt die Quell-Client-Vorrichtung 502-1 das Streaming des Videos mit der ersten Framerate und der ersten Komprimierung fort. Da das Video kontinuierlich gestreamt wurde, wenn auch mit einer niedrigeren Framerate und geringerer Komprimierung, während es angehalten wurde, kann die Ziel-Client-Vorrichtung einfach damit fortfahren, das gestreamte Video so darzustellen, wie es empfangen wird.
  • Der Austausch zwischen Videostreaming mit der ersten Framerate und den ersten Komprimierungen und Videostreaming mit der zweiten Framerate und den zweiten Komprimierungen kann bei jedem Triggerereignis, wie z. B. Pause/Wiedergabe, erfolgen und kann während einer RTC-Sitzung mehrmals auftreten.
  • 6 ist ein Flussdiagramm eines beispielhaften Farbanpassungsprozesses 600 einer Client-Vorrichtung gemäß Implementierungen der vorliegenden Offenbarung. Der beispielhafte Prozess 600 beginnt nach dem Empfang eines Bildes, das eine Darstellung einer Farbkarte, wie oben erörtert, und eine Darstellung von Farbbalken auf einer Anzeige einer Client-Vorrichtung, wie in 602, einschließt. Wie bereits erwähnt, kann ein Teilnehmer beispielsweise eine Farbkarte neben die Anzeige einer Client-Vorrichtung halten und mit einer tragbaren Vorrichtung ein Bild erzeugen, das die Farbkarte und die Anzeige der Client-Vorrichtung enthält, auf dem Farbbalken dargestellt werden.
  • Beim Empfang des Bildes wird das Bild verarbeitet, um Unterschiede zwischen den auf der Farbkarte präsentierten Farben und den Farben der auf der Anzeige der Client-Vorrichtung präsentierten Farbbalken zu bestimmen, wie in 604. Beispielsweise können ein oder mehrere Farbanpassungsalgorithmen verwendet werden, um Farben der Farbkarte und der Farbbalken zu vergleichen, die auf der Anzeige der Client-Vorrichtung dargestellt werden, um Unterschiede zwischen ihnen zu bestimmen. Die empfangende Anwendung kann einen bestimmten Farbkanal, wie z. B. Blau, isolieren und Unterschiede zwischen den empfangenen Blaukanalbildern erkennen. Die empfangende Anwendung kann das Umgebungslicht in der nach vorne gerichteten Kamera mit dem Farbbalken und den Karteninformationen vergleichen, die von der nach hinten gerichteten Kamera empfangen werden. Der Verarbeitungsalgorithmus kann auf einer ähnlichen Vorrichtung auf beiden Seiten laufen, z. B. auf einem bestimmten Smartphone-Modell mit einem identischen Kamerasystem, und so einen ziemlich standardisierten Vergleich sowohl der Farbkalibrierung des Bildschirms als auch der angezeigten Farben unter den Lichtverhältnissen der Umgebung auf beiden Seiten liefern. Die empfangende Anwendung kann mit der zu kalibrierenden Vorrichtung kommunizieren und diese veranlassen, die angezeigten Farbbalken oder andere Informationen zu ändern (die Farbbalken können jedes beliebige Bild für die Kalibrierung enthalten) und die Farben, das Farbprofil der Vorrichtung oder die Helligkeit oder den Kontrast oder andere Bildeinstellungen des angeschlossenen Monitors zu ändern oder den Benutzer darauf hinzuweisen, dass er eine der oben genannten Einstellungen manuell ändern soll. Die empfangende Vorrichtung kann die auf der zu kalibrierenden Vorrichtung angezeigten Farbeinstellungen so manipulieren, dass ein sich ändernder Farbbereich angezeigt wird, so dass ein vollständiger Bereich von beiden Seiten getestet werden kann, und kann einen Benutzer anweisen, die empfangende Vorrichtung näher an den Bildschirm heranzubringen oder von ihm zu entfernen, um das Umgebungslicht anzupassen, z. B. durch Ausschalten oder Einschalten der Lichter im RTC-Raum, durch Schließen oder Öffnen der Jalousien und so weiter.
  • Basierend auf der bestimmten Differenz wird wie bei 606 eine Gamma-Anpassungsanweisung für die Client-Vorrichtung generiert. Wie im Stand der Technik bekannt ist, steuert das Gamma einer Anzeige die Gesamthelligkeit eines Bildes. Gamma repräsentiert eine Beziehung zwischen einer Helligkeit eines Pixels, wie es auf einer Anzeige erscheint, und dem numerischen Wert des Pixels. Durch Anpassen des Gammas der Anzeige kann der Unterschied zwischen den auf der Anzeige angezeigten Farbbalken und der Farbkarte verringert werden. Dementsprechend wird die Gamma-Anpassungsanweisung an die Client-Vorrichtung zur Anpassen des Gammas der Anzeige der Client-Vorrichtung gesendet, wie in 608.
  • Wie oben angemerkt, kann der beispielhafte Prozess 600 viele Male durchgeführt werden, bis der Unterschied zwischen der Farbkarte und den Farbbalken, die auf der Anzeige der Client-Vorrichtung dargestellt werden, vernachlässigbar ist oder unter einem definierten Schwellenwert liegt. Der Schwellenwert kann beispielsweise in Abhängigkeit von den Anzeigefähigkeiten der Anzeige der Client-Vorrichtung, dem zu streamenden Video usw. variieren.
  • In einigen Implementierungen können anstelle oder zusätzlich zur Anpassung des Gammas auf der Grundlage der Farbkarten auch die auf den Anzeigen mehrerer verschiedener Client-Vorrichtungen dargestellten Farbbalken verglichen und Gamma-Anpassungsanweisungen erzeugt und an diese Client-Vorrichtungen gesendet werden, um diese Vorrichtungen so anzupassen, dass die auf den Anzeigen dieser Client-Vorrichtungen dargestellten Farbbalken korreliert sind.
  • 7 ist ein Flussdiagramm eines beispielhaften Benutzeridentitätsverifizierungsprozesses 700 gemäß Implementierungen der vorliegenden Offenbarung. Der beispielhafte Prozess 700 kann jederzeit während einer RTC-Sitzung und separat für jeden Teilnehmer der RTC-Sitzung ausgeführt werden, um die Identität von Benutzern, die an der RTC-Sitzung teilnehmen, kontinuierlich oder periodisch zu verifizieren, wodurch die Sicherheit der RTC-Sitzung gewährleistet wird.
  • Der beispielhafte Prozess 700 beginnt, wenn sich ein Teilnehmer bei dem RTC-Verwaltungssystem authentifiziert, wie in 702. Beispielsweise kann sich ein Teilnehmer, der eine Client-Vorrichtung verwendet, in das RTC-Verwaltungssystem einloggen, indem er einen Benutzernamen und ein Passwort und/oder andere Nachweisformen bereitstellt.
  • Zusätzlich dazu, dass sich der Teilnehmer direkt beim RTC-Verwaltungssystem authentifiziert, empfängt der Beispielprozess eine sekundäre Vorrichtungsauthentifizierung, wie in 704. Die sekundäre Authentifizierung kann von einer beliebigen sekundären Vorrichtung empfangen werden, z. B. von einer tragbaren Vorrichtung, einer am Körper tragbaren Vorrichtung usw. Ebenso kann die sekundäre Authentifizierung eine beliebige Authentifizierungstechnik sein, die von der sekundären Vorrichtung und/oder einer auf der sekundären Vorrichtung ausgeführten Anwendung durchgeführt wird, um die Identität des Teilnehmers zu überprüfen.
  • Sobald sich der Teilnehmer beim RTC-Verwaltungssystem selbst authentifiziert hat und eine sekundäre Autorisierung empfangen wurde, können Identitätsinformationen, die dem Teilnehmer entsprechen, auch von der sekundären Vorrichtung empfangen werden, wie in 706. Zu den Identitätsinformationen können unter anderem Standortinformationen gehören, die dem Standort der sekundären Vorrichtung und/oder der Client-Vorrichtung entsprechen, die in drahtloser Kommunikation mit der sekundären Vorrichtung stehen kann, biometrische Informationen des Benutzers (z. B. Herzfrequenz, Blutdruck, Temperatur usw.), Bewegungsdaten des Benutzers, Bilder des Benutzers usw.
  • In einigen Implementierungen kann das System das biometrische Bild einer Person speichern, die es nicht identifiziert hat, der jedoch von einem anderen autorisierten Benutzer Zutritt zu einem RTC-Konferenzraum eines RTC-Verwaltungssystems gewährt wurde. Anschließend kann das System dieselbe Person unter Verwendung der gespeicherten Biometrie erneut identifizieren. Das System erstellt einen Identitätsdatensatz mit Metadaten dieses identifizierten, anonymen, authentifizierten, aber nicht identifizierten Benutzers. Das System kann für diesen nicht identifizierten Benutzer auch jede Zeit verfolgen, zu der der Benutzer auf das System zugreift und in das System eingelassen wird, so dass, wenn der Benutzer später identifiziert wird, die früheren Zugriffe mit dem Benutzer abgeglichen werden. Dies trägt dazu bei, einen Prüfpfad für den Fall zu erhalten, dass auf Assets zugegriffen wird und später die Personen, die darauf zugegriffen haben, identifiziert werden müssen.
  • Wenn die Identitätsinformationen empfangen werden, verarbeitet der beispielhafte Prozess 700 die empfangenen Identitätsinformationen, um sowohl den Standort des Teilnehmers als auch die Identität des Teilnehmers zu verifizieren, wie in 708. So kann beispielsweise der Standort der an der RTC-Sitzung beteiligten Client-Vorrichtung während der anfänglichen Authentifizierung oder über die von der tragbaren Vorrichtung erhaltenen Informationen bestimmt werden. Ebenso können Standortinformationen von der tragbaren Vorrichtung eingeholt werden, um zu überprüfen, ob sich die tragbare Vorrichtung nicht mehr als eine bestimmte Entfernung (z. B. fünf Fuß) vom Standort der Client-Vorrichtung entfernt hat. Ebenso können auch von der tragbaren Vorrichtung generierte Identitätsinformationen verarbeitet werden, um zu verifizieren, dass der Teilnehmer bei der tragbaren Vorrichtung und somit der Client-Vorrichtung verbleibt.
  • Wenn bestimmt wird, dass die Identität und der Standort des Teilnehmers verifiziert sind, wie in Entscheidungsblock 710, wird eine Bestimmung dahingehend vorgenommen, ob ein anderer Körper oder Person in den Identitätsinformationen erfasst wird, wie in 712. Wenn beispielsweise die Identitätsinformationen Bilddaten des Teilnehmers enthalten, können die Bilddaten weiterverarbeitet werden, um zu bestimmen, ob andere Personen als der Teilnehmer in den Bilddaten dargestellt sind. Als weiteres Beispiel kann ein Bewegungserkennungselement, wie z. B. ein Infrarotscanner, SONAR (Sound Navigation and Ranging, usw.) der tragbaren Vorrichtung und/oder der Client-Vorrichtung Entfernungsdaten erzeugen, und diese Daten können in die Identitätsinformationen aufgenommen und verwendet werden, um festzustellen, ob andere Personen anwesend sind. Wenn festgestellt wird, dass keine anderen Körper oder Personen erkannt werden, wird der Zugriff auf die RTC-Sitzung durch die Client-Vorrichtung hergestellt oder aufrechterhalten, wie in 714.
  • Wird dagegen in Entscheidungsblock 710 festgestellt, dass entweder die Identität des Benutzers oder der Standort des Benutzers nicht verifiziert wurde und/oder dass eine andere Stelle oder Person in den Identitätsinformationen erkannt wurde, wird in Entscheidungsblock 712 der Zugriff auf die RTC-Sitzung durch die Client-Vorrichtung verweigert oder beendet, wie in 718.
  • Schließlich bestimmt der beispielhafte Prozess 700 auch, ob die RTC-Sitzung abgeschlossen ist, wie in 716. Wenn bestimmt wird, dass die RTC-Sitzung nicht abgeschlossen wurde, kehrt der beispielhafte Prozess 700 zu Block 706 zurück und fährt fort. Wenn bestimmt wird, dass die RTC-Sitzung abgeschlossen ist, wird der Zugriff auf die RTC-Sitzung wie in 718 beendet.
  • 8 ist ein Flussdiagramm eines beispielhaften Kommunikations-Videokollaborationsprozess in Echtzeit 800 gemäß Implementierungen der vorliegenden Offenbarung.
  • Der beispielhafte Prozess 800 beginnt mit dem Aufbau einer RTC-Sitzung wie bei 802. Bei Initiierung der RTC-Sitzung wird Video mit einer ersten Framerate (z. B. 25 Frames pro Sekunde) und einer ersten Komprimierung von einer Quell-Client-Vorrichtung zu einer oder mehreren Ziel-Client-Vorrichtungen gestreamt, wie in 804.
  • Irgendwann während der RTC-Sitzung wird ein erstes Triggerereignis wie eine Pause des gestreamten Videos erkannt, wie in 806. Beispielsweise kann ein Redakteur an der Quell-Client-Vorrichtung das gestreamte Video anhalten. Als weiteres Beispiel kann ein Teilnehmer an einer der Ziel-Client-Vorrichtungen veranlassen, dass das gestreamte Video angehalten wird.
  • Bei Erkennung des Triggerereignisses wird wie bei 808 ein hochaufgelöstes Bild des angehaltenen Videos zum Zeitpunkt des ersten Triggerereignisses erzeugt. Als hochaufgelöstes Bild kann z. B. ein Screenshot des Bildschirms der Quell-Client-Vorrichtung mit voller Auflösung erstellt werden, der das angehaltene Video einschließt. Als ein weiteres Beispiel kann eine Anwendung, die auf der Quell-Client-Vorrichtung ausgeführt wird, die das Streaming-Video präsentiert, ein hochaufgelöstes Bild des Videos erzeugen, wenn sie angehalten wird.
  • Außerdem wird das Streamen des nun angehaltenen Videos beendet, wie in 810, und das hochaufgelöste Bild wird von der Quell-Client-Vorrichtung an die Ziel-Client-Vorrichtung(en) gesendet und auf der Anzeige der Ziel-Client-Vorrichtung(en) alsein Overlay oder anstelle des beendeten Streaming-Videos dargestellt, wie in 812. Wie oben besprochen, können die Teilnehmer der RTC-Sitzung weiter zusammenarbeiten und das Video diskutieren, und das hochaufgelöste Bild stellt jedem Teilnehmer eine Darstellung mit höherer Auflösung des pausierten Punkts des Videos bereit.
  • Irgendwann während der RTC-Sitzung wird wie in 814 ein zweites Triggerereignis, wie z. B. ein Abspielen oder Fortsetzen des Abspielens des Videos, erkannt. Beispielsweise kann ein Teilnehmer an der Quell-Client-Vorrichtung das Abspielen des Videos an der Quell-Client-Vorrichtung fortsetzen. Als weiteres Beispiel kann ein Teilnehmer an einer der Ziel-Client-Vorrichtungen veranlassen, dass das Video wieder abgespielt wird.
  • Unabhängig von der Quelle des zweiten Triggerereignisses wird das Streamen des Videos von der Quell-Client-Vorrichtung mit der ersten Framerate und der ersten Komprimierung fortgesetzt, wie in 816. Ebenso wird das hochaufgelöste Bild von der Anzeige der Ziel-Client-Vorrichtung(en) entfernt und das fortgesetzte Streaming-Video wird auf diesen Anzeigen wie in 818 präsentiert.
  • Es versteht sich, dass der beispielhafte Prozess 800 mehrere Male während einer RTC-Sitzung durchgeführt werden kann, beispielsweise jedes Mal, wenn ein Triggerereignis erfasst wird.
  • 9 ist ein Flussdiagramm eines weiteren beispielhaften Kommunikations-Videokollaborationsprozess 900 in Echtzeit gemäß Implementierungen der vorliegenden Offenbarung.
  • Der beispielhafte Prozess 900 beginnt mit dem Aufbau einer RTC-Sitzung wie bei 902. Bei Initiierung der RTC-Sitzung wird Video mit einer ersten Framerate (z. B. 25 Frames pro Sekunde) und einer ersten Komprimierung von einer Quell-Client-Vorrichtung zu einer oder mehreren Ziel-Client-Vorrichtungen gestreamt, wie in 904.
  • Irgendwann während der RTC-Sitzung wird ein erstes Triggerereignis wie eine Pause des gestreamten Videos erkannt, wie in 906. Beispielsweise kann ein Redakteur an der Quell-Client-Vorrichtung das gestreamte Video anhalten. Als weiteres Beispiel kann ein Teilnehmer an einer der Ziel-Vorrichtungen veranlassen, dass das gestreamte Video angehalten wird.
  • Bei Erkennung des Triggerereignisses werden die Framerate und die Komprimierung des Streaming-Videos wie in 908 auf eine zweite Framerate und eine zweite Komprimierung geändert. Beispielsweise kann die zweite Framerate niedriger sein als die erste Framerate (z. B. fünf Frames pro Sekunde) und die zweite Komprimierung kann geringer sein als die erste Komprimierung (z. B. keine Komprimierung). Infolgedessen wird das Streaming des Videos fortgesetzt, jedoch mit einer höheren Auflösung, während es angehalten wird. Wie oben besprochen, können die Teilnehmer der RTC-Sitzung weiterhin zusammenarbeiten und das Video diskutieren, und das gestreamte hochaufgelöste Video stellt jedem Teilnehmer eine Darstellung des Videos mit höherer Auflösung bereit, während es angehalten ist.
  • Irgendwann während der RTC-Sitzung wird wie in 910 ein zweites Triggerereignis, wie z. B. ein Abspielen oder Fortsetzen des Abspielens des Videos, erkannt. Beispielsweise kann ein Teilnehmer an der Quell-Client-Vorrichtung das Abspielen des Videos an der Quell-Client-Vorrichtung fortsetzen. Als weiteres Beispiel kann ein Teilnehmer an einer der Ziel-Client-Vorrichtungen veranlassen, dass das Video wieder abgespielt wird.
  • Als Reaktion auf das zweite Triggerereignis wird das Streamen des Videos mit der ersten Framerate und der ersten Komprimierung fortgesetzt, wie in 911.
  • Es versteht sich, dass der beispielhafte Prozess 900 mehrere Male während einer RTC-Sitzung durchgeführt werden kann, beispielsweise jedes Mal, wenn ein Triggerereignis erfasst wird. Ebenso können die Beispielprozesse 800/900 mit jeder Netzwerkbandbreite durchgeführt werden, die Video-Streaming unterstützt, und die Bandbreite kann während der RTC-Sitzung im Wesentlichen unverändert bleiben. Darüber hinaus können ein oder mehrere CODECs (z. B. AV1, H.265, MPEG4 usw.) verwendet werden, um das Video auf die erste Komprimierung und/oder die zweite Komprimierung zu komprimieren. Während sich das obige Beispiel auf das Video bezieht, das von einer Quell-Client-Vorrichtung gestreamt wird, kann das Video ferner in anderen Implementierungen von dem RTC-Verwaltungssystem zu einer oder mehreren Ziel-Client-Vorrichtungen gestreamt werden. In einem solchen Beispiel kann das RTC-Verwaltungssystem bei Erkennung eines Triggerereignisses das Streaming-Video anhalten, ein hochaufgelöstes Bild erzeugen und an die eine oder die mehreren Client-Vorrichtungen senden. Alternativ kann das RTC-Verwaltungssystem den Videostream von einer ersten Framerate und einer ersten Komprimierung zu einer zweiten Framerate und einer zweiten Komprimierung ändern, die sich von der ersten Framerate und der ersten Komprimierung unterscheiden, wie oben besprochen. Alternativ kann das RTC-Verwaltungssystem eine unkomprimierte oder verlustfrei komprimierte oder Rohversion des Videostreams oder eines Teils des Videostreams um einen interessierenden Bereich liefern, der durch das Triggerereignis angezeigt wird.
  • Zusätzlich zu den oben genannten Implementierungen können Benutzer das RTC-Verwaltungssystem unter Verwendung einer API zu einem Online-Inhaltsverwaltungssystem oder einem Cloud-Speichersystem leiten. Die offenbarten Implementierungen können sich beispielsweise mit DROPBOX, AMAZON WEB SERVICES, MICROSOFT AZURE usw. verbinden. Der Cloud-Dienst kann ein einfacher Speicher oder ein komplexerer Content-Verwaltungsdienst sein. Das RTC-Verwaltungssystem kann durch eine Liste von Dateien navigieren und Metadaten über sie anzeigen sowie sie streamen, gemeinsam teilen usw. So können die beschriebenen Implementierungen beispielsweise Dateien aus einem Originalformat umwandeln (nicht mit dem Streamer des Cloud-Speichers, sondern durch Kontrolle und Transkodierung der Datei). Alternativ können die offenbarten Implementierungen auf das Cloud-Speichersystem zugreifen oder sich darin anmelden und es Benutzern ermöglichen, Dateien von diesem System gemeinsam zu nutzen.
  • Ohne Einschränkung können die offenbarten Implementierungen auch auf andere Medienvermögensverwalter angewendet werden. Beispielsweise können Benutzer ein anderes Content-Verwaltungssystem in das RTC-Verwaltungssystem wie ADOBE PIX SYSTEM oder FRAME.IO einbetten und der Benutzer kann die entsprechende Webseite ausführen, aber die Webseite wird remote auf dem RTC-Verwaltungssystem gerendert und dann dorthin an alle Clients gestreamt.
  • In noch anderen Beispielen kann eine RTC-Anwendung auf eine Client-Vorrichtung ausgeführt werden, das Screenshots oder Dateien für Echtzeit-Streaming an das RTC-Verwaltungssystem neu codiert. Wie weiter unten erläutert, verbleiben die Dateien auf der Client-Vorrichtung, und die auf dieser Client-Vorrichtung ausgeführte RTC-Anwendung kann die Streaming-Software zu einem Ordner auf dieser Client-Vorrichtung leiten. Die Streaming-Software stellt eine Verbindung mit dem RTC-Verwaltungssystem her und stellt dem RTC-Verwaltungssystem eine Liste aller Dateien bereit, auf die auf der Client-Vorrichtung zugegriffen werden kann. Das RTC-Verwaltungssystem ermöglicht es anderen Client-Vorrichtungen, diese anderen Dateien, die im Speicher anderer Client-Vorrichtungen gespeichert sind, einzusehen und darauf zuzugreifen sowie mit den auf diesen anderen Client-Vorrichtungen gespeicherten Dateien zu interagieren.
  • So kann beispielsweise ein Benutzer auf einer Client-Vorrichtung eine Vorschau einer Datei anfordern, die physisch auf einer anderen Client-Vorrichtung gespeichert ist. Durch die Vorschau der Datei wird eine dynamische Live-Streaming-Sitzung von der Streaming-Software bis zum RTC-Verwaltungssystem des RTC-Raums und wieder zurück zur anfragenden Client-Vorrichtung und allen anderen Client-Vorrichtungen, die auf den RTC-Raum zugreifen (siehe unten), aufgebaut. Die Befehle zum Abspielen, Anhalten, Zurückspulen, Vorspulen usw. werden von Zuschauern im RTC-Raum ferngesteuert. Auf diese Weise kann jede Client-Vorrichtung, die auf den RTC-Raum zugreift, ohne Verzögerung durch eine große Anzahl von Remote-Dateien navigieren und eine Vorschau anzeigen, als befänden sich diese Dateien auf ihrem eigenen Rechner. Somit kann eine Inhaltsbibliothek mit einer beliebigen Anzahl von Dateien effektiv sofort geteilt werden, und es müssen nur die Metadaten zu den Dateien (Dateiname, Größe, Zeitpunkt der Erstellung, Miniaturansichten usw.) hochgeladen werden. Diese Metadaten können ebenfalls gestreamt werden, sodass im Laufe der Zeit die gesamte Metadatenbibliothek umfassender bereitgestellt wird.
  • Die Datei-Streamer-Software kann von den Teilnehmern des RTC-Raums von jeder einzelnen Client-Vorrichtung aus ferngesteuert werden. Eine solche Konfiguration ist insofern sicher, als sie nur den Ordner freigibt, der von der Person bestimmt wurde, die den Streamer betreibt. Der Datei-Streamer gibt alle Dateien innerhalb des festgelegten Ordners und der Unterordner frei, und nur die festgelegten Dateitypen werden freigegeben. Jede Client-Vorrichtung kann einen oder mehrere Ordner und/oder Dateien bezeichnen. Ebenso kann die Software des RTC-Verwaltungssystems als „Dienst“ des Betriebssystems ausgeführt werden, so dass sie kontinuierlich arbeitet. Darüber hinaus kann das RTC-Verwaltungssystem die aktuelle Bandbreite zum RTC-Raum und zu jeder Client-Vorrichtung überwachen und die Vorschau und/oder die Streaming-Auflösung automatisch so kalibrieren, dass der gestreamte Inhalt in Echtzeit in die verfügbare Bandbreite passt.
  • Mehrere Teilnehmer können ihre Inhaltsbibliotheken unabhängig voneinander für denselben RTC-Raum freigeben. Beispielsweise können drei verschiedene Kameraleute ihre Dailies oder laufenden Arbeiten automatisch im RTC-Raum bereitstellen lassen.
  • Eingebettete Versionen der offenbarten Implementierungen können auf Software installiert werden, die in Hardware läuft, die auf an das Netzwerk angeschlossenen Speichervorrichtungen läuft. Die Software kann beispielsweise in eine Vorrichtung eingebettet werden, die sich wie eine normale Festplatte verhält, aber über WLAN-Zugang verfügt und eine Verbindung zu einem Netzwerk herstellt. Somit kann sie einen kontinuierlichen Zugriff auf die Dateien bieten, die von einer Kamera aufgezeichnet wurden. Beispielsweise kann eine Kamera über ein Multi-Terabyte-Solid-State-Laufwerk verfügen, auf dem sie 8K-Filmmaterial aufzeichnet. Die Streaming-Software läuft auf der Kamera oder auf der Solid-State-Festplatte und stellt eine Liste und Metadaten aller Dateien (einschließlich der aktuell aufgezeichneten Datei) bereit, sodass Dateiindikatoren generiert und im RTC-Raum präsentiert werden können. Eine mit dem RTC-Raum verbundene Client-Vorrichtung kann eine Vorschau aller Dateien anzeigen, einschließlich der Datei, die gerade auf die Kamera geschrieben wird, was eine nahezu Echtzeit-Überwachung aller laufenden Kameras ermöglicht. Wenn Festplatten entfernt oder von einer Kamera entfernt und beispielsweise an ein Backup-System mit Stromversorgung angeschlossen werden, liefern sie weiterhin Vorschauen für die im Speicher gespeicherten Dateien an den RTC-Raum. Die Software kann zusätzlich so konfiguriert werden, dass eine neu kodierte Version der Dailies/Dateien in den RTC-Raum hochgeladen wird, damit sie verfügbar sind, wenn die Festplatten oder Kameras offline gehen. Dementsprechend werden Dateien, die auf der Festplatte einer Kamera gespeichert sind, wie hierin beschrieben als Dateien behandelt, die im Speicher einer Client-Vorrichtung (der Kamera) gespeichert sind, die Teil der RTC-Sitzung/des RTC-Raums ist.
  • Die Client-Anwendung kann auch die Fähigkeit integrieren, nicht nur Dateien zum Streamen in einen RTC-Raum bereitzustellen, sondern auch Videokonferenzen bereitzustellen. Beispielsweise kann die Client-Anwendung als Plug-In implementiert werden, das in eine Videobearbeitungs- oder Kreativsuite-Anwendung wie ADOBE PREMIERE, AVID oder FINAL CUT PRO integriert wird. Die Client-Anwendung kann so konfiguriert sein, dass sie sich mit der von diesen Programmen bereitgestellten API verbindet, um auf die in diesen Anwendungen gespeicherten und bearbeiteten Medieninhalte zuzugreifen. So kann z. B. das aktuell geöffnete Medienprojekt, das in einer Videobearbeitungsanwendung bearbeitet wird und aus zahlreichen anderen Multimediadateien und -einstellungen besteht, der Client-Anwendung zur Vorschau als eine einzige „Datei“ präsentiert werden, obwohl es nicht in eine einzige Datei „geglättet“ oder exportiert wurde. Die Client-Anwendung, die als Plugin arbeitet, stellt eine geeignete, live-streamingfähige Version bereit, die in die verfügbare Bandbreite passt, um eine Echtzeit-Vorschau des bearbeiteten Inhalts zu bieten, wobei jedoch nur der Inhalt und nicht die Wiedergabe-/Pause-Steuerung oder andere Mediensteuerungen angezeigt werden. Alternativ kann die Client-Anwendung, die als Plugin arbeitet, eine vollständige Anzeige einer ausgewählten Teilmenge von Medienbearbeitungssteuerelementen bereitstellen. Beispielsweise kann die Client-Anwendung, die als Plugin arbeitet, feinkörnige Steuerelemente remote exportieren, so dass andere Teilnehmer des RTC-Raums die Steuerelemente der Edit-Suite-Anwendung manipulieren können, z. B. Scrubbing (feinkörniges Durchsuchen von Frames, z. B. mit einem Steuerrad), Farbeinstellungen oder jede andere Funktion innerhalb der Anwendung, die remote manipuliert werden soll.
  • Die Videokonferenz kann als Plugin in die Anwendung integriert werden, so dass beispielsweise außerhalb oder innerhalb der Hauptanwendung zusätzliche Fenster angezeigt werden, die andere Teilnehmer im RTC-Raum zeigen.
  • In einigen Implementierungen kann die Client-Anwendung als Dateistreamer-Anwendung betrieben werden, die auf einer Client-Vorrichtung vorhanden sein kann und/oder in der Cloud gehostet werden kann. Der Datei-Streamer kann auf andere Quellen von Cloud-Assets und/oder andere Online-Medien wie DROPBOX, AMAZON WEB SERVICES, MICROSOFT AZURE usw. verwiesen werden. Unter Verwendung der APIs solcher Systeme kann der Datei-Streamer dem RTC-Raum eine Liste der an diesen Orten gespeicherten Dateien und ihrer zugehörigen Metadaten zur Verfügung stellen. Bei Auswahl ruft der Streamer eine auf dem RTC-Verwaltungssystem gespeicherte Version der Medien ab und transkodiert sie in ein geeignetes Format für Echtzeit-Streaming an den RTC-Raum und andere Teilnehmer.
  • Bei einigen Implementierungen kann andere Media-Asset-Manager-Software wie CMS (Inhaltsverwaltungssysteme) direkt in einen RTC-Raum eingebettet werden. Da der RTC-Raum in der Cloud gehostet wird (z. B. bei AMAZON WEB SERVICES), kann die Streamer-Software direkt im RTC-Raum ausgeführt werden und auf die APIs anderer Streaming-Dienste zugreifen. In einigen Implementierungen kann der RTC-Raum eine Instanz eines Webbrowsers ausführen und auf Cloud-Dienste für die gemeinsame Nutzung zugreifen, indem eine Webseite direkt in der Cloud gerendert wird, dann ferngesteuert auf dem RTC-Verwaltungssystem gerendert wird und dann an alle Client-Vorrichtungen gestreamt wird, die auf den RTC-Raum zugreifen.
  • In einigen Implementierungen kann eine Bilderkennung für das Bild eines Benutzers verwendet werden, der Zugang zu einem RTC-Raum anfordert, um vorläufig zu bestimmen, ob er sich bereits im RTC-Verwaltungssystem befunden hat. Wenn der Benutzer dem RTC-Verwaltungssystem bekannt und mit dem RTC-Raum verbunden ist, zu dem er Zugang anfordert, kann der Benutzer in den RTC-Raum gelassen werden. Alternativ kann der Nutzer sein Bild denjenigen Nutzern im RTC-Raum zeigen lassen, die in der Lage/berechtigt sind, dem Nutzer den Zugang zum RTC-Raum zu gewähren/zu verweigern. Die Benutzer würden das Bild des anfordernden Benutzers der Client-Vorrichtung sehen und bestimmen, ob dieser Benutzer den RTC-Raum betreten darf. In einigen Implementierungen kann das RTC-Verwaltungssystem die vom Benutzer gewährten Zugriffe prüfen, indem es den Benutzer, dem der Zugriff gewährt wurde, den Benutzer, der den Zugriff autorisiert hat, und/oder ein Stück Video vor und/oder nach der Gewährung des Zugriffs aufzeichnet und diese Sitzung an ein sicherheitsrelevantes Archiv sendet. In einigen Implementierungen kann ein maschineller Lernalgorithmus darauf trainiert werden, nach Anomalien oder nicht standardmäßigen Zugriffen auf RTC-Räume zu suchen. War einem Benutzer zum Beispiel bewusst, dass er jemanden in den RTC-Raum ließ, hat der Benutzer den anfragenden Benutzer visuell überprüft, bevor er Zugang gewährte, schien der gewährende Benutzer den anfragenden Benutzer zu erkennen, bevor er Zugang gewährte usw. Das RTC-Verwaltungssystem kann einem anfragenden Benutzer den Zugang zum RTC-Raum gestatten, kann dann aber Bilder des anfragenden und/oder gewährenden Benutzers per E-Mail oder auf andere Weise an einen Vorgesetzten senden, der automatisch prüft, ob der Benutzer Zugang zum RTC-Raum haben sollte. In einem solchen Beispiel kann der Zugriff temporär sein und dem anfordernden Benutzer muss möglicherweise jedes Mal Zugriff gewährt werden.
  • In einigen Implementierungen kann ein Benutzer, der Zugang zu einem RTC-Raum hat, einen anderen Benutzer oder eine Client-Vorrichtung in den RTC-Raum einladen, und dem eingeladenen Benutzer oder der Client-Vorrichtung kann der Zugang gewährt werden. In einem solchen Beispiel könnte das RTC-Verwaltungssystem bemerken, dass, obwohl der eingeladene Benutzer nicht in einer biometrischen Datenbank des RTC-Verwaltungssystems ist und nicht als autorisierter Benutzer hinzugefügt wurde, der eingeladene Benutzer möglicherweise zuvor eingeladen wurde.
  • In einigen Implementierungen kann es eine Situation geben, in der es keinen Benutzer im RTC-Raum gibt, der berechtigt ist, einem anfordernden Benutzer den Zugang zum RTC-Raum zu gestatten. In diesem Fall ist der Zugang durch einen Gast möglicherweise nicht verfügbar. In anderen Implementierungen könnte das Live-Video von der anfordernden Client-Vorrichtung jedoch an einen RTC-Raum-Organisator gesendet werden, der sich zu diesem Zeitpunkt nicht im RTC-Raum befand, und der RTC-Raum-Organisator könnte den Video-Feed überprüfen und den Zugang gewähren oder verweigern. Auf diese Weise kann ein RTC-Raum von einem RTC-Raumorganisator erstellt werden und dann können verschiedene Benutzer in den RTC-Raum eingelassen werden, ohne dass der RTC-Raumorganisator auch im RTC-Raum sein muss.
  • 10A bis 10G sind Übergangsdiagramme für die Remote-Ordnerfreigabe während einer RTC-Sitzung und eine videobasierte Zugriffsauthentifizierung gemäß Implementierungen der vorliegenden Offenbarung.
  • Wie in diesem Beispiel dargestellt, fragt eine RTC-Anwendung 1003-1, die auf einer ersten Client-Vorrichtung 1002-1 ausgeführt wird, einen Speicherabschnitt, hierin als Ordner 1006-1 bezeichnet, des Speichers der ersten Client-Vorrichtung 1002-1 ab, um Metadaten über Dateien zu erhalten, die in dem Ordner 1006-1 gespeichert sind, wie in 1000-1. Beispielsweise kann ein Benutzer der ersten Client-Vorrichtung 1002-1 einen Ordner 1006-1 identifizieren, auf den die RTC-Anwendung 1003-1 zugreifen kann. Die RTC-Anwendung 1003-1 kann periodisch auf den identifizierten Ordner 1006-1 zugreifen und Metadaten für beliebige Dateien erhalten, die in diesem Ordner 1006-1 enthalten oder gespeichert sind. In diesem Beispiel werden Datei 1 1008-1 und Datei 2 1008-2 in dem Ordner 1006-1 der ersten Client-Vorrichtung 1002-1 gespeichert, die mit der auf der Client-Vorrichtung ausgeführten RTC-Anwendung 1003-1 verknüpft oder für diese zugänglich ist.
  • Da Metadaten von der RTC-Anwendung 1003-1 identifiziert werden, verbinden sich die RTC-Anwendung 1003-1 und die erste Client-Vorrichtung 1002-1 über ein Netzwerk 1002 mit dem RTC-Verwaltungssystem 1001, das auf den Remote-Rechenressourcen 1013 ausgeführt wird, wie in 1000-2. Sobald die Verbindung hergestellt ist, sendet die RTC-Anwendung die Metadaten für jede der Dateien, die in dem Ordner 1006-1 der ersten Client-Vorrichtung 1002-1 gespeichert sind, wie in 1000-3. In dem veranschaulichten Beispiel sendet die RTC-Anwendung 1003-1 Metadaten für jede Datei 1 1008-1 und Datei 2 1008-2 von der ersten Client-Vorrichtung 1002-1 an das RTC-Verwaltungssystem 1001. Die Datei-Metadaten können neben anderen Informationen den physischen Speicherort der Datei auf der ersten Client-Vorrichtung 1002-1, einen Identifizierer der Datei, einen Typ der Datei, eine Größe der Datei, eine Länge der Datei und/oder andere Informationen einschließen. Insbesondere, wie weiter unten besprochen, bleibt die eigentliche Datei, wie etwa Datei 1 1008-1 und Datei 2 1008-2 auf der Client-Vorrichtung gespeichert und wird nicht von der Client-Vorrichtung zu den Remote-Rechenressourcen 1013 übertragen.
  • Wenn das RTC-Verwaltungssystem 1001 Metadaten über Dateien empfängt, die auf Client-Vorrichtungen wie der Client-Vorrichtung 1 1002-1 gespeichert sind, werden die Metadaten in einem Speicher der Rechenressourcen 1013 gespeichert, wie in 1000-4.
  • In diesem Beispiel sendet die RTC-Anwendung 1003-1, die auf der ersten Client-Vorrichtung 1002-1 ausgeführt wird, nicht nur Metadaten für Dateien, die im Speicher der ersten Client-Vorrichtung 1002-1 gespeichert sind und auf die die RTC-Anwendung 1003-1 zugreifen kann, sondern eine zweite RTC-Anwendung 1003-2, die auf einer zweiten Client-Vorrichtung 1002-2 ausgeführt wird, sammelt auch Metadaten über Dateien, die in einem Speicher der zweiten Client-Vorrichtung 1002-2 gespeichert sind und auf die die zweite RTC-Anwendung 1003-2 zugreifen kann, wie in 1000-5. In diesem Beispiel hat die zweite RTC-Anwendung 1003-2 Zugriff auf Datei A 1008-3 und Datei B 1008-4, die in einem Ordner 1006-2 gespeichert sind, auf den die RTC-Anwendung 1003-2 Zugriff hat.
  • Während die zweite RTC-Anwendung Metadaten über Dateien sammelt, die im Speicher der zweiten Client-Vorrichtung 1002-2 gespeichert sind, verbindet sich die RTC-Anwendung wie in 1000-6 mit dem RTC-Verwaltungssystem und stellt die Metadaten über diese Dateien dem RTC-Verwaltungssystem bereit, wie in 1000-7. Wenn die Metadaten von der zweiten Client-Vorrichtung 1002-2 empfangen werden, speichert das RTC-Verwaltungssystem 1001 die empfangenen Metadaten in einem Speicher der Remote-Rechenressourcen 1013, wie in 1000-8. In einigen Implementierungen können die Metadaten, die sowohl von der ersten Client-Vorrichtung 1002-1 als auch von der zweiten Client-Vorrichtung 1002-2 empfangen werden, in demselben Speichersegment der Remote-Rechenressourcen 1013 gespeichert werden. In anderen Implementierungen können die von den verschiedenen Client-Vorrichtungen empfangenen Metadaten in verschiedenen Speicherabschnitten der Remote-Rechenressourcen gespeichert werden.
  • Wie bereits erwähnt, werden gemäß den beschriebenen Implementierungen nur die Metadaten von den Client-Vorrichtungen an das RTC-Verwaltungssystem übertragen, das auf den Remote-Rechenressourcen 1013 ausgeführt wird, so dass die Sicherheit der eigentlichen Dateien unter der Kontrolle der jeweiligen Client-Vorrichtung bleibt.
  • Wie in 10B dargestellt, kann zu einem bestimmten Zeitpunkt ein RTC-Raum 1050 für die Echtzeit-Zusammenarbeit zwischen der ersten Client-Vorrichtung 1002-1 und der zweiten Client-Vorrichtung 1002-2 erstellt werden, wie in 1000-9. In diesem Beispiel wird der RTC-Raum 1050 erzeugt und gleichzeitig auf jeder Client-Vorrichtung 1002-1, 1002-2 präsentiert, als ob der RTC-Raum auf jeder separaten Client-Vorrichtung lokal wäre.
  • Ein RTC-Raum, wie er hierin verwendet wird, ist ein virtueller Bereich, der für einen beliebigen Zeitraum eingerichtet werden kann und dazu dient, eine oder mehrere RTC-Sitzungen zu ermöglichen und/oder zu unterstützen. Der RTC-Raum kann z. B. dazu verwendet werden, Metadaten und Dateiindikatoren zuzuordnen, Benutzer/Teilnehmer und/oder Client-Vorrichtungen anzugeben, die auf den RTC-Raum oder eine mit einem RTC-Raum verbundene RTC-Sitzung zugreifen dürfen, usw. Auch wenn in den beschriebenen Beispielen in erster Linie von zwei bis drei Client-Vorrichtungen und entsprechenden Teilnehmern die Rede ist, kann ein RTC-Raum und/oder eine RTC-Sitzung auch weniger oder zusätzliche Client-Vorrichtungen und/oder Teilnehmer umfassen. Ebenso sind die offenbarten Implementierungen nicht auf Client-Vorrichtungen beschränkt, die auf einen RTC-Raum und/oder eine RTC-Sitzung zugreifen. Jedes der hierin besprochenen Vorrichtungen kann mit einem RTC-Raum und/oder einer RTC-Sitzung verbunden und/oder verwendet werden.
  • Im Rahmen der Erstellung des RTC-Raums oder jederzeit, wenn Metadaten über eine Datei von einer beliebigen Client-Vorrichtung gesendet werden, die an dem RTC-Raum 1050 teilnimmt oder mit ihm verbunden ist, kann jedes Element der empfangenen Metadaten verwendet werden, um einen Dateiindikator zu erstellen, der für die jeweilige Datei steht, die auf den verschiedenen Client-Vorrichtungen gespeichert ist. Der Dateiindikator kann stellvertretend für die Datei stehen, aber nicht tatsächlich die Datei einschließen, und kann von jeder am RTC-Raum 1050 teilnehmenden Client-Vorrichtung ausgewählt werden, als ob der Dateiindikator tatsächlich die Datei wäre und im RTC-Raum 1050 eingeschlossen wäre. In diesem Beispiel wird die Datei 1 1008-1, die auf der ersten Client-Vorrichtung 1002-1 gespeichert ist, durch eine Datei 1-Identifikation 1058-1 dargestellt, die Datei 2 1008-2, die auf der ersten Client-Vorrichtung 1002-1 gespeichert ist, wird durch eine Datei 2-Identifikation 1058-2 dargestellt, die Datei A 1008-3, die auf der zweiten Client-Vorrichtung 1002-2 gespeichert ist, wird durch eine Datei A-Identifikation 1058-3 dargestellt, und die Datei B 1008-4, die auf der zweiten Client-Vorrichtung 1002-2 gespeichert ist, wird durch eine Datei B-Identifikation 1058-4 dargestellt.
  • Darüber hinaus kann ein Remote-Ordner 1056 erstellt werden, und die Dateiindikatoren 1058 der verschiedenen Dateien, die auf den verschiedenen Client-Vorrichtungen gespeichert sind, können in dem Remote-Ordner konsolidiert werden, um jeder Client-Vorrichtung, die am RTC-Raum 1050 teilnimmt, so präsentiert zu werden, als ob die Dateien tatsächlich in dem Remote-Ordner 1056 gespeichert wären, wie in 1000-11. In anderen Implementierungen können mehrere verschiedene entfernte Ordner 1056 erstellt und die verschiedenen Dateiindikatoren in verschiedenen Ordnern gespeichert werden, wiederum so, als ob die Dateien tatsächlich auf dem entfernten Computersystem und Teil des RTC-Raums 1050 gespeichert wären.
  • Als Teil der Erstellung des RTC-Raums können RTC-Kanäle, wie z. B. ein Audiokanal, ein Videokanal und/oder ein Datenkanal, zwischen der ersten Client-Vorrichtung 1002-1, der zweiten Client-Vorrichtung 1002-2 und dem RTC-Verwaltungssystem 1001, wie in 1002-12, eingerichtet werden, wodurch eine RTC-Sitzung zwischen den Client-Vorrichtungen und der RTC-Verwaltungssitzung gestartet wird. In diesem Beispiel ist die RTC-Sitzung dem RTC-Raum zugeordnet. Schließlich kann der RTC-Raum als Teil der RTC-Sitzung auf jeder der Client-Vorrichtungen 1002-1, 1002-2 präsentiert werden, die als Teil des RTC-Raums eingeschlossen sind, wie in 1000-13. In dem veranschaulichten Beispiel kann der RTC-Raum 1050 eine Vielzahl von Informationen aufweisen, die auf oder in dem RTC-Raum präsentiert werden. In diesem Beispiel können zusätzlich zu dem entfernten Ordner 1056 und den Dateianzeigen 1058 auch ein Live-Video-Feed 1051-1 eines ersten Benutzers, der die erste Client-Vorrichtung 1002-1 verwendet, und ein Live-Video-Feed 1051-2 eines zweiten Benutzers, der die zweite Client-Vorrichtung 1002-2 verwendet, zwischen den Vorrichtungen übertragen und im RTC-Raum 1050 als Teil der RTC-Sitzung dargestellt werden. Wie in 10B dargestellt, kann jeder Client-Vorrichtung 1002-1, 1002-2 ein identischer RTC-Raum 1050 präsentiert werden. In anderen Implementierungen kann der Video-Feed der Client-Vorrichtung, auf der der RTC-Raum dargestellt wird, im RTC-Raum 1050 weggelassen werden. Zum Beispiel kann der RTC-Raum 1050, wie er auf der ersten Client-Vorrichtung 1002-1 dargestellt wird, in einigen Implementierungen den ersten Video-Feed 1051-1 weglassen und der RTC-Raum 1050, wie er auf der zweiten Client-Vorrichtung 1002-2 dargestellt wird, kann den zweiten Video-Feed 1051-2 weglassen.
  • Wie in 10C dargestellt, kann in diesem Beispiel zu einem bestimmten Zeitpunkt während der RTC-Sitzung eine dritte Client-Vorrichtung 1002-3 eine Anfrage zum Beitritt zum RTC-Raum 1050 stellen, wie in 1000-14. Anstatt vom Benutzer der dritten Client-Vorrichtung zu verlangen, dass er sich ein Passwort oder eine andere Zugangskennung merkt und bereitstellt, kann das RTC-Verwaltungssystem 1001 in den offenbarten Implementierungen als Reaktion auf den Empfang der Zugangsanforderung verlangen oder anfordern, dass ein Live-Video-Feed von einer Kamera der dritten Client-Vorrichtung 1002-3 als Teil der Zugangsanforderung übertragen wird, wie in 1000-15. Beispielsweise kann das RTC-Verwaltungssystem 1001 eine Antwort an die RTC-Anwendung 1003-3 senden, die auf der dritten Client-Vorrichtung 1002-3 ausgeführt wird, und anfordern, dass die RTC-Anwendung 1003-3 die Kamera der dritten Client-Vorrichtung 1002-3 aktiviert und das von der Kamera der dritten Client-Vorrichtung erhaltene Live-Video an das RTC-Verwaltungssystem 1001 sendet, wie in 1000-16.
  • Das RTC-Verwaltungssystem 1001 kann bei Empfang des Live-Video-Feeds von der dritten Client-Vorrichtung den Live-Video-Feed 1051-3 einer der anderen Client-Vorrichtungen und/oder allen anderen Client-Vorrichtungen, die in der RTC-Sitzung eingeschlossen sind, zusammen mit einer Bestätigungsanfrage 1052 präsentieren, damit die dritte Client-Vorrichtung der RTC-Sitzung beitreten kann, wie in 1000-17. In einigen Implementierungen kann der Live-Video-Feed nur an eine der Client-Vorrichtungen gesendet werden, die an der RTC-Sitzung beteiligt sind, z. B. an eine Client-Vorrichtung, die als Moderator oder Leiter der RTC-Sitzung identifiziert wurde und hierin auch als RTC-Raumorganisator bezeichnet wird.
  • Das Bereitstellen eines Live-Video-Feeds von der Kamera der anfragenden Client-Vorrichtung vereinfacht nicht nur den Zugangsprozess für den Benutzer auf der anfragenden Client-Vorrichtung (d. h. der Benutzer muss sich nicht an ein Kennwort oder ein anderes Identifizierungsmerkmal erinnern oder es angeben), sondern erhöht auch die allgemeine Sicherheit des RTC-Raums. Insbesondere ermöglicht das Präsentieren eines Live-Video-Feeds von der anfordernden Client-Vorrichtung einem Benutzer, der an der RTC-Sitzung teilnimmt, den Benutzer, der Zugriff anfordert, visuell zu verifizieren.
  • In dem dargestellten Beispiel wird eine Zugriffsbestätigung empfangen, um der dritten Client-Vorrichtung zu erlauben, der RTC-Sitzung beizutreten, wie in 1000-18. Als Reaktion auf die Zugriffsbestätigung, die sich auf 10D bezieht, kann ein oder mehrere Audiokanäle, Videokanäle und/oder Datenkanäle zwischen jeder der ersten Client-Vorrichtung 1002-1, der zweiten Client-Vorrichtung 1002-2, der dritten Client-Vorrichtung 1002-3 und dem RTC-Verwaltungssystem 1001 eingerichtet werden, wie in 1000-19, und der RTC-Raum 1050 wird an die dritte Client-Vorrichtung 1002-3 gestreamt, wie in 1000-20. Darüber hinaus wird in diesem Beispiel ein dritter Live-Videostream 1051-3 des Benutzers an der dritten Client-Vorrichtung 1002-3 als Teil des RTC-Raums 1050 für jede der anderen Client-Vorrichtungen/Teilnehmer, die an der RTC-Sitzung teilnehmen, präsentiert. Darüber hinaus hat die RTC-Anwendung 1003-3 in diesem Beispiel keinen Zugriff auf eine Datei der dritten Client-Vorrichtung und/oder auf Dateien, die auf der dritten Client-Vorrichtung gespeichert sind, und daher werden keine Metadaten für Dateien, die auf der dritten Client-Vorrichtung gespeichert sind, an das RTC-Verwaltungssystem gesendet. Da die dritte Client-Vorrichtung 1002-3 nun an der RTC-Sitzung teilnimmt und den RTC-Raum 1050 betrachtet, kann die dritte Client-Vorrichtung 1002-3 jeden Dateiindikator 1058 und den Remote-Ordner 1056 so betrachten, als ob die durch diese Dateiindikatoren dargestellten Dateien im RTC-Raum 1050 eingeschlossen wären.
  • Während das besprochene Beispiel angibt, dass jede im RTC-Raum enthaltene Client-Vorrichtung alle Dateiindikatoren sehen und darauf zugreifen kann, kann ein RTC-Raum-Organisator in einigen Implementierungen angeben, auf welche Dateiindikatoren und/oder Remote-Ordner 1056 von verschiedenen Client-Vorrichtungen des RTC-Raums zugegriffen und diese angezeigt werden können. Zum Beispiel kann die erste Client-Vorrichtung 1002-1 als Organisator des RTC-Raums angegeben werden und kann als Organisator bestimmen, dass die zweite Client-Vorrichtung 1002-2 jede der Dateiindikatoren 1058 sehen und darauf zugreifen kann, aber dass die dritte Client-Vorrichtung 1002-3 nur den Datei-1-Identifikator 1058-1 sehen und darauf zugreifen kann. In anderen Beispielen können andere Zugriffsrechte angegeben werden.
  • Während einer RTC-Sitzung kann jede an der RTC-Sitzung teilnehmende Client-Vorrichtung, der der Zugriff auf einen Dateiindikator gestattet ist, diesen Dateiindikator auswählen. Zum Beispiel und unter Bezugnahme auf 10E sendet in diesem Beispiel die zweite Client-Vorrichtung 1002-2 eine Anforderung, die Datei 1 abzuspielen, die durch den Identifikator 1058-1 der Datei 1 dargestellt wird, der auf dem Remote-Ordner 1056 des RTC-Raums 1050 präsentiert wird, wie in 1000-21. Eine Anforderung zum Zugreifen oder in diesem Beispiel zum Abspielen einer Datei kann irgendeine von einer Vielzahl von Zugriffsanforderungen sein. Beispielsweise kann die zweite Client-Vorrichtung 1002-2 unter Verwendung einer Eingabe-Ausgabe-Komponente der Client-Vorrichtung, wie einer Maus, einer Tastatur, eines Trackpads, einer berührungsempfindlichen Anzeige usw., den Dateianzeiger 1058 auswählen, und diese Auswahl kann eine Zugriffsanforderung in Bezug auf diese Datei anzeigen, wie z. B. eine Anforderung zur Wiedergabe der Datei.
  • Das RTC-Verwaltungssystem fragt nach Erhalt der Zugriffsanforderung von der zweiten Client-Vorrichtung in Bezug auf die Datei 1, die durch den Datei-1-Identifikator 1058-1 dargestellt wird, die für den RTC-Raum gespeicherten Metadaten ab, um den physischen Ort der Datei 1 1008-1 zu bestimmen, die durch den ausgewählten Datei-1-Identifikator 1058-1 dargestellt wird, wie in 1000-22. In diesem Beispiel wird aus den Metadaten bestimmt, dass sich der physische Ort der Datei 1 im Ordner 1006-1 der ersten Client-Vorrichtung 1002-1 befindet. Als solches sendet das RTC-Verwaltungssystem eine Anweisung an die erste RTC-Anwendung 1003-1, die auf der ersten Client-Vorrichtung 1002-1 ausgeführt wird, um zu veranlassen, dass die erste Datei 1008-1 von der ersten Client-Vorrichtung 1002-1 abgespielt wird, wie in 1000-23.
  • Bezug nehmend auf 10F veranlasst die erste RTC-Anwendung 1003-1, die auf der ersten Client-Vorrichtung 1002-1 ausgeführt wird, als Reaktion auf den Empfang der Anweisungen, dass die erste Datei als Teil des RTC-Raums 1050 und der RTC-Sitzung, wie in 1000-24, zu jeder der Client-Vorrichtungen 1002-1, 1002-2, 1002-3 gestreamt wird 1055. Zusätzlich können Dateisteuerungen 1057 für jede Client-Vorrichtung präsentiert werden und zugänglich sein, wodurch jeder Client-Vorrichtung ermöglicht wird, gleichzeitig die Kontrolle über den Zugriff auf die Datei zu übertragen. Zum Beispiel kann jede der Client-Vorrichtungen, während es die Streaming-Wiedergabe 1055 der ersten Datei betrachtet, eine der Dateisteuerungen auswählen, wie etwa eine Wiedergabesteuerung, eine Pausensteuerung, eine Stoppsteuerung, eine Schnellvorlaufsteuerung, eine Rücklaufsteuerung, eine Zeitlupensteuerung, usw., und diese Steuerung wird in Bezug auf die Datei, auf die zugegriffen wird, durchgeführt und von jeder Client-Vorrichtung wahrgenommen, die an dem RTC-Raum 1050 teilnimmt. Beispielsweise kann die dritte Client-Vorrichtung 1002-3 mit den Dateisteuerungen 1057 interagieren und auswählen, die Wiedergabe der ersten Datei wie in 1000-25 anzuhalten. Als Reaktion darauf bestimmt das RTC-Verwaltungssystem 1001 erneut den physischen Ort der ersten Datei, in diesem Beispiel die erste Client-Vorrichtung, und sendet die ausgegebene Steueranweisung an die Client-Vorrichtung, an der sich die Datei physisch befindet, wie in 1000-26. Die RTC-Anwendung, die auf dieser Client-Vorrichtung ausgeführt wird, führt die Steueranweisungen in Bezug auf die Datei aus, wobei in diesem Beispiel die Wiedergabe der Datei angehalten wird, wie in 1000-27.
  • Indem die Dateisteuerungen jeder an der RTC-Sitzung teilnehmenden Client-Vorrichtung angezeigt werden, kann jede Client-Vorrichtung die Kontrolle über eine angezeigte oder angezeigte Datei ausüben, unabhängig vom physischen Speicherort der Datei. Darüber hinaus können in einigen Implementierungen Anmerkungen, Kommentare, Markierungen oder andere Eingaben von jeder der Client-Vorrichtungen in Bezug auf den RTC-Raum und die Datei, auf die zugegriffen wird, bereitgestellt werden. Zum Beispiel, bezogen auf 10G, nachdem die dritte Client-Vorrichtung die Wiedergabe der ersten Datei, die von der ersten Client-Vorrichtung gestreamt wurde, angehalten hat, kommentiert die dritte Client-Vorrichtung 1059 einen Teil dieser Datei, wiederum so, als ob die Datei vom RTC-Verwaltungssystem als Teil des RTC-Raums gespeichert wäre, wie in 1000-28. In diesem Beispiel wird die von der dritten Client-Vorrichtung erstellte Anmerkung 1059 im RTC-Raum als Teil der RTC-Sitzung präsentiert, so dass jede andere Client-Vorrichtung, die auf den RTC-Raum zugreift, die Anmerkung gleichzeitig wahrnimmt. Darüber hinaus speichert das RTC-Verwaltungssystem die Anmerkungen und Metadaten zu den Anmerkungen als Teil des RTC-Raums/der RTC-Sitzung, wie in 1000-29. Zum Beispiel können die Metadaten einen Zeitstempel innerhalb der ersten Datei oder ein Einzelbild oder eine Aufnahme der ersten Datei angeben, bei der die Anmerkung erzeugt wurde, Positionsinformationen bezüglich der Anmerkung, die Quelle der Anmerkung usw. Durch die Speicherung der Anmerkung und der Metadaten über die Anmerkung können die Anmerkung und die entsprechenden Metadaten später als Teil des RTC-Raums verwendet werden, um die Anmerkung der ersten Datei mit der Anmerkung neu zu erstellen, auch wenn die Anmerkung nicht Teil der ersten Datei wird, die gerade angesehen wird, wie weiter unten beschrieben.
  • 11 ist ein beispielhafter Prozess des Remote Ordners 1100 gemäß Implementierungen der vorliegenden Offenbarung.
  • Der beispielhafte Prozess 1100 beginnt mit dem Sammeln von Dateimetadaten von jeder Client-RTC-Anwendung, die auf jeder Client-Vorrichtung ausgeführt wird, die auf einen RTC-Raum zugreift oder diesem zugeordnet ist, wie in 1102. Wie oben dargelegt, kann eine RTC-Anwendung, die auf einer Client-Vorrichtung ausgeführt wird, Zugang zu einer oder mehreren Dateien und/oder Ordnern haben, die im Speicher dieser Client-Vorrichtung gespeichert sind. Für jede zugängliche Datei kann die RTC-Anwendung Dateimetadaten über die Datei abrufen und bereitstellen, wie z. B. Dateispeicherort, Dateityp, Dateigröße, Dateiname, Dateierstellungsdatum usw.
  • Für jede auf einer Client-Vorrichtung gespeicherte Datei, für die Dateimetadaten empfangen wurden, wird ein Dateiindikator basierend auf den Dateimetadaten generiert, wie in 1104. Der Dateiindikator kann eine visuelle Darstellung der Datei sein, die als Teil des RTC-Raums präsentiert wird, obwohl die Datei selbst auf der Client-Vorrichtung gespeichert und gesichert bleibt. Die Dateiindikatoren für jede der Dateien, die auf den verschiedenen Client-Vorrichtungen gespeichert sind, können in einem oder mehreren Remote-Ordnern zusammengefasst werden, wie in 1105. Beispielsweise können die Dateiindikatoren ungeachtet des tatsächlichen Speicherorts der Dateien in einem einzigen Ordner zur gemeinsamen Präsentation als Teil des RTC-Raums zusammengefasst werden. Der Remote-Ordner und die entsprechenden Dateiindikatoren können dann als Teil eines RTC-Raums/einer RTC-Sitzung jeder Client-Vorrichtung präsentiert werden, die mit dem RTC-Raum/der RTC-Sitzung verbunden ist oder daran teilnimmt, wie in 1106. In einigen Implementierungen können alle Client-Vorrichtungen, die in einem RTC-Raum/einer RTC-Sitzung enthalten sind, Zugang zu den RTC-Ordner- und Dateianzeigen haben und diese einsehen. In anderen Implementierungen kann ein RTC-Raumorganisator festlegen, welche Client-Vorrichtungen die Remote-Ordner und/oder Dateianzeigen anzeigen und/oder darauf zugreifen können.
  • Während die Dateiindikatoren angezeigt werden, wird festgestellt, ob eine Dateianforderung für eine durch einen Dateiindikator dargestellte Datei von einem der an der RTC-Sitzung teilnehmenden Client-Vorrichtungen empfangen wurde, wie in 1108. Eine Dateianforderung kann jede Art von Dateianforderung in Bezug auf eine Datei sein und beispielsweise je nach Dateityp variieren. Wenn die Datei beispielsweise eine Videodatei ist, kann die Dateianforderung eine Wiedergabeanforderung sein. Ein weiteres Beispiel ist, dass es sich bei der Datei um ein Dokument handeln kann und die Dateianfrage eine Aufforderung zum Öffnen des Dokuments zur Überprüfung durch die Teilnehmer der RTC-Sitzung/des RTC-Raums sein kann.
  • Wenn bestimmt wird, dass keine Dateianforderung empfangen wurde, kann der beispielhafte Prozess bei Entscheidungsblock 1108 bleiben. Wenn bestimmt wird, dass eine Dateianforderung empfangen wurde, werden die Metadaten, die dem ausgewählten Dateiindikator entsprechen, abgefragt, um die Client-Vorrichtung zu bestimmen, auf der die Datei tatsächlich gespeichert ist, wie in 1110. Wie oben erwähnt, können Metadaten Informationen über die Datei enthalten, wie z. B. den physikalischen Speicherort der Datei, der durch einen Dateiindikator dargestellt wird.
  • Als Reaktion auf die Bestimmung des Dateispeicherorts auf einer Client-Vorrichtung, auf der sich die Datei physisch befindet, wird die Dateianfrage wie in 1112 an die Client-Vorrichtung gesendet, auf der die Datei gespeichert ist. In einigen Implementierungen kann die Dateianforderung an eine RTC-Anwendung gesendet werden, die auf der Client-Vorrichtung ausgeführt wird, auf dem die Datei gespeichert ist. In einem solchen Beispiel kann die RTC-Anwendung, die auf der Client-Vorrichtung ausgeführt wird, beim Empfangen der Dateianforderung auf die Datei zugreifen und die Dateianforderung ausführen, wie z. B. das Abspielen der Datei.
  • Zusätzlich zur Ausführung der Dateianfrage streamt die Client-Vorrichtung die angeforderte Datei an jede der anderen Client-Vorrichtungen, die an der RTC-Sitzung teilnehmen, und als Teil des RTC-Raums, wie in 1114. Beispielsweise kann die RTC-Anwendung, die auf der Client-Vorrichtung ausgeführt wird, auf der die angeforderte Datei gespeichert ist, die Dateianforderung ausführen, z. B. die Datei abspielen und die Wiedergabe der Datei an jede der anderen Client-Vorrichtungen als Teil der RTC-Sitzung übertragen. Durch das Streamen der Datei, anstatt die gesamte Datei zu übertragen, verbleibt die eigentliche Datei auf der Client-Vorrichtung und unterliegt der Sicherheit der Client-Vorrichtung.
  • Während die Datei gestreamt wird, wird festgestellt, ob von einer angeschlossenen Vorrichtung, die die Datei ansieht und an der RTC-Sitzung teilnimmt, ein Dateiinteraktionsbefehl empfangen wurde, wie in 1116. So kann beispielsweise jeder Client-Vorrichtung eine Dateisteuerung als Teil des Streaming der abgerufenen Datei präsentiert werden, und jede Client-Vorrichtung kann gleichzeitig Dateisteuerungen zur Steuerung der gestreamten Datei übermitteln. Handelt es sich bei der gestreamten Datei beispielsweise um eine Videodatei, kann die Dateisteuerung unter anderem die Wiedergabe der Datei, die Pause der Datei, das Anhalten der Datei, den schnellen Vorlauf der Datei, den Rücklauf der Datei, die Zeitlupe der Datei usw. einschließen. In anderen Implementierungen kann der Befehl zur Interaktion mit der Datei eine Anmerkung zu einem Bild der Datei, eine Bearbeitung, ein Kommentar zu einem Bild oder einer Aufnahme der Datei usw. sein. Ein Benutzer an einer beliebigen Client-Vorrichtung kann durch Interaktion mit der Dateisteuerung einen Dateibefehl erzeugen. In anderen Implementierungen können andere Arten von Interaktionsbefehlen empfangen und mit den offenbarten Implementierungen ausgeführt werden, wie hierin erörtert.
  • Wenn bestimmt wird, dass kein Dateiinteraktionsbefehl empfangen wird, kann der beispielhafte Prozess bei Entscheidungsblock 1116 bleiben. Jedoch können beim Empfang eines Dateiinteraktionsbefehls von einer Client-Vorrichtung Metadaten, die dem Dateiinteraktionsbefehl (einem Ereignis) entsprechen, als Teil der RTC-Sitzung beibehalten werden, wie in 1118. Die Metadaten können Informationen in Bezug auf den Dateiinteraktionsbefehl bereitstellen, wie z. B. einen Zeitstempel, wann wir den Dateiinteraktionsbefehl erhalten haben, ein Frame oder eine Aufnahme der gestreamten Datei, die als Teil der RTC-Sitzung präsentiert wird, wenn der Dateiinteraktionsbefehl empfangen wird usw. Außerdem kann der Dateiinteraktionsbefehl an die Client-Vorrichtung gesendet werden, die die Datei streamt, so dass der Befehl in Bezug auf die Datei ausgeführt wird, wie in 1120. Wenn der Dateiinteraktionsbefehl beispielsweise darin besteht, die Wiedergabe der Datei anzuhalten, kann der Dateiinteraktionsbefehl zum Anhalten an die RTC-Anwendung gesendet werden, die auf der Client-Vorrichtung ausgeführt wird, auf der sich die Datei physisch befindet, und die RTC-Anwendung kann den Dateiinteraktionsbefehl ausführen, beispielsweise die Wiedergabe der Datei anhalten.
  • Der beispielhafte Prozess 1100 kann kontinuierlich während einer beliebigen RTC-Sitzung ausgeführt werden, was den Zugriff auf mehrere Dateien durch beliebige der verbundenen Client-Vorrichtungen ermöglicht, unabhängig vom physischen Standort dieser Dateien, durchzuführenden Interaktionen in Bezug auf ausgewählte Dateien usw.
  • 12 ist ein beispielhafter Seitenkommunikationsprozess 1200 gemäß Implementierungen der vorliegenden Offenbarung. Der beispielhafte Prozess kann jederzeit während einer RTC-Sitzung von zwei oder mehr Client-Vorrichtungen ausgeführt werden, die in einer RTC-Sitzung eingeschlossen sind.
  • Der beispielhafte Prozess 1200 hält als Teil der normalen RTC-Sitzung getrennte Audiokanäle und Videokanäle zwischen jeder Client-Vorrichtung aufrecht, die an einer RTC-Sitzung teilnimmt, wie in 1202. Wenn diese Kanäle aktiv sind, werden Audio- und Videodaten zwischen den einzelnen Client-Vorrichtungen gestreamt, so dass alle Client-Vorrichtungen Audiodaten und Videodaten empfangen und ausgeben, die von den anderen an der RTC-Sitzung teilnehmenden Client-Vorrichtungen empfangen wurden, wie in 1204.
  • Während die Audio- und Videodaten zwischen den einzelnen Client-Vorrichtungen gestreamt werden, wird festgestellt, ob eine seitliche Kommunikationsanforderung empfangen wurde, wie in 1206. Eine Nebenkommunikation, wie sie hierin verwendet wird, istjede Audio- und/oder Videokommunikation, die Teil einer laufenden RTC-Sitzung ist, die weniger als alle Client-Vorrichtungen der RTC-Sitzung einschließt, ohne eine weitere RTC-Sitzung aufzubauen. Wenn beispielsweise drei Client-Vorrichtungen in einer RTC-Sitzung enthalten sind, kann, wie unten erläutert, eine Nebenkommunikation zwischen zwei dieser Client-Vorrichtungen als Teil der RTC-Sitzung eingerichtet werden, während der diese beiden Client-Vorrichtungen Audiodaten von allen Client-Vorrichtungen der RTC-Sitzung empfangen und ausgeben, während die dritte Client-Vorrichtung keine Audiodaten von den ersten beiden Client-Vorrichtungen ausgibt.
  • Wenn bei Entscheidungsblock 1206 festgestellt wird, dass keine Seitenkommunikationsanforderung empfangen wurde, kehrt der beispielhafte Prozess 1200 zu Block 1204 zurück und fährt fort. Wenn jedoch eine Seitenkommunikationsanforderung empfangen wird, werden die Audiokanäle (hierin als Seitenaudiokanäle bezeichnet) und optional die Videokanäle (hierin als Seitenvideokanäle bezeichnet), die in die Seitenkommunikation einzubeziehen sind bestimmt, wie in 1208. Ebenso werden die von der Seitenkommunikation auszuschließenden Client-Vorrichtungen bestimmt, die hierin als ausgeschlossene Vorrichtungen bezeichnet werden, wie in 1210.
  • Schließlich wird für die von der Nebenkommunikation auszuschließenden Client-Vorrichtungen die Ausgabe der Audiodaten und optional der Videodaten, die von den Nebenaudiokanälen empfangen werden, deaktiviert oder stumm geschaltet, so dass Audiodaten von diesen Kanälen nicht an die ausgeschlossenen Client-Vorrichtungen ausgegeben werden, wie in 1212. Wenn beispielsweise drei Client-Vorrichtungen (Vorrichtung 1, Vorrichtung 2, Vorrichtung 3) in einer RTC-Sitzung eingeschlossen sind und Vorrichtung 1 und Vorrichtung 2 eine Nebenkommunikation als Teil der RTC-Sitzung wünschen, werden die Audio-Seitenkanäle zwischen Vorrichtung 1 und Vorrichtung 2 als die Neben-Audiokanäle identifiziert und Client-Vorrichtung 3 wird als die Client-Vorrichtung identifiziert, die von der Nebenkommunikation ausgeschlossen werden soll. Um die Seitenkommunikation als Teil der RTC-Sitzung zu ermöglichen, sind die Audiodaten von Client 1 zu Client 2 aktiv und werden an Client 2 ausgegeben, die Audiodaten von Client 2 zu Client 1 sind aktiv und werden an Client 1 ausgegeben, die Audiodaten von Client 3 zu Client 1 sind aktiv und werden an Client 1 ausgegeben, die Audiodaten von Client 3 zu Client 2 aktiv sind und an Client 2 ausgegeben werden, die Audiodaten von Client 1 zu Client 3 deaktiviert sind, so dass die Audiodaten von Client 1 nicht an Client 3 ausgegeben werden, und die Audiodaten von Client 2 zu Client 3 deaktiviert sind, so dass die Audiodaten von Client 2 nicht an Client 3 ausgegeben werden. In einer solchen Konfiguration empfangen und geben Client 1 und Client 2 nach wie vor Audiodaten von jedem der anderen an der RTC-Sitzung beteiligten Client-Vorrichtungen aus, aber Client 3 gibt die von Client 1 oder Client 2 empfangenen Audiodaten nicht aus. In einigen Implementierungen werden die Audiodaten von Client 1 und Client 2 nicht an Client 3 gesendet. In anderen Implementierungen können die Audiodaten von Client 1 und Client 2 an Client 3 gesendet werden, werden aber möglicherweise nicht an Client 3 ausgegeben.
  • 13 ist ein beispielhafter RTC-Raumzugangsprozess 1300 gemäß Implementierungen der vorliegenden Offenbarung.
  • Der beispielhafte Prozess 1300 beginnt nach Erhalt einer Anfrage von einer Client-Vorrichtung, einer RTC-Sitzung oder einem RTC-Raum beizutreten, wie in 1302. Wie oben besprochen, kann der beispielhafte Prozess, anstatt von einer anfragenden Partei zu verlangen, sich ein Passwort oder einen anderen Code zu merken und einzugeben, um Zugang zu einer RTC-Sitzung oder einem RTC-Raum zu erhalten, einen Live-Video-Feed von der Client-Vorrichtung erhalten, die Zugang anfordert, wie in 1304. Beispielsweise kann eine auf der Client-Vorrichtung ausgeführte RTC-Anwendung eine Kamera der Client-Vorrichtung aktivieren und einen Live-Video-Feed von der Kamera an die RTC-Sitzung/den RTC-Raum senden.
  • Der empfangene Video-Feed von der anfragenden Client-Vorrichtung kann einem oder mehreren Client-Vorrichtungen in der RTC-Sitzung/dem RTC-Raum präsentiert werden, wie in 1306. In einigen Implementierungen kann das Live-Video von der Client-Vorrichtung als Teil des RTC-Raums präsentiert werden und alle Client-Vorrichtungen können in der Lage sein, den Live-Video-Feed anzusehen und optional auszuwählen, ob der Zugriff auf die Client-Vorrichtung gewährt oder verweigert werden soll. In anderen Implementierungen kann das Live-Video an einen Organisator der RTC-Sitzung oder eine andere designierte Client-Vorrichtung gesendet werden.
  • Während das Live-Video präsentiert wird, wird bestimmt, ob eine Zugangsanfrageantwort empfangen wurde, wie in 1307. Wenn bestimmt wird, dass keine Zugriffsanforderungsantwort empfangen wurde, kehrt der beispielhafte Prozess 1300 zu Block 1306 zurück und die Präsentation des Live-Videos wird fortgesetzt. In einigen Implementierungen kann auch ein Anforderungstimer aufrechterhalten werden und der Video-Feed und die Zugriffsanforderung nur für einen definierten Zeitraum präsentiert werden. Wenn der definierte Zeitraum (z. B. 1 Minute) abläuft, ohne dass eine Zugriffsantwort empfangen wird, kann der beispielhafte Prozess 1300 enden und die Zugriffsanforderung kann abgelehnt werden. In anderen Implementierungen kann, wenn eine Antwort auf eine Zugangsanfrage nicht innerhalb der festgelegten Zeitspanne eingeht, ein akustisches Warnsignal an die RTC-Sitzung/den RTC-Raum ausgegeben werden und/oder der Live-Video-Feed kann an eine andere Client-Vorrichtung der RTC-Sitzung/des RTC-Raums gesendet werden, um eine Zugangsantwort zu erhalten.
  • Wenn bei Entscheidungsblock 1307 festgestellt wird, dass eine Zugriffsanforderungsantwort empfangen wurde, wird wie bei 1308 festgestellt, ob die Zugriffsanforderung gewährt wird. Wenn festgestellt wird, dass die Zugriffsanforderung genehmigt wird, wird eine RTC-Sitzung zwischen der anfragenden Client-Vorrichtung und jeder der anderen Client-Vorrichtungen, die in der RTC-Sitzung eingeschlossen sind, aufgebaut, wie in 1310. Wird die RTC-Sitzung verweigert, wird die Zugangsanforderung der anfordernden Client-Vorrichtung verweigert, wie in 1312.
  • 14A bis 14B ist ein beispielhafter sicherer Dateizugriffsprozess 1400 gemäß Implementierungen der vorliegenden Offenbarung.
  • Der beispielhafte Prozess 1400 beginnt mit dem Empfang einer Zugriffsanforderung für eine gesicherte Datei, wie in 1402. Anstatt von einem Client zu verlangen, dass er sich an ein Passwort oder eine andere Zugriffsanforderung erinnert, ermöglichen die offenbarten Implementierungen eine visuelle Überprüfung.
  • In diesem Beispiel wird festgestellt, ob der Dateieigentümer der Datei, für die die Zugriffsanforderung gestellt wurde, verfügbar ist, wie in 1403. In einigen Implementierungen kann ein Dateieigentümer auf der Grundlage von Statusinformationen, die von einer oder mehreren mit dem Dateieigentümer verbundenen Vorrichtungen und/oder Anwendungen bereitgestellt werden, als verfügbar oder potenziell verfügbar bestimmt werden.
  • Wenn festgestellt wird, dass der Eigentümer der Datei verfügbar ist, wird ein Live-Video-Feed von der Client-Vorrichtung erhalten, die Zugriff auf die gesicherte Datei anfordert, wie in 1404. So kann beispielsweise eine Benachrichtigung oder Anforderung an die Client-Vorrichtung gesendet werden, die den Zugriff auf eine Kamera der Client-Vorrichtung anfordert, und es können Live-Videodaten von der Kamera der anfordernden Client-Vorrichtung abgerufen werden. Der erhaltene Live-Video-Feed kann dann an die Client-Vorrichtung des Eigentümers der sicheren Datei gesendet werden und auf der Client-Vorrichtung des Eigentümers mit der Bitte um Bestätigung angezeigt werden, ob die anfordernde Client-Vorrichtung auf die sichere Datei zugreifen kann, wie in 1406.
  • Während das Live-Video präsentiert wird, wird bestimmt, ob eine Zugangsanfrageantwort empfangen wurde, wie in 1407. Wenn bestimmt wird, dass keine Zugriffsanforderungsantwort empfangen wurde, kehrt der beispielhafte Prozess 1400 zu Block 1406 zurück und die Präsentation des Live-Videos wird fortgesetzt. In einigen Implementierungen kann auch ein Anforderungstimer aufrechterhalten werden und der Video-Feed und die Zugriffsanforderung nur für einen definierten Zeitraum präsentiert werden. Wenn der definierte Zeitraum (z. B. 1 Minute) abläuft, ohne dass eine Zugriffsantwort empfangen wird, kann der beispielhafte Prozess 1400 enden und die Zugriffsanforderung kann abgelehnt werden. In anderen Implementierungen kann, wenn eine Antwort auf eine Zugangsanfrage nicht innerhalb der festgelegten Zeitspanne eingeht, ein akustisches Warnsignal auf der Client-Vorrichtung des Besitzers ausgegeben werden, um eine Antwort zu erhalten. Als weiteres Beispiel kann, wenn eine Antwort auf eine Zugriffsanforderung nicht innerhalb der definierten Zeitspanne empfangen wird, festgestellt werden, dass der Eigentümer der sicheren Datei nicht verfügbar ist, der Live-Video-Feed beendet werden und der Beispielprozess 1400 kann zu Block 1403 zurückkehren und so fortfahren, als ob der Eigentümer der sicheren Datei nicht verfügbar wäre.
  • Wenn bei Entscheidungsblock 1407 festgestellt wird, dass eine Zugriffsanforderungsantwort empfangen wurde, wird wie bei 1408 festgestellt, ob die Zugriffsanforderung gewährt wird. Wenn festgestellt wird, dass die Zugriffsanfrage genehmigt wird, wird der Zugriff auf die sichere Datei durch die anfordernde Client-Vorrichtung erlaubt, wie in 1410. In einigen Implementierungen kann der Zugriff für die anfordernde Client-Vorrichtung und/oder einen Benutzer der anfordernden Client-Vorrichtung unbegrenzt sein. In anderen Implementierungen kann der Zugriff für einen definierten Zeitraum erfolgen. Wenn festgestellt wird, dass die Antwort eine Ablehnung der Anforderung ist, wird der Zugriff auf die sichere Datei verweigert, wie in 1412.
  • Kehrt man zum Entscheidungsblock 1403 zurück und stellt fest, dass der Dateieigentümer nicht verfügbar ist, wird, anstatt einen Live-Video-Feed an die Client-Vorrichtung des Eigentümers zu senden, ein Videosegment von der anfordernden Client-Vorrichtung abgerufen, wie in 1414 (14B). Das Videosegment kann ein beliebiger definierter Zeitraum sein, der ausreicht, um Videodaten eines Benutzers an der anfordernden Client-Vorrichtung zu erfassen, die Zugriff auf die sichere Datei anfordert. Beispielsweise kann das Videosegment zehn Sekunden lang, kürzer als zehn Sekunden oder länger als zehn Sekunden sein.
  • Das erhaltene Videosegment kann dann an den Dateieigentümer zur Überprüfung und Antwort gesendet werden, ob der anfordernden Client-Vorrichtung Zugriff auf die sichere Datei gewährt werden soll, wie in 1416. Die Übertragung des Videosegments kann beispielsweise per E-Mail, SMS, Videonachricht, Post an einen RTC-Raum usw. erfolgen.
  • Nachdem das Videosegment zur Durchsicht und Überprüfung an den Dateieigentümer gesendet wurde, wird festgestellt, ob eine Zugriffsanforderungsantwort empfangen wurde, wie in 1418. Wenn keine Zugriffsanforderungsantwort empfangen wurde, bleibt der beispielhafte Prozess 1400 bei Entscheidungsblock 1418 und wartet auf eine Zugriffsanforderungsantwort.
  • Wenn festgestellt wird, dass eine Antwort auf eine Zugriffsanforderung empfangen wurde, wird wie in 1420 festgestellt, ob der Client-Vorrichtung, die den Zugriff auf die sichere Datei beantragt hat, Zugriff gewährt wurde. Wenn festgestellt wird, dass die Zugriffsanfrage genehmigt wird, wird der Zugriff auf die sichere Datei durch die anfordernde Client-Vorrichtung erlaubt, wie in 1422. In einigen Implementierungen kann der Zugriff für die anfordernde Client-Vorrichtung und/oder einen Benutzer der anfordernden Client-Vorrichtung unbegrenzt sein. In anderen Implementierungen kann der Zugriff für einen definierten Zeitraum erfolgen. Wenn festgestellt wird, dass die Antwort eine Ablehnung der Anforderung ist, wird der Zugriff auf die sichere Datei verweigert, wie in 1424.
  • 15 ist eine beispielhafte RTC-Sitzung 1500 gemäß Implementierungen der vorliegenden Offenbarung. Der beispielhafte Prozess 1500 kann während eines Teils oder der gesamten RTC-Sitzung für einen RTC-Raum durchgeführt werden. In einer solchen Konfiguration kann ein RTC-Raum mehrere RTC-Sitzungen haben. In anderen Implementierungen kann der beispielhafte Prozess fortgesetzt werden, solange der RTC-Raum aktiv ist, wobei eine einzelne RTC-Sitzung für die Dauer des RTC-Raums andauert.
  • Der beispielhafte Prozess 1500 beginnt mit dem Aufbau einer RTC-Sitzung wie in 1502. Wie hierin beschrieben, kann eine RTC-Sitzung eine beliebige Dauer oder Zeitspanne sein, während die eine oder mehrere Client-Vorrichtungen mit einem RTC-Raum verbunden sind. Beispielsweise kann eine erste Client-Vorrichtung einem RTC-Raum beitreten oder einen erstellen. Wenn die Client-Vorrichtung dem RTC-Raum beitritt, kann die RTC-Sitzung aufgebaut werden. Alternativ kann die RTC-Sitzung mit der Erstellung des RTC-Raums eingerichtet werden und fortgesetzt werden, bis der RTC-Raum geschlossen oder abgeschlossen ist.
  • Der beispielhafte Prozess 1500 kann auch bestimmen, ob die RTC-Sitzung aufgezeichnet werden soll, wie in 1504. Eine Aufzeichnung einer RTC-Sitzung kann eine Audio- und/oder Videoaufzeichnung der RTC-Sitzung sein, die in einem Speicher, z. B. in einem Speicher des RTC-Verwaltungssystems, gespeichert wird und zu einem späteren Zeitpunkt zur Überprüfung der RTC-Sitzung zugänglich ist. Wenn bestimmt wird, dass die RTC-Sitzung aufgezeichnet werden soll, wird die Aufzeichnung der RTC-Sitzung initiiert, wie in 1506.
  • Nach dem Start der Aufzeichnung der RTC-Sitzung oder wenn festgestellt wird, dass die RTC-Sitzung nicht aufgezeichnet werden soll, wird eine RTC-Raumuhr, die hierin auch als globale Uhr oder Synchronisationsuhr bezeichnet wird, beibehalten, wie in 1508.
  • Zusätzlich zur Einrichtung einer RTC-Raumuhr werden der RTC-Sitzung wie in 1510 Dateianzeigen, Client-Vorrichtungen, die während der RTC-Sitzung mit dem RTC-Raum verbunden sind, Benutzer, die der Client-Vorrichtung entsprechen, und/oder andere Informationen im Zusammenhang mit dem RTC-Raum/der RTC-Sitzung zugeordnet. Im Allgemeinen können alle Informationen, die sich auf die RTC-Sitzung/den RTC-Raum beziehen, als Metadaten angegeben und mit der RTC-Sitzung verknüpft werden.
  • Im weiteren Verlauf der RTC-Sitzung wird festgestellt, ob ein Ereignis im Rahmen der RTC-Sitzung eingetreten ist, wie in 1512. Ein Ereignis kann alles sein, was sich auf die RTC-Sitzung bezieht, wie z. B., aber nicht beschränkt auf, ein Benutzer/Client-Vorrichtung, die während der RTC-Sitzung dem RTC-Raum beitritt, eine Auswahl eines Dateiindikators, um auf eine durch den Dateiindikator dargestellte Datei zuzugreifen, eine Seitenkommunikation zwischen zwei oder mehr Teilnehmern der RTC-Sitzung, eine Anmerkung oder ein Kommentar zu einer Datei, auf die während der RTC-Sitzung zugegriffen wird, eine Wiedergabe, Pause, Rücklauf, schneller Vorlauf usw. einer Datei, auf die während der RTC-Sitzung zugegriffen wird, usw.
  • Wenn bestimmt wird, dass kein Ereignis aufgetreten ist, bleibt der beispielhafte Prozess 1500 bei Entscheidungsblock 1512. Bei der Bestimmung eines Ereignisses während der RTC-Sitzung wird jedoch ein Zeitstempel, der der RTC-Raumuhr entspricht, für das Auftreten des Ereignisses generiert, wie in 1514, und Metadaten über das Ereignis (einschließlich des Zeitstempels) werden generiert und gespeichert, wie in 1516. Die Metadaten können alle Informationen in Bezug auf das Ereignis sein, wie z. B. eine an dem Ereignis beteiligte Datei, eine Position innerhalb einer Datei, als das Ereignis aufgetreten ist, die Art des Ereignisses, an dem Ereignis beteiligte Benutzer, die Ereignisdauer usw.
  • Nach Erstellung und Speicherung der einem Ereignis entsprechenden Metadaten wird festgestellt, ob die RTC-Sitzung abgeschlossen ist, wie in 1518. Wenn festgestellt wird, dass die RTC-Sitzung nicht abgeschlossen wurde, kehrt der beispielhafte Prozess zum Entscheidungsblock 1512 zurück und fährt mit der Überwachung auf ein nächstes Ereignis fort. Wenn bestimmt wird, dass die RTC-Sitzung abgeschlossen ist, wenn die RTC-Sitzung aufgezeichnet wurde, wird die Aufzeichnung der RTC-Sitzung gestoppt, wie in 1520. Zusätzlich zum Stoppen einer Aufzeichnung der RTC-Sitzung oder falls keine Aufzeichnung stattgefunden hat, wird für die RTC-Sitzung wie in 1522 eine Zeitlinie generiert, die die RTC-Sitzung und jedes zeitgestempelte Ereignis darstellt, das während der RTC-Sitzung aufgetreten ist. Wie hierin erörtert, kann die Zeitleiste für eine RTC-Sitzung als Überblick oder Zusammenfassung der RTC-Sitzung verwendet werden und kann in einigen Implementierungen interaktiv sein, indem ein Benutzer einen Zeitstempel oder Ereignisindikator in der Zeitleiste auswählen kann und das dem Indikator entsprechende Ereignis auf der Grundlage der dem Ereignis entsprechenden Metadaten neu erstellt werden kann.
  • 16 ist ein beispielhafter RTC-Sitzungsprüfungsprozess 1600 gemäß Implementierungen der vorliegenden Offenbarung. Der beispielhafte Prozess 1600 kann nach Abschluss einer beliebigen RTC-Sitzung und Generierung einer RTC-Sitzungszeitachse für diese RTC-Sitzung ausgeführt werden.
  • Der beispielhafte Prozess 1600 beginnt mit dem Präsentieren einer Zeitachse einer RTC-Sitzung, wie in 1602. In einigen Implementierungen kann die der Zeitachse entsprechende RTC-Sitzung eine abgeschlossene RTC-Sitzung sein und die Zeitachse kann einen Teil oder die gesamte RTC-Sitzung darstellen. Wenn in anderen Implementierungen beispielsweise eine RTC-Sitzung während der gesamten Dauer eines RTC-Raums andauert, kann die Zeitachse die gesamte oder einen Teil der RTC-Sitzung bis zu einem bestimmten Zeitpunkt darstellen, beispielsweise bis zum Zugriffspunkt der Zeitachse durch den beispielhaften Prozess 1600 oder bis zu einem letzten aufgezeichneten Ereignis als Teil der RTC-Sitzung usw.
  • Bei der Darstellung der Zeitleiste wird festgestellt, ob ein auf der Zeitleiste angegebenes Ereignis ausgewählt wurde, wie in 1604. Wie oben erörtert, kann jedes Ereignis, das während einer RTC-Sitzung auftritt, mit einem Zeitstempel versehen und auf der Zeitachse für die RTC-Sitzung angezeigt werden. Wenn bestimmt wird, dass die Ereignisauswahl nicht stattgefunden hat, kehrt der beispielhafte Prozess 1600 zu Block 1602 zurück und fährt fort. Wenn festgestellt wird, dass eine Auswahl eines Ereignisses aus der Zeitleiste stattgefunden hat, wird das der Auswahl entsprechende Ereignis auf der Grundlage der Ereignis-Metadaten, die zum Zeitpunkt des Ereignisses während der RTC-Sitzung generiert wurden, neu erstellt, wie in 1606, und dem Benutzer präsentiert, wie in 1608.
  • Wenn es sich bei dem Ereignis beispielsweise um einen Benutzer handelt, der einen angehaltenen Frame eines Videos mit Anmerkungen versieht, kann auf die relevanten Teile des Videoframes vom Quellort des Videos (z. B. einer Client-Vorrichtung, die das Video speichert) zugegriffen werden, die Anmerkungen können aus dem Speicher des RTC-Verwaltungssystems abgerufen werden, und der angehaltene Frame des Videos und die entsprechenden Anmerkungen können überlagert und dem Benutzer so präsentiert werden, als ob das Ereignis eingetreten wäre. Ebenso kann der Benutzer in einigen Implementierungen mit dem Ereignis interagieren, indem er sich in Bezug auf das Ereignis zeitlich vorwärts oder rückwärts bewegt. Zum Beispiel kann das Ereignis eine Zeitdauer haben, wie zum Beispiel fünf Minuten, und der Benutzer kann durch das Ereignis fortschreiten, während das Ereignis während der RTC-Sitzung aufgetreten ist. Wenn in anderen Beispielen die RTC-Sitzung aufgezeichnet wurde, kann dem Benutzer bei Auswahl des Ereignisses ein relevanter Teil der Aufzeichnung der RTC-Sitzung präsentiert werden, sodass der Benutzer das Ereignis während der RTC-Sitzung sehen kann.
  • Nachdem das Ereignis neu erstellt und präsentiert wurde, wird bestimmt, ob der beispielhafte Prozess 1600 für die präsentierte Zeitachse fortgesetzt werden soll, wie in 1610. Wenn zum Beispiel die Zeitachse weiterhin präsentiert wird, kann bestimmt werden, dass der beispielhafte Prozess 1600 fortgesetzt werden soll. Wenn bestimmt wird, dass der beispielhafte Prozess 1600 fortgesetzt werden soll, kehrt der beispielhafte Prozess 1600 zu Block 1604 zurück und überwacht die Auswahl eines anderen Ereignisses aus der Zeitachse. Wenn bestimmt wird, dass der beispielhafte Prozess nicht fortgesetzt werden soll, wird der beispielhafte Prozess 1600 abgeschlossen, wie in 1612.
  • 17 ist ein Blockdiagramm von Beispielkomponenten einer Client-Vorrichtung 1730, einer tragbaren Vorrichtung 1732, einer am Körper tragbaren Vorrichtung 1733 und Remote-Rechenressourcen 1703, in Übereinstimmung mit Implementierungen der vorliegenden Offenlegung.
  • Wie dargestellt, kann die tragbare Vorrichtung eine beliebige tragbare Vorrichtung 1732 sein, wie z. B. ein Tablet, ein Mobiltelefon, ein Laptop usw. Das bildgebende Element 1740 der tragbaren Vorrichtung 1732 kann jede Form von optischem Aufnahmesensor oder - gerät umfassen, das zum Fotografieren oder anderweitigen Aufzeichnen von Informationen oder Daten verwendet werden kann. Wie in 17 dargestellt, ist die tragbare Vorrichtung 1732 mit dem Netzwerk 1702 verbunden und umfasst einen oder mehrere Speicher 1744 oder Speicherkomponenten (z. B. eine Datenbank oder einen anderen Datenspeicher), einen oder mehrere Prozessoren 1741 und ein oder mehrere Elemente zur Bestimmung von Position/Ausrichtung/Winkel 1728, eine Ausgabe, wie z. B. eine Anzeige 1734, einen Lautsprecher, eine haptische Ausgabe usw. Die tragbare Vorrichtung 1732 kann sich auch mit dem Netz 1702 verbinden oder anderweitig mit diesem kommunizieren, indem sie digitale Daten sendet und empfängt.
  • Die tragbare Vorrichtung 1732 kann an jedem beliebigen Ort und in jeder beliebigen Umgebung verwendet werden, um Identitätsinformationen zu generieren und an das RTC-Verwaltungssystem 1701 zu senden und/oder um Bilder von Farbkarten und der Anzeige einer Client-Vorrichtung 1730 zu erzeugen. Die tragbare Vorrichtung 1732 kann auch eine oder mehrere Anwendungen 1745 einschließen, wie z. B. einen Streaming-Videoplayer, eine Anwendung zur Erfassung von Identitätsinformationen, eine Anwendung zur Benutzerauthentifizierung usw., die jeweils in einem Speicher gespeichert sein können, der von dem einen oder den mehreren Prozessoren 1741 der tragbaren Vorrichtung ausgeführt werden kann, um den Prozessor der tragbaren Vorrichtung zu veranlassen, verschiedene Funktionen oder Aktionen durchzuführen. Zum Beispiel kann die Anwendung 1745 bei ihrer Ausführung Bilddaten und Standortinformationen (z. B. Identitätsinformationen) erzeugen und diese Informationen dem RTC-Verwaltungssystem 1701 bereitstellen.
  • Die Anwendung 1745 kann nach Erzeugung von Identitätsinformationen, Bildern einer Farbkarte und Anzeige der Client-Vorrichtung 1730 usw. die Informationen über das Netzwerk 1702 an das RTC-Verwaltungssystem 1701 zur weiteren Verarbeitung senden.
  • Die Client-Vorrichtung 1730, die der tragbaren Vorrichtung ähnlich sein kann, kann ein bildgebendes Element 1720, wie z. B. eine Kamera, eine Anzeige 1731, einen Prozessor 1726 und einen Speicher 1724 einschließen, der eine oder mehrere Anwendungen 1725 speichert, wie z. B. eine RTC-Anwendung. Die Anwendung 1725 kann über das Netzwerk 1702 mit dem RTC-Verwaltungssystem 1701, einer Anwendung 1745, die auf der tragbaren Vorrichtung 1732 läuft, und/oder einer Anwendung 1755, die auf der am Körper tragbaren Vorrichtung 1733 läuft, kommunizieren. Beispielsweise kann die auf der Client-Vorrichtung 1730 ausgeführte Anwendung 1725 periodisch oder kontinuierlich mit einer auf der tragbaren Vorrichtung 1732 ausgeführten Anwendung 1745 und/oder einer auf der am Körper tragbaren Vorrichtung 1733 ausgeführten Anwendung 1755 kommunizieren, um den Standort der tragbaren Vorrichtung 1732 und/oder der am Körper tragbaren Vorrichtung 1733 in Bezug auf die Client-Vorrichtung 1730 zu bestimmen. Als weiteres Beispiel kann die Anwendung 1725 Streaming-Videodaten senden und/oder empfangen und diese auf einer Anzeige 1731 der Client-Vorrichtung 1730 darstellen. In weiteren Beispielen kann die Anwendung 1725, die auf der Client-Vorrichtung 1730 ausgeführt wird, die Framerate und/oder Komprimierung als Reaktion auf ein Triggerereignis ändern und/oder bei Erkennung des Triggerereignisses ein hochaufgelöstes Bild erzeugen und das Streaming des Inhalts starten/beenden.
  • Bei der am Körper tragbaren Vorrichtung 1733 kann es sich um jede Art von Vorrichtung handeln, die von einem Teilnehmer getragen oder angezogen werden kann. Beispiele für am Körper tragbare Vorrichtungen sind unter anderem Ringe, Uhren, Halsketten, Kleidung usw. Ähnlich wie die tragbare Vorrichtung 1732 und die Client-Vorrichtung 1730 kann die am Körper tragbare Vorrichtung 1733 einen oder mehrere Prozessoren 1750 und einen Speicher 1752 einschließen, der Programmanweisungen oder Anwendungen speichert, die, wenn sie von dem einen oder den mehreren Prozessoren 1750 ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, eine oder mehrere Verfahren, Schritte oder Anweisungen durchzuführen. Ebenso kann die am Körper tragbare Vorrichtung eine oder mehrere Eingabe-/Ausgabevorrichtungen 1754 einschließen, die verwendet werden können, um Informationen über einen Teilnehmer zu erhalten, der die am Körper tragbare Vorrichtung trägt, und/oder um dem Teilnehmer Informationen zu liefern. Die E/A-Vorrichtung 1754 kann z. B. einen Beschleunigungsmesser zur Überwachung der Bewegung des Teilnehmers, einen Herzfrequenz-, Temperatur- oder Schweißmesser zur Überwachung eines oder mehrerer Vitalparameter des Teilnehmers usw. einschließen. Als weiteres Beispiel kann die E/A-Vorrichtung 1754 ein Mikrofon oder einen Lautsprecher einschließen.
  • Im Allgemeinen schließt das RTC-Verwaltungssystem 1701 Rechenressource(n) 1703 ein. Die Rechenressource(n) 1703 sind von der tragbaren Vorrichtung 1732, der Client-Vorrichtung 1730 und/oder der am Körper tragbaren Vorrichtung 1733 getrennt. Ebenso können die Rechenressource(n) 1703 so konfiguriert sein, dass sie über das Netzwerk 1702 mit der tragbaren Vorrichtung 1732, der Client-Vorrichtung 1730, der am Körper tragbaren Vorrichtung 1733 und/oder anderen externen Rechenressourcen, Datenspeichern usw. kommunizieren.
  • Wie dargestellt, kann die Rechenressource(n) 1703 von der tragbaren Vorrichtung 1732, der Client-Vorrichtung 1730 und/oder der am Körper tragbaren Vorrichtung 1733 entfernt sein und als ein oder mehrere Server 1703(1), 1703(2), ..., 1703(P) implementiert sind und in einigen Fällen einen Teil einer über ein Netzwerk zugänglichen Computerplattform bilden können, die als eine Computerinfrastruktur von Prozessoren, Speicher, Software, Datenzugriff usw. implementiert ist, die von Komponenten/Vorrichtungen des RTC-Verwaltungssystems 1701, der tragbaren Vorrichtung 1732, der Client-Vorrichtungen 1730 und/oder der am Körper tragbaren Vorrichtungen 1733 über das Netzwerk 1702, wie ein Intranet (z. g., lokales Netzwerk), das Internet, etc.
  • Die Rechenressource(n) 1703 erfordern keine Kenntnisse des Endbenutzers über den physischen Standort und die Konfiguration des Systems, das die Dienste bereitstellt. Gängige Ausdrücke für diese Remote-Rechenressource(n) 1703 sind unter anderem „On-Demand-Computing“, „Software as a Service (SaaS)“, „Platform Computing“, „netzzugängliche Plattform“, „Cloud-Dienste“, „Rechenzentren“ und so weiter. Jeder der Server 1703(1)-(P) enthält einen Prozessor 1717 und einen Speicher 1719, der ein RTC-Verwaltungssystem 1701 speichern oder anderweitig darauf zugreifen kann.
  • Das Netzwerk 1702 kann ein beliebiges verdrahtetes Netzwerk, drahtloses Netzwerk oder eine Kombination davon sein und kann das Internet ganz oder teilweise umfassen. Außerdem kann das Netzwerk 1702 ein Personal Area Network, ein Local Area Network, ein Wide Area Network, ein Kabelnetzwerk, ein Satellitennetzwerk, ein Mobiltelefonnetzwerk oder eine Kombination davon sein. Das Netzwerk 1702 kann auch ein öffentlich zugängliches Netzwerk verbundener Netzwerke sein, die möglicherweise von verschiedenen unterschiedlichen Parteien betrieben werden, wie z. B. dem Internet. In einigen Implementierungen kann das Netzwerk 1702 ein privates oder halbprivates Netzwerk sein, wie etwa ein Firmen- oder Universitäts-Intranet. Das Netzwerk 1702 kann ein oder mehrere drahtlose Netzwerke enthalten, wie etwa ein Global System for Mobile Communications (GSM)-Netzwerk, ein Code Division Multiple Access (CDMA)-Netzwerk, ein Long Term Evolution (LTE)-Netzwerk oder eine andere Art von drahtlosem Netzwerk. Protokolle und Komponenten zum Kommunizieren über das Internet oder irgendeine der anderen zuvor erwähnten Arten von Kommunikationsnetzwerken sind Fachleuten auf dem Gebiet der Computerkommunikation gut bekannt und müssen daher hierin nicht ausführlicher beschrieben werden.
  • Die hierin beschriebenen Computer, Server, Vorrichtungen und dergleichen verfügen über die notwendige Elektronik, Software, Speicher, Datenbanken, Firmware, Logik-/Zustandsmaschinen, Mikroprozessoren, Kommunikationsverbindungen, Anzeigen oder andere visuelle oder akustische Benutzerschnittstellen, Druckvorrichtungen und alle anderen Eingabe-/Ausgabeschnittstellen, um die hierin beschriebenen Funktionen oder Dienste bereitzustellen und/oder die hierin beschriebenen Ergebnisse zu erzielen. Diejenigen, die sich mit der Materie auskennen, werden auch erkennen, dass die Benutzer solcher Computer, Server, Vorrichtungen und dergleichen eine Tastatur, ein Tastenfeld, eine Maus, einen Stift, einen Berührungsbildschirm oder eine andere Vorrichtung (nicht dargestellt) oder Verfahren zur Interaktion mit den Computern, Servern, Vorrichtungen und dergleichen verwenden können.
  • Das RTC-Verwaltungssystem 1701, die Anwendung 1745, die tragbare Vorrichtung 1732, die Anwendung 1725, die Client-Vorrichtung 1730, die Anwendung 1755 und/oder die am Körper tragbare Vorrichtung 1733 können beliebige webfähige oder Internet-Anwendungen oder -Funktionen oder beliebige andere Client-Server-Anwendungen oder - Funktionen, einschließlich E-Mail oder andere Nachrichtenübermittlungstechniken, verwenden, um sich mit dem Netz 1702 zu verbinden oder miteinander zu kommunizieren, z. B. über Kurznachrichten oder Multimedia-Nachrichten (SMS oder MMS), Bluetooth, NFC, usw. Zum Beispiel können die Server 1703-1, 1703-2, ..., 1703-P geeignet sein, Informationen oder Daten in Form von synchronen oder asynchronen Nachrichten vom RTC-Verwaltungssystem 1701 an den Prozessor 1741 oder andere Komponenten der tragbaren Vorrichtung 1732, an den Prozessor 1726 oder andere Komponenten der Client-Vorrichtung 1730 und/oder an den Prozessor 1750 oder andere Komponenten der am Körper tragbaren Vorrichtung 1733 oder an jede andere Computervorrichtung in Echtzeit oder nahezu in Echtzeit oder in einem oder mehreren Offline-Prozessen über das Netz 1702 zu übertragen. Der Durchschnittsfachmann würde erkennen, dass das RTC-Verwaltungssystem 1701 mit einer beliebigen Anzahl von Computervorrichtungen arbeiten oder kommunizieren kann, die über das Netzwerk kommunizieren können, einschließlich, aber nicht beschränkt auf Set-Top-Boxen, persönliche digitale Assistenten, digitale Mediaplayer, Webpads, Laptop-Computer, Desktop-Computer, Lesegeräte für elektronische Bücher, Mobiltelefone und dergleichen. Die Protokolle und Komponenten zum Bereitstellen einer Kommunikation zwischen solchen Vorrichtungen sind Fachleuten auf dem Gebiet der Computerkommunikation gut bekannt und müssen hierin nicht ausführlicher beschrieben werden.
  • Die hierin beschriebenen Daten und/oder computerausführbaren Anweisungen, Programme, Firmware, Software und dergleichen (hierin auch als „computerausführbare“ Komponenten bezeichnet) können auf einem computerlesbaren Medium gespeichert sein, das sich in Computern oder Computerkomponenten wie den Servern 1703-1, 1703-2, ..., 1703-P, einem oder mehreren der Prozessoren 1717, 1741, 1726, 1750 oder anderen Computern oder Steuersystemen zugänglich sind und Sequenzen von Anweisungen enthalten, die, wenn sie von einem Prozessor (z. B. einer Zentraleinheit oder „CPU“) ausgeführt werden, den Prozessor veranlassen, alle oder einen Teil der hierin beschriebenen Funktionen, Dienste und/oder Verfahren durchzuführen. Solche computerausführbaren Anweisungen, Programme, Anwendungen, Software und dergleichen können in den Speicher eines oder mehrerer Computer geladen werden, indem ein Laufwerkmechanismus verwendet wird, der dem computerlesbaren Medium zugeordnet ist, wie z. B. einem Diskettenlaufwerk, CD-ROM-Laufwerk, DVD-ROM-Laufwerk, Netzwerkschnittstelle oder dergleichen, oder über externe Verbindungen.
  • Einige Implementierungen der Systeme und Verfahren der vorliegenden Offenbarung können auch als computerausführbares Programmprodukt bereitgestellt werden, das ein nichttransitorisches, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen (in komprimierter oder unkomprimierter Form) einschließt, die verwendet werden können, um einen Computer (oder eine andere elektronische Vorrichtung) so zu programmieren, dass er die hierin beschriebenen Prozesse oder Verfahren durchführt. Zu den maschinenlesbaren Speichermedien der vorliegenden Offenbarung können unter anderem Festplatten, Disketten, optische Disketten, CD-ROMs, DVDs, ROMs, RAMs, löschbare programmierbare ROMs („EPROM“), elektrisch löschbare programmierbare ROMs („EEPROM“), Flash-Speicher, magnetische oder optische Karten, Festkörperspeichervorrichtungen oder andere Arten von Medien/maschinenlesbaren Medien gehören, die zur Speicherung elektronischer Anweisungen geeignet sind. Ferner können Implementierungen auch als ein computerausführbares Programmprodukt bereitgestellt werden, das ein vorübergehendes maschinenlesbares Signal (in komprimierter oder unkomprimierter Form) einschließt. Beispiele für maschinenlesbare Signale, unabhängig davon, ob sie mit einem Träger moduliert sind oder nicht, können unter anderem Signale einschließen, für die ein Computersystem oder eine Maschine, die ein Computerprogramm beherbergt oder ausführt, konfiguriert werden kann, um darauf zuzugreifen, oder auch Signale, die über das Internet oder andere Netzwerke heruntergeladen werden können.
  • Hierin offenbarte Implementierungen können ein computerimplementiertes Verfahren einschließen. Das computerimplementierte Verfahren kann einen oder mehrere der folgenden Schritte einschließen: Aufbau einer RTC-Sitzung zwischen einer Quellvorrichtung und einer Zielvorrichtung, um eine Zusammenarbeit über ein Video zwischen einem ersten Teilnehmer an der Quellvorrichtung und einem zweiten Teilnehmer an der Zielvorrichtung zu ermöglichen, Abspielen des Videos auf der Quellvorrichtung, so dass das Video auf einer ersten Anzeige der Quellvorrichtung dem ersten Teilnehmer als Teil der Zusammenarbeit präsentiert wird, Streaming des Videos, während das Video abgespielt wird, über einen ersten Kanal der RTC-Sitzung und mit einer ersten Framerate und einer ersten Komprimierung von der Quellvorrichtung zur Zielvorrichtung, so dass die Zielvorrichtung das Video auf einer zweiten Anzeige der Zielvorrichtung dem zweiten Teilnehmer als Teil der Zusammenarbeit präsentiert, und Erfassen einer Pause in der Wiedergabe des Videos. Darüber hinaus kann das computerimplementierte Verfahren als Reaktion auf die Erkennung der Pause auch einschließen: Beenden des Streaming des Videos, Erzeugen eines hochaufgelösten Bildes des angehaltenen Videos und Senden des hochaufgelösten Bildes von der Quellvorrichtung an die Zielvorrichtung zur Darstellung auf der zweiten Anzeige der Zielvorrichtung anstelle des Streaming-Videos, so dass dem zweiten Teilnehmer, der die zweite Anzeige der Zielvorrichtung betrachtet, das hochaufgelöste Bild des angehaltenen Videos präsentiert wird. Ebenso kann das computerimplementierte Verfahren während der Präsentation des hochaufgelösten Bildes einschließen: Aufrechterhaltung der RTC-Sitzung zwischen der Quellvorrichtung und der Zielvorrichtung und Ermöglichung der Zusammenarbeit über die RTC-Sitzung, wobei die Zusammenarbeit mindestens eine Audiokommunikation zwischen dem ersten Teilnehmer und dem zweiten Teilnehmer oder eine visuelle Kommentierung des hochaufgelösten Bildes durch den zweiten Teilnehmer an der Zielvorrichtung einschließt, die über die RTC-Sitzung gesendet und auf der ersten Anzeige der Quellvorrichtung dargestellt wird.
  • Optional kann das computerimplementierte Verfahren weiterhin einschließen, dass nach dem Senden des hochaufgelösten Bildes ein zweites Abspielen des Videos an der Quellvorrichtung detektiert wird und als Reaktion auf das Detektieren des zweiten Abspielens des Videos das Streaming des Videos wieder aufgenommen wird, wenn das Video über den ersten Kanal der RTC-Sitzung mit der ersten Framerate und der ersten Komprimierung von der Quellvorrichtung zur Zielvorrichtung abgespielt wird, so dass die Zielvorrichtung das Video auf der zweiten Anzeige der Zielvorrichtung darstellt, wenn das Video empfangen wird. Optional kann das computerimplementierte Verfahren ferner als Reaktion auf das Erkennen des zweiten Abspielens des Videos das Entfernen des hochaufgelösten Bildes von der zweiten Anzeige der Zielvorrichtung einschließen, so dass das Streaming-Video auf der zweiten Anzeige der Zielvorrichtung dargestellt wird. Optional kann das computerimplementierte Verfahren ferner das Ermöglichen des Austauschs anderer visueller Informationen zwischen der Quellvorrichtung und der Zielvorrichtung über einen zweiten Kanal der RTC-Sitzung einschließen. Optional kann das computerimplementierte Verfahren ferner das Erzeugen einer ersten Vielzahl von hochaufgelösten Bildern einschließen, die Frames des Videos entsprechen, die vor einem Frame liegen, der verwendet wird, um das hochaufgelöste Bild zu erzeugen, das Erzeugen einer zweiten Vielzahl von hochaufgelösten Bildern, die Frames des Videos entsprechen, die nach dem Frame liegen, der verwendet wird, um das hochaufgelöste Bild zu erzeugen, und das Senden der ersten Vielzahl von hochaufgelösten Bildern und der zweiten Vielzahl von hochaufgelösten Bildern von der Quellvorrichtung an die Zielvorrichtung.
  • Hierin offenbarte Implementierungen können ein Verfahren einschließen. Das Verfahren kann einen oder mehrere der folgenden Schritte einschließen: Aufbau einer RTC-Sitzung zwischen einer Quellvorrichtung und einer Zielvorrichtung, um eine Zusammenarbeit über einen Inhalt zwischen einem ersten Teilnehmer an der Quellvorrichtung und einem zweiten Teilnehmer an der Zielvorrichtung zu ermöglichen, Abspielen des Inhalts auf der Quellvorrichtung, so dass der Inhalt auf einer ersten Anzeige der Quellvorrichtung dem ersten Teilnehmer als Teil der Zusammenarbeit präsentiert wird, Streaming des Inhalts, wenn der Inhalt von der Quellvorrichtung zu der Zielvorrichtung abgespielt wird, über einen ersten Kanal der RTC-Sitzung und mit einer ersten Framerate und einer ersten Komprimierung, so dass die Zielvorrichtung den Inhalt auf einer zweiten Anzeige der Zielvorrichtung präsentiert, wenn der Inhalt für den zweiten Teilnehmer als Teil der Zusammenarbeit empfangen wird, und Erfassen eines ersten Ereignisses, das dem Inhalt entspricht. Zusätzlich kann das Verfahren als Reaktion auf das Erkennen des ersten Ereignisses das Übertragen des Inhalts von der Quellvorrichtung und über den ersten Kanal der RTC-Sitzung mit einer zweiten Framerate und einer zweiten Komprimierung einschließen, so dass die Zielvorrichtung den Inhalt auf der zweiten Anzeige mit der zweiten Framerate und der zweiten Komprimierung darstellt, wobei die zweite Framerate und die zweite Komprimierung von der ersten Framerate und der ersten Komprimierung verschieden sind. Darüber hinaus kann das Verfahren, während der Inhalt mit der zweiten Framerate und der zweiten Komprimierung übertragen wird, Folgendes einschließen: Aufrechterhalten der RTC-Sitzung zwischen der Quellvorrichtung und der Zielvorrichtung und Ermöglichen der Zusammenarbeit über die RTC-Sitzung, wobei die Zusammenarbeit mindestens eine Audiokommunikation zwischen dem ersten Teilnehmer und dem zweiten Teilnehmer oder eine visuelle Kommentierung des Inhalts durch den zweiten Teilnehmer an der Zielvorrichtung umfasst, die über die RTC-Sitzung gesendet und auf der ersten Anzeige der Quellvorrichtung dargestellt wird.
  • Optional kann das erste Ereignis eine Pause des Abspielens des Inhalts sein. Optional kann die zweite Framerate eine niedrigere Framerate als die erste Framerate sein und die zweite Komprimierung kann eine niedrigere Komprimierung als die erste Komprimierung sein. Optional kann die Quellvorrichtung mindestens eine Client-Vorrichtung oder ein RTC-Verwaltungssystem sein. Optional kann das Verfahren ferner ein oder mehrere oder das Erkennen eines zweiten Ereignisses einschließen, und als Reaktion auf das zweite Ereignis die Wiederaufnahme des Streamings des Inhalts über den ersten Kanal der RTC-Sitzung mit der ersten Framerate und der ersten Komprimierung von der Quellvorrichtung zur Zielvorrichtung. Optional kann das zweite Ereignis das Abspielen des Inhalts auf der Quellvorrichtung einschließen. Optional kann die Bandbreite einer Verbindung zwischen der Quellvorrichtung und der Zielvorrichtung im Wesentlichen unverändert bleiben. Optional kann das Verfahren auch das Erhalten des Inhalts mit der zweiten Framerate und der zweiten Komprimierung von einer auf der Quellvorrichtung ausgeführten Anwendung einschließen. Optional kann das Verfahren ferner das Empfangen einer Anweisung, die das erste Ereignis verursacht, von der Zielvorrichtung einschließen. Optional kann das Verfahren ferner das Ermöglichen des Austauschs anderer visueller Informationen zwischen der Quellvorrichtung und der Zielvorrichtung über einen zweiten Kanal der RTC einschließen.
  • Hierin offenbarte Implementierungen können ein Computersystem mit einem oder mehreren Prozessoren und einem Speicher einschließen, der Programmanweisungen speichert. Die Programmanweisungen können, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, eine Sitzung zwischen einer Quellvorrichtung und einer Zielvorrichtung aufzubauen, um eine Zusammenarbeit über ein Video zwischen einem ersten Teilnehmer an der Quellvorrichtung und einem zweiten Teilnehmer an der Zielvorrichtung zu ermöglichen, das Video auf der Quellvorrichtung abzuspielen, so dass das Video auf einer ersten Anzeige der Quellvorrichtung dem ersten Teilnehmer als Teil der Zusammenarbeit präsentiert wird, das Video während der Wiedergabe des Videos mit einer ersten Framerate und einer ersten Komprimierung von der Quellvorrichtung zur Zielvorrichtung zu streamen, so dass die Zielvorrichtung das Video auf einer zweiten Anzeige der Zielvorrichtung dem zweiten Teilnehmer als Teil der Zusammenarbeit präsentiert, und/oder eine Pause des Streaming des Videos zu erkennen. Die Programmanweisungen können, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, ferner bewirken, dass der eine oder die mehreren Prozessoren als Reaktion auf die Erkennung der Pause den Videostream von der ersten Framerate und der ersten Komprimierung auf eine zweite Framerate und eine zweite Komprimierung ändern, wobei die zweite Framerate niedriger ist als die erste Framerate und die zweite Komprimierung niedriger ist als die erste Komprimierung, und während das Video mit der zweiten Framerate und der zweiten Komprimierung gestreamt wird: Aufrechterhalten der Sitzung zwischen der Quellvorrichtung und der Zielvorrichtung und Ermöglichen der Zusammenarbeit über die Sitzung, wobei die Zusammenarbeit mindestens eines von einer Audiokommunikation zwischen dem ersten Teilnehmer und dem zweiten Teilnehmer oder einer visuellen Kommentierung des Videos durch den zweiten Teilnehmer an der Zielvorrichtung einschließt, die über die Sitzung gesendet und auf der ersten Anzeige der Quellvorrichtung dargestellt wird.
  • Optional können die Programmanweisungen, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, um den einen oder die mehreren Prozessoren zu veranlassen, zumindest den Videostream zu ändern, ferner Anweisungen einschließen, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, ferner den einen oder die mehreren Prozessoren veranlassen, zumindest ein hochaufgelöstes Bild des angehaltenen Videos zu erzeugen und das hochaufgelöste Bild mit der zweiten Framerate und der zweiten Komprimierung von der Quellvorrichtung an die Zielvorrichtung zu senden. Optional können die Programmanweisungen, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren außerdem veranlassen, zumindest eine Wiedergabe des Videos zu erkennen und als Reaktion auf die Erkennung der Wiedergabe den Videostream mit der ersten Framerate und der ersten Komprimierung wieder aufzunehmen. Optional veranlassen die Programmanweisungen, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren außerdem dazu, zumindest in Reaktion auf die Erkennung der Pause von einer Anwendung, die auf der Quellvorrichtung ausgeführt wird, ein hochaufgelöstes Bild des angehaltenen Videos zu erhalten, und wobei der veränderte Videostream das hochaufgelöste Bild einschließt. Optional kann das hochaufgelöste Bild der Zielvorrichtung zur Darstellung auf einer Anzeige der Zielvorrichtung bereitgestellt werden, während das Video angehalten wird.
  • Hierin offenbarte Implementierungen können ein computerimplementiertes Verfahren einschließen. Das computerimplementierte Verfahren kann eines oder mehrere der folgenden Schritte einschließen: Aufbauen einer RTC-Sitzung zwischen einer ersten Vorrichtung und einer zweiten Vorrichtung, Empfangen, durch die erste Vorrichtung, von ersten Metadaten, die einer ersten Datei entsprechen, die auf der ersten Vorrichtung gespeichert ist, Erzeugen, zumindest teilweise auf der Grundlage der ersten Metadaten, eines ersten Dateiindikators, der für die erste auf der erste Vorrichtung gespeicherte Datei repräsentativ ist, Empfangen, durch die zweite Vorrichtung, von zweiten Metadaten, die einer zweiten Datei entsprechen, die auf der zweiten Vorrichtung gespeichert ist, Erzeugen, zumindest teilweise auf der Grundlage der zweiten Metadaten, eines zweiten Dateiindikators, der für die zweite auf der zweiten Vorrichtung gespeicherte Datei repräsentativ ist, Konsolidieren zumindest des ersten Dateiindikators und des zweiten Dateiindikators in einem Remote-Ordner, Präsentieren des Remote-Ordners, der den ersten Dateiindikator und den zweiten Dateiindikator enthält, gleichzeitig auf der ersten Vorrichtung und der zweiten Vorrichtung, ohne die erste Datei von der ersten Vorrichtung oder die zweite Datei von der zweiten Vorrichtung zu erhalten, und Empfangen einer Auswahl des zweiten Dateiindikators, der für die zweite auf der zweiten Vorrichtung gespeicherte Datei repräsentativ ist, von der ersten Vorrichtung. Das computerimplementierte Verfahren kann ferner als Reaktion auf den Empfang der Auswahl einschließen, dass die zweite Datei, die auf der zweiten Vorrichtung gespeichert ist, als Teil der RTC-Sitzung von der zweiten Vorrichtung gestreamt und gleichzeitig auf der ersten Vorrichtung und der zweiten Vorrichtung dargestellt wird.
  • Optional kann das computerimplementierte Verfahren weiterhin einschließen, während die zweite Datei gestreamt wird, von einer dritten Vorrichtung, die in der RTC-Sitzung eingeschlossen ist, einen Dateiinteraktionsbefehl in Bezug auf das Streaming der zweiten Datei zu empfangen, und in Reaktion auf den Empfang des Dateiinteraktionsbefehls von der dritten Vorrichtung zu veranlassen, dass der Dateiinteraktionsbefehl von der zweiten Vorrichtung ausgeführt wird, um die Interaktion in Bezug auf das Streaming der zweiten Datei durchzuführen. Optional kann der Dateiinteraktionsbefehl mindestens einer von einem Abspielbefehl, einem Rücklaufbefehl, einem Schnellvorlaufbefehl, einem Pausebefehl, einem Zeitlupenbefehl oder einem Stoppbefehl sein. Optional kann das computerimplementierte Verfahren ferner eines oder mehrere von Folgendem einschließen: Empfangen einer Anmerkung, die der zweiten Datei entspricht, die von der zweiten Vorrichtung gestreamt wird, von der ersten Vorrichtung und während der RTC-Sitzung, Aufrechterhalten einer Synchronisierung zwischen der Anmerkung und der zweiten Datei, und Speichern der Anmerkung und der Synchronisation als Teil eines RTC-Sitzungsdatensatzes. Optional kann das computerimplementierte Verfahren ferner einen oder mehrere der folgenden Schritte einschließen: Bestimmen einer Seitenkommunikation, die zwischen der ersten Vorrichtung und einer dritten Vorrichtung als Teil der RTC-Sitzung aktiviert werden soll, Deaktivieren eines ersten Audiokanalausgangs zu der zweiten Vorrichtung, so dass Audio von der ersten Vorrichtung nicht an die zweite Vorrichtung ausgegeben wird, Deaktivieren eines zweiten Audiokanalausgangs zu der zweiten Vorrichtung, so dass Audio von der dritten Vorrichtung nicht an die zweite Vorrichtung ausgegeben wird, Aufrechterhalten eines dritten Audiokanalausgangs zu der ersten Vorrichtung, so dass Audio von der zweiten Vorrichtung an die erste Vorrichtung ausgegeben wird, Aufrechterhalten eines vierten Audiokanalausgangs zu der dritten Vorrichtung, so dass Audio von der zweiten Vorrichtung an die dritte Vorrichtung ausgegeben wird, Aufrechterhalten eines fünften Audiokanalausgangs zu der ersten Vorrichtung, so dass Audio von der dritten Vorrichtung an die erste Vorrichtung ausgegeben wird, und Aufrechterhalten eines sechsten Audiokanalausgangs zu der dritten Vorrichtung, so dass Audio von der ersten Vorrichtung an die dritte Vorrichtung ausgegeben wird.
  • Hierin offenbarte Implementierungen können ein Verfahren einschließen. Das Verfahren kann einen oder mehrere der folgenden Schritte einschließen: Aufbau einer RTC-Sitzung zwischen einer Vielzahl von Vorrichtungen, Empfangen von ersten Metadaten, die einer ersten Datei entsprechen, die auf der ersten Vorrichtung gespeichert ist, von einer ersten Vorrichtung der Vielzahl von Vorrichtungen, gleichzeitiges Präsentieren eines ersten Dateiindikators, der für die erste Datei steht, die auf der ersten Vorrichtung gespeichert ist, an jede der Vielzahl von Vorrichtungen, Empfangen einer Auswahl des ersten Dateiindikators, der für die auf der ersten Vorrichtung gespeicherte erste Datei repräsentativ ist, von einer zweiten Vorrichtung der Vielzahl von Vorrichtungen, und als Reaktion auf den Empfang der Auswahl, Bewirken, dass die auf der ersten Vorrichtung gespeicherte erste Datei als Teil der RTC-Sitzung von der ersten Vorrichtung gestreamt und gleichzeitig jeder der Vielzahl von Vorrichtungen präsentiert wird.
  • Optional kann es sich bei der ersten Datei um eine Videodatei handeln und/oder die Auswahl des Dateiindikators kann eine Aufforderung zur Wiedergabe der ersten Datei einschließen. Optional kann das Verfahren ferner einschließen, dass an jeder der mehreren Vorrichtungen eine Dateisteuervorrichtung bereitgestellt wird, so dass jede Vorrichtung der mehreren Vorrichtungen einen Dateisteuerbefehl ausgeben kann, um ein Streaming der ersten Datei von der ersten Vorrichtung zu steuern. Optional kann das Verfahren ferner einen oder mehrere der folgenden Schritte einschließen: Empfangen eines Dateisteuerungsbefehls von einer dritten Vorrichtung der Vielzahl von Vorrichtungen, um die Wiedergabe der ersten Datei zu ändern, und Veranlassen, dass der Dateisteuerungsbefehl an der ersten Vorrichtung ausgeführt wird, um die Wiedergabe der ersten Datei zu ändern. Optional kann das Verfahren ferner einen oder mehrere der folgenden Schritte einschließen: Empfangen, während der RTC-Sitzung, von einer dritten Vorrichtung, die nicht an der RTC-Sitzung teilnimmt, einer Anforderung, der RTC-Sitzung beizutreten, Erhalten, von der dritten Vorrichtung, eines Live-Video-Feeds von einer Kamera an der dritten Vorrichtung, Präsentieren, zumindest der ersten Vorrichtung der Vielzahl von Vorrichtungen des Live-Video-Feeds und eine Anforderung, dass der dritten Vorrichtung ein Zugriff gewährt wird, um an der RTC-Sitzung teilzunehmen, Empfangen, von der ersten Vorrichtung eine Anzeige, dass der dritten Vorrichtung ein Zugriff gewährt werden soll, und als Reaktion auf den Empfang der Anzeige die dritte Vorrichtung in die RTC-Sitzung einzubeziehen. Optional kann die erste Vorrichtung als Organisator der RTC-Sitzung angegeben werden. Optional kann das Verfahren weiterhin einen oder mehrere der folgenden Schritte einschließen: Empfangen von zweiten Metadaten, die einer zweiten Datei entsprechen, die auf der dritten Vorrichtung gespeichert ist, von einer dritten Vorrichtung der Vielzahl von Vorrichtungen, Zusammenführen des ersten Dateiindikators und eines zweiten Dateiindikators, der die zweite Datei darstellt, in einem Remote-Ordner, und wobei das Präsentieren das gleichzeitige Präsentieren des Remote-Ordners, der den ersten Dateiindikator und den zweiten Dateiindikator enthält, an jede der Vielzahl von Vorrichtungen einschließt. Optional kann das Verfahren weiterhin einen oder mehrere der folgenden Schritte einschließen: Empfangen einer Eingabe von einer dritten Vorrichtung in Bezug auf die erste Datei während der RTC-Sitzung und während die erste Datei von der ersten Vorrichtung gestreamt wird, Synchronisieren der Eingabe mit einem Frame des Streamings der ersten Datei, der gleichzeitig jeder der Vielzahl von Vorrichtungen zu einem Zeitpunkt präsentiert wird, zu dem die Eingabe empfangen wird, und Speichern von Metadaten, die die Synchronisationsinformationen und die Eingabe einschließen. Optional kann das Verfahren ferner das Aufzeichnen der RTC-Sitzung einschließen.
  • Hierin offenbarte Implementierungen können ein Computersystem mit einem oder mehreren Prozessoren und einem Speicher einschließen, der Programmanweisungen speichert. Die Programmanweisungen können, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, eine Echtzeit-Kommunikationssitzung („RTC“) zwischen einer Vielzahl von Vorrichtungen einzurichten, gleichzeitig jeder der Vielzahl von Vorrichtungen einen Remote-Ordner zu präsentieren, der mindestens Folgendes einschließt: einen ersten Dateiindikator einer ersten Datei, die in einer ersten Vorrichtung der Vielzahl von Vorrichtungen gespeichert ist, und/oder einen zweiten Dateiindikator einer zweiten Datei, die in einer zweiten Vorrichtung der Vielzahl von Vorrichtungen gespeichert ist, von einer dritten Vorrichtung der Vielzahl von Vorrichtungen eine Anforderung zum Streamen der ersten Datei zu empfangen, in Reaktion auf die Anforderung zumindest teilweise auf der Grundlage von Metadaten, die dem ersten Dateiindikator entsprechen, zu bestimmen, dass die erste Datei auf der ersten Vorrichtung gespeichert ist, und/oder die Anforderung, die erste Datei zu streamen, an die erste Vorrichtung zu senden, so dass ein Streaming der ersten Datei auf der ersten Vorrichtung als Teil der RTC-Sitzung eingeleitet und gleichzeitig jeder der Vielzahl von Vorrichtungen präsentiert wird.
  • Optional können die Programmanweisungen, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, ferner Anweisungen einschließen, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, ferner bewirken, dass der eine oder die mehreren Prozessoren zumindest an jeder der mehreren Vorrichtungen und während die erste Datei gestreamt wird, eine Dateisteuereinheit bereitstellen, so dass jede Vorrichtung der mehreren Vorrichtungen einen Dateisteuerbefehl ausgeben kann, um ein Streaming der ersten Datei von der ersten Vorrichtung zu steuern. Optional kann der Dateisteuerungsbefehl das Abspielen der ersten Datei, das Pausieren der ersten Datei, das Stoppen der ersten Datei, das Zurückspulen der ersten Datei, den schnellen Vorlauf der ersten Datei oder die Zeitlupe der ersten Datei ermöglichen. Optional bewirken die Programmanweisungen, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, ferner bei dem einen oder den mehreren Prozessoren zumindest: Empfangen, während der RTC-Sitzung, von einer vierten Vorrichtung, die nicht an der RTC-Sitzung teilnimmt, einer Anforderung, der RTC-Sitzung beizutreten, Erhalten, von der vierten Vorrichtung, eines Live-Video-Feeds von einer Kamera an der vierten Vorrichtung, Präsentieren, als Teil der RTC-Sitzung, des Live-Video-Feeds und einer Anforderung, dass der vierten Vorrichtung ein Zugang gewährt wird, um der RTC-Sitzung beizutreten, Empfangen, von mindestens einer Vorrichtung der Vielzahl von Vorrichtungen, eines Hinweises, dass der vierten Vorrichtung Zugang gewährt werden soll, und/oder als Reaktion auf den Empfang des Hinweises, Einschließen der vierten Vorrichtung in die RTC-Sitzung. Optional bewirken die Programmanweisungen, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, ferner bei dem einen oder den mehreren Prozessoren zumindest: Empfangen erster Metadaten von der ersten Vorrichtung, die der ersten Datei entsprechen, wobei die ersten Metadaten zumindest einen ersten Ort der ersten Datei angeben, und/oder Empfangen zweiter Metadaten von der zweiten Vorrichtung, die der zweiten Datei entsprechen, wobei die zweiten Metadaten zumindest einen zweiten Ort der zweiten Datei angeben. Optional bewirken die Programmanweisungen, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, ferner, dass der eine oder die mehreren Prozessoren zumindest eine Seitenkommunikation bestimmen, die zwischen der ersten Vorrichtung und der zweiten Vorrichtung der RTC-Sitzung aktiviert werden soll, so dass Audio zwischen der ersten Vorrichtung und der zweiten Vorrichtung nicht an die dritte Vorrichtung ausgegeben wird, aber Audio von der dritten Vorrichtung an die erste Vorrichtung und die zweite Vorrichtung ausgegeben wird, einen ersten Audiokanalausgang an die dritte Vorrichtung deaktivieren, so dass Audio von der ersten Vorrichtung nicht an die dritte Vorrichtung ausgegeben wird, einen zweiten Audiokanalausgang an die dritte Vorrichtung deaktivieren, so dass Audio von der zweiten Vorrichtung nicht an der dritten Vorrichtung ausgegeben wird, einen dritten Audiokanalausgang an die erste Vorrichtung aufrechterhalten, so dass Audio von der zweiten Vorrichtung an die erste Vorrichtung ausgegeben wird, einen vierten Audiokanalausgang an die zweite Vorrichtung, so dass Audio von der ersten Vorrichtung an die zweite Vorrichtung ausgegeben wird, einen fünften Audiokanalausgang an die erste Vorrichtung aufrechterhalten, so dass Audio von der dritten Vorrichtung an die erste Vorrichtung ausgegeben wird, und/oder einen sechsten Audiokanalausgang an die zweite Vorrichtung aufrechterhalten, so dass Audio von der dritten Vorrichtung an die zweite Vorrichtung ausgegeben wird.
  • VISUELLE ASPEKTE VON CHATROOM - MIXED REALITY
  • Sogenannte Augmented-Reality-, Mixed-Reality- und Virtual-Reality-Systeme werden immer üblicher. In einigen Implementierungen kann ein Chat-System in Verbindung mit einer tragbaren Vorrichtung oder einer am Körper tragbaren Vorrichtung verwendet werden, die visuelle Überlagerungen mit dem System, das verwendet wird, einblendet. Beispielsweise kann die Software mit einem Augmented-Reality-Headset kombiniert werden, um die anderen Teilnehmer des Chats im Rahmen einer RTC-Sitzung mit dem manipulierten Material, beispielsweise der Videobearbeitung, zu überlagern oder zu umgeben. Die Augmented Reality kann verwendet werden, um andere Aspekte der Benutzeroberfläche zu überlagern, wie z. B. Spielsteuerungen oder farblich passende Felder oder Tafeln. Solche Steuerungen und/oder Aktionen können durch körperliche Bewegungen wie Handgesten oder durch vom System verstandene Sprachbefehle gesteuert werden.
  • NOTIZEN UND CHATFUNKTIONEN UND MASCHINELLES LERNEN
  • In einigen Implementierungen kann das RTC-Verwaltungssystem Notizen und Chats aufzeichnen und diese Notizen und Chats synchronisieren sowie den Kanal transkribieren und den Text des Transkripts mit dem Video unter Verwendung von Zeitstempeln synchronisieren. Ein Benutzer kann nach jedem Wort suchen, das in den Notizen oder dem Transkript erfasst ist. „Fuzzy-Matching“ (um Rechtschreibfehler bei der Transkription auszugleichen) und phonetisches Matching (Suchen von Wörtern, die wie das Gesuchte klingen) können ebenfalls verwendet werden, um zusätzliche mögliche Übereinstimmungen zu erzielen. Beim Klicken auf Wörter in einer Zeitleiste oder in einem Chat- oder Transkriptfenster wird der entsprechende Teil des Videos wiedergegeben. Beim Anklicken der Suchergebnisse für ein bestimmtes Wort wird der entsprechende Teil des Videos wiedergegeben.
  • Einzelne Stellen in einer Aufzeichnung, an denen ein Frame eines kollaborativen Videos als Teil der Aufzeichnung mit einem Lesezeichen versehen werden kann. Das RTC-Verwaltungssystem weiß möglicherweise nicht, was markiert wird, falls ein Benutzer seinen Bildschirm teilt. Alternativ kann das RTC-Verwaltungssystem speziell eine Videodatei gemeinsam nutzen, wobei das RTC-Verwaltungssystem in diesem Fall weiß, welches Frame des Videos zu einem bestimmten Zeitpunkt betrachtet wird. Ein Moment in der Aufnahme kann mit einem Lesezeichen versehen werden, sodass später darauf zurückgegriffen werden kann. Ein gezeichneter oder kommentierter Frame wird automatisch mit einem Lesezeichen versehen. Jeder angehaltene Frame kann auch mit einem Lesezeichen versehen werden, wobei das System feststellt, dass sich die Bildschirmfreigabe im Laufe der Zeit nicht wesentlich ändert (mit Ausnahme der Cursorbewegung).
  • Ein visueller horizontaler oder vertikaler Streifen, der die Länge der Aufzeichnung darstellt und ihr entspricht, kann verwendet werden, um wahlfrei auf Teile der Aufzeichnung einer RTC-Sitzung zuzugreifen. Ein Cursor oder ein visueller Indikator innerhalb des Streifens kann die Position der aktuellen Wiedergabe innerhalb der Aufzeichnung anzeigen. Punkte, Quadrate oder andere unterschiedliche visuelle Indikatoren können auf dem Streifen platziert werden, um Lesezeichen anzuzeigen. Unterschiedliche visuelle Indikatoren können unterschiedliche Arten von Lesezeichen anzeigen, wie etwa Diskussionspunkte, gespeicherte Standbilder, Hinzufügen oder Entfernen von Personal in der Aufzeichnung oder dergleichen.
  • Ein Export kann in eine Datei erfolgen, z. B. ein PDF oder ein Dokument zum Herunterladen. Der Export umfasst alle oder eine Reihe von mit Lesezeichen versehenen Bereichen. Der Export enthält möglicherweise nicht nur Standbilder, sondern auch eingebettete animierte Videos (z. B. animierte GIFs), Links zu Online-Videos der gesamten Konversation, die zu diesem Teil des Videos führt und diesen einschließt, usw. Auf diese Weise werden nur die hervorstechenden, besprochenen Teile einer inhaltlichen Besprechung zusammengefasst.
  • Der Export kann als Nachweisseite (Zusammenfassung) verwendet werden. Jeder kommentierte oder mit Lesezeichen versehene Frame oder angehaltene Frame kann in die Korrekturseite aufgenommen werden. Die Beweisseite kann eine Reihe von eingebetteten Videos enthalten, eines für jede Konversation. Beispielsweise kann eine ganze zweistündige Filmbesprechungssitzung eine Stunde konzentrierter Kommentare in fünf- bis zehnminütigen Abschnitten zu Teilen des Inhalts ergeben.
  • Alternativ oder zusätzlich dazu kann die Zusammenfassungsseite auf einer gemeinsam genutzten Online-Webseite gehostet werden, die die zusammengefassten relevanten Abschnitte statt einer herunterladbaren PDF-Datei oder einer anderen Datei einschließt.
  • Ein erster Benutzer kann auf eine RTC-Sitzung zugreifen, eine Videodatei (z. B. einen Film) auswählen, sie abspielen, die Datei mit Anmerkungen versehen (unter Verwendung von Audio- und Videoaufzeichnungen), um einen Kommentar zu liefern (z. B. einen „Kommentar des Regisseurs“), den die beschriebenen Implementierungen in Verbindung mit der Originaldatei mit einem Zeitstempel versehen können, und es kann eine Exportdatei erzeugt werden, in der die Eingaben des ersten Benutzers zusammengefasst sind. Anschließend kann ein zweiter Benutzer auf die Exportdatei zugreifen und den Kommentar abspielen. Die Quelle des Videos kann ein hochgeladenes Video oder ein auf einem anderen Content-Verwaltungssystem (z. B. DROPBOX, MICROSOFT AZURE usw.) gespeichertes Video sein.
  • Darüber hinaus kann ein maschineller Lernalgorithmus trainiert werden, um nicht relevante Audiogespräche und Konversationen, die sich direkt auf den angesehenen Inhalt beziehen, zu kategorisieren. Somit kann das System automatisch eine Zusammenfassungsseite erstellen, die automatisch auf der Grundlage von Ausgaben des maschinellen Lernalgorithmus verbessert werden kann, wodurch der Schwerpunkt auf den Schlüsselkommentar gelegt wird. Andere herausgefilterte Kommentare können am Ende mit groben Transkripten eingefügt werden, damit der Benutzer überfliegen und sehen kann, ob der maschinelle Lernalgorithmus etwas Entscheidendes übersehen hat.
  • ZUGRIFF AUF AUFZEICHNUNGEN UND 2-FAKTOR-SICHERHEIT
  • Die Menschen müssen Zugriff auf die Aufzeichnungen haben, aber diese sind sehr sensibel, weil sie vor der Veröffentlichung IP zusammen mit vertraulichen Kommentaren aufweisen. Somit Sicherheit rund um das Teilen von Clips wie „Korrekturen des Regisseurs an einer Bearbeitung“.
  • Das System kann auf einer Ebene geschützt werden, indem eine Form der Zwei-Faktor-Authentifizierung erzwungen wird. Jedes Mal, wenn der Benutzer auf eine Aufzeichnung zugreifen möchte, wird er aufgefordert, einen 2FA-Code von einer Authentifizierungs-App oder über eine Textnachricht einzugeben, die an eine Vorrichtung gesendet wird, die er bekanntermaßen besitzt. Alternativ kann ein 2FA-Code an eine benutzerdefinierte Authentifizierungsanwendung gesendet werden, die auch andere Formen der Sicherheit erzwingt, z. B. die Anforderung biometrischer Sicherheit auf der Vorrichtung, wie einen Fingerabdruck oder ein Bild oder Video, unter Verwendung der integrierten Authentifizierungsfunktionen der Mobilvorrichtung. Oder die 2FA kann in Form einer erneuten Authentifizierung der Person erfolgen, indem sie eine benutzerdefinierte App aufruft und ihre biometrischen Daten in dieser App erfasst und dann die Authentifizierung auf die Vorrichtung überträgt, die sie für den Zugriff auf die Aufzeichnung verwenden möchte.
  • In einer anderen Ausführungsform kann die Authentifizierung an jemand anderen gesendet werden. Ein Anforderer versucht, mit seinen Anmeldedaten auf eine Aufzeichnung zuzugreifen. Er wird aufgefordert, sein Bild als Video bereitzustellen und das Video anzufordern. Der Clip oder das Bild des Anforderers wird per Textnachricht oder an eine benutzerdefinierte Anwendung gesendet, die auf einem Produzenten oder einer verantwortlichen, autorisierten Person ausgeführt wird, die dann angibt, dass er auf diesen Clip zugreifen darf. Diese Angabe der Erlaubnis wandert zum RTC-Verwaltungssystem und ermöglicht den Zugriff auf den Inhalt.
  • Kombinationen könnten es ermöglichen, dass der Clip jedes Mal aufgezeichnet wird, und 2FA erlaubt dem Benutzer den Zugang, und alle Zugriffe werden in einen Zeitablauf integriert, der von einem Vorgesetzten auf einmal überprüft werden kann, um z. B. für eine Woche alle Personen zu ermitteln, die auf Inhalte zugegriffen haben, und festzustellen, ob sie hätten zugreifen dürfen. Dies ermöglicht schnelle, regelmäßige menschliche Sicherheitsüberprüfungen und stellt sicher, dass jede aufgerufene Umcodierung berücksichtigt wird.
  • In Ausführungsformen sind Aufzeichnungen nur abspielbar, während kontinuierlich eine biometrische Videoverifizierung des betrachtenden Benutzers durchgeführt wird, und ähnlich wie bei Konferenzen, wenn der Benutzer wegschaut oder weggeht, wird die Wiedergabe des aufgezeichneten Inhalts deaktiviert.
  • Obwohl die Offenbarung hierin unter Verwendung von beispielhaften Techniken, Komponenten und/oder Prozessen zur Implementierung der Systeme und Verfahren der vorliegenden Offenbarung beschrieben wurde, sollte es dem Fachmann klar sein, dass andere Techniken, Komponenten und/oder Prozesse oder andere Kombinationen und Abfolgen der hierin beschriebenen Techniken, Komponenten und/oder Prozesse verwendet oder durchgeführt werden können, die dieselbe(n) Funktion(en) und/oder dasselbe(n) Ergebnis(e) erzielen, die hierin beschrieben sind und die in den Anwendungsbereich der vorliegenden Offenbarung fallen.
  • Es versteht sich, dass, sofern hierin nicht ausdrücklich oder implizit etwas anderes angegeben ist, alle Merkmale, Eigenschaften, Alternativen oder Modifikationen, die hierin in Bezug auf eine bestimmte Implementierung beschrieben werden, auch auf jede andere hierin beschriebene Implementierung angewendet, verwendet oder in diese integriert werden können, und dass die Zeichnungen und die detaillierte Beschreibung der vorliegenden Offenbarung alle Modifikationen, Äquivalente und Alternativen zu den verschiedenen Implementierungen abdecken sollen, wie sie in den beigefügten Ansprüchen definiert sind. Im Hinblick auf die hierin beschriebenen Verfahren oder Prozesse der vorliegenden Offenbarung, einschließlich, aber nicht beschränkt auf die in den 6 bis 9 dargestellten Flussdiagramme, sind die Reihenfolgen, in denen diese Verfahren oder Prozesse dargestellt sind, nicht als Einschränkung der beanspruchten Erfindungen zu verstehen, und eine beliebige Anzahl der hierin beschriebenen Verfahrens- oder Prozessschritte oder -boxen kann in beliebiger Reihenfolge und/oder parallel kombiniert werden, um die hierin beschriebenen Verfahren oder Prozesse zu implementieren. Außerdem sind die Zeichnungen hierin nicht maßstabsgetreu gezeichnet.
  • Konditionale Ausdrücke, wie z. B. „kann“, „könnte“, „würde“ oder „sollte“, sofern nicht ausdrücklich etwas anderes angegeben ist oder im Kontext anders verstanden wird, sollen im Allgemeinen in einer erlaubenden Weise ausdrücken, dass bestimmte Umsetzungen bestimmte Merkmale, Elemente und/oder Schritte einschließen oder einschließen könnten, aber nicht vorschreiben oder erfordern. In ähnlicher Weise sollen Begriffe wie „einschließen“, „einschließlich“ und „schließt ein“ im Allgemeinen „einschließlich, aber nicht beschränkt auf“ bedeuten. Somit sollen derartige Konditionalformulierungen nicht allgemein implizieren, dass Merkmale, Elemente und/oder Schritte in irgendeiner Weise für eine oder mehrere Umsetzungen erforderlich sind, oder dass eine oder mehrere Umsetzungen notwendigerweise Logik zum Entscheiden, mit oder ohne Benutzereingabe oder Eingabeaufforderung, beinhalten, ob diese Merkmale, Elemente und/oder Schritte in einer konkreten Ausführungsform beinhaltet sind oder durchgeführt werden sollen.
  • Die Elemente eines Verfahrens, Prozesses oder Algorithmus, die in Verbindung mit den hierin offenbarten Implementierungen beschrieben werden, können direkt in Hardware, in einem Softwaremodul, das in einer oder mehreren Speichervorrichtungen gespeichert ist und von einem oder mehreren Prozessoren ausgeführt wird, oder in einer Kombination aus beidem verkörpert sein. Ein Softwaremodul kann sich in RAM, Flash-Speicher, ROM, EPROM, EEPROM, Registern, einer Festplatte, einer Wechselplatte, einer CD-ROM, einer DVD-ROM oder jeder anderen Form von nicht transitorischen, computerlesbaren Speichermedien oder physischen Computerspeichern befinden, die in der Technik bekannt sind. Ein Beispielspeichermedium kann mit dem Prozessor verbunden werden, so dass der Prozessor Informationen von dem Speichermedium lesen und in dieses schreiben kann. Alternativ kann das Speichermedium in den Prozessor integriert sein. Das Speichermedium kann flüchtig oder nicht flüchtig sein. Der Prozessor und das Speichermedium können sich in einem ASIC befinden. Der ASIC kann sich in einer Vorrichtung befinden. Alternativ können sich der Prozessor und das Speichermedium als diskrete Komponenten in einer Vorrichtung befinden.
  • Eine disjunktive Formulierung, wie etwa der Ausdruck „mindestens eines von X, Y oder Z“ oder „mindestens eines von X, Y und Z“ wird, sofern nicht ausdrücklich anders angegeben, im Kontext verstanden, wie er im Allgemeinen verwendet wird, um darzustellen, dass ein Gegenstand, ein Begriff usw. entweder X, Y oder Z oder eine beliebige Kombination davon (z. B. X, Y, und/oder Z) sein kann. Somit soll eine derartige disjunktive Sprache im Allgemeinen nicht ausdrücken, dass bestimmte Implementierungen erfordern, dass mindestens eines von X, mindestens eines von Y oder mindestens eines von Z jeweils vorhanden ist.
  • Sofern nicht ausdrücklich anders angegeben, sollten Artikel wie „ein“ oder „eine“ im Allgemeinen so interpretiert werden, dass sie einen oder mehrere beschriebene Artikel einschließen. Dementsprechend sollen Ausdrücke wie „eine Vorrichtung, die dafür konfiguriert ist“ eine oder mehrere der genannten Vorrichtungen einschließen.Eine solche eine oder mehrere der genannten Vorrichtungen können auch kollektiv konfiguriert sein, um die genannten Angaben auszuführen.Beispielsweise kann „ein Prozessor, der so konfiguriert ist, dass er die Angaben A, B und C ausführt“ einen ersten Prozessor einschließen, der so konfiguriert ist, dass er die Angabe A ausführt und mit einem zweiten Prozessor zusammenarbeitet, der so konfiguriert ist, dass er die Angaben B und C ausführt.
  • Die hierin verwendeten Begriffe wie „ungefähr“, „etwa“, „allgemein“, „fast“ oder „im Wesentlichen“, wie sie hierin verwendet werden, stellen einen Wert, eine Menge oder eine Eigenschaft dar, die dem angegebenen Wert, der Menge oder dem angegebenen Wert nahe kommt und noch eine gewünschte Funktion erfüllt oder ein gewünschtes Ergebnis erzielt. Beispielsweise können sich die Begriffe „ungefähr“, „etwa“, „allgemein“, „fast“ oder „im Wesentlichen“ auf einen Betrag beziehen, der weniger als 10 %, weniger als 5 %, weniger als 1 %, weniger als 0,1 % und weniger als 0,01 % des angegebenen Betrags beträgt.
  • Obwohl die Erfindung in Bezug auf veranschaulichende Implementierungen davon beschrieben und dargestellt wurde, können die vorstehenden und verschiedene andere Hinzufügungen und Weglassungen darin und daran vorgenommen werden, ohne vom Geist und Umfang der vorliegenden Offenbarung abzuweichen.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 17179381 [0001]
    • US 62978554 [0001]
    • US 17139472 [0001]
    • US 16794962 [0001]

Claims (15)

  1. Verfahren, das Folgendes umfasst: Einrichten einer Echtzeit-Kommunikationssitzung („RTC“) zwischen einer Quellvorrichtung und einer Zielvorrichtung, um eine Zusammenarbeit über einen Inhalt zwischen einem ersten Teilnehmer an der Quellvorrichtung und einem zweiten Teilnehmer an der Zielvorrichtung zu ermöglichen; Abspielen des Inhalts auf der Quellvorrichtung, so dass der Inhalt auf einer ersten Anzeige der Quellvorrichtung dem ersten Teilnehmer als Teil der Zusammenarbeit präsentiert wird; Streamen des Inhalts, während der Inhalt von der Quellvorrichtung an die Zielvorrichtung abgespielt wird, über einen ersten Kanal der RTC-Sitzung und mit einer ersten Framerate und einer ersten Komprimierung, sodass die Zielvorrichtung den Inhalt auf einer zweiten Anzeige der Zielvorrichtung darstellt, wenn der Inhalt als Teil der Zusammenarbeit von dem zweiten Teilnehmer empfangen wird; Erfassen eines ersten Ereignisses, das dem Inhalt entspricht; Übertragen, als Reaktion auf das Erkennen des ersten Ereignisses, des Inhalts von der Quellvorrichtung und über den ersten Kanal der RTC-Sitzung mit einer zweiten Framerate und einer zweiten Komprimierung, so dass die Zielvorrichtung den Inhalt auf der zweiten Anzeige mit der zweiten Framerate und der zweiten Komprimierung darstellt, wobei die zweite Framerate und die zweite Komprimierung von der ersten Framerate und der ersten Komprimierung verschieden sind; während der Inhalt mit der zweiten Framerate und der zweiten Komprimierung übertragen wird: Aufrechterhalten der RTC-Sitzung zwischen der Quellvorrichtung und der Zielvorrichtung; und Ermöglichen der Zusammenarbeit über die RTC-Sitzung, wobei die Zusammenarbeit mindestens eine Audiokommunikation zwischen dem ersten Teilnehmer und dem zweiten Teilnehmer oder eine visuelle Kommentierung des Inhalts durch den zweiten Teilnehmer an der Zielvorrichtung beinhaltet, die über die RTC-Sitzung gesendet und auf der ersten Anzeige der Quellvorrichtung dargestellt wird.
  2. Verfahren nach Anspruch 1, wobei das erste Ereignis eine Pause des Abspielens des Inhalts ist.
  3. Verfahren nach einem der Ansprüche 1 oder 2, wobei: die zweite Framerate eine niedrigere Framerate als die erste Framerate ist; und die zweite Komprimierung eine niedrigere Komprimierung als die erste Komprimierung ist.
  4. Verfahren nach einem der Ansprüche 1, 2 oder 3, wobei die Quellvorrichtung mindestens eines von einer Client-Vorrichtung oder einem RTC-Verwaltungssystem ist.
  5. Verfahren nach einem der Ansprüche 1, 2, 3 oder 4, ferner umfassend: Erkennen eines zweiten Ereignisses; und als Reaktion auf das zweite Ereignis die Wiederaufnahme des Streamings des Inhalts über den ersten Kanal der RTC-Sitzung mit der ersten Framerate und der ersten Komprimierung von der Quellvorrichtung zur Zielvorrichtung.
  6. Verfahren nach Anspruch 5, wobei das zweite Ereignis ein Abspielen des Inhalts auf der Quellvorrichtung ist.
  7. Verfahren nach einem der Ansprüche 1, 2, 3, 4, 5 oder 6, wobei eine Bandbreite einer Verbindung zwischen der Quellvorrichtung und der Zielvorrichtung im Wesentlichen unverändert bleibt.
  8. Verfahren nach einem der Ansprüche 1, 2, 3, 4, 5, 6 oder 7, ferner umfassend: Erhalten des Inhalts mit der zweiten Framerate und der zweiten Komprimierung von einer auf der Quellvorrichtung ausgeführten Anwendung.
  9. Verfahren nach einem der Ansprüche 1, 2, 3, 4, 5, 6, 7 oder 8, ferner umfassend: Empfangen einer Anweisung von der Zielvorrichtung, die das erste Ereignis verursacht.
  10. Verfahren nach einem der Ansprüche 1, 2, 3, 4, 5, 6, 7, 8 oder 9, ferner umfassend: Ermöglichen des Austauschs anderer visueller Informationen zwischen der Quellvorrichtung und der Zielvorrichtung über einen zweiten Kanal der RTC-Sitzung.
  11. Computersystem, umfassend: einen oder mehrere Prozessoren; und einen Speicher, der Programmanweisungen speichert, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren mindestens zu Folgendem veranlassen: Einrichten einer Sitzung zwischen einer Quellvorrichtung und einer Zielvorrichtung, um eine Zusammenarbeit über ein Video zwischen einem ersten Teilnehmer an der Quellvorrichtung und einem zweiten Teilnehmer an der Zielvorrichtung zu ermöglichen; Abspielen des Videos auf der Quellvorrichtung, so dass das Video auf einer ersten Anzeige der Quellvorrichtung dem ersten Teilnehmer als Teil der Zusammenarbeit präsentiert wird; Streamen des Videos, während das Video abgespielt wird, mit einer ersten Framerate und einer ersten Komprimierung von der Quellvorrichtung an die Zielvorrichtung, sodass die Zielvorrichtung das Video auf einer zweiten Anzeige der Zielvorrichtung dem zweiten Teilnehmer als Teil der Zusammenarbeit präsentiert; Erkennen einer Pause des Streamens des Videos; als Reaktion auf das Erkennen der Pause Ändern des Videostreams von der ersten Framerate und der ersten Komprimierung zu einer zweiten Framerate und einer zweiten Komprimierung, wobei die zweite Framerate niedriger ist als die erste Framerate und die zweite Komprimierung niedriger ist als die erste Komprimierung; während das Video mit der zweiten Framerate und der zweiten Komprimierung gestreamt wird: Aufrechterhalten der Sitzung zwischen der Quellvorrichtung und der Zielvorrichtung; und Ermöglichen der Zusammenarbeit über die Sitzung, wobei die Zusammenarbeit mindestens eine Audiokommunikation zwischen dem ersten Teilnehmer und dem zweiten Teilnehmer oder eine visuelle Kommentierung des Videos durch den zweiten Teilnehmer an der Zielvorrichtung beinhaltet, die über die Sitzung gesendet und auf der ersten Anzeige der Quellvorrichtung dargestellt wird.
  12. Computersystem nach Anspruch 11, wobei die Programmanweisungen, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, um den einen oder die mehreren Prozessoren zu veranlassen, zumindest den Videostream zu ändern, ferner Anweisungen einschließen, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, ferner den einen oder die mehreren Prozessoren zumindest zu Folgendem veranlassen: Generieren eines hochaufgelösten Bildes des angehaltenen Videos; und Senden des hochaufgelösten Bildes von der Quellvorrichtung an die Zielvorrichtung mit der zweiten Framerate und der zweiten Komprimierung.
  13. Computersystem nach einem der Ansprüche 11 oder 12, wobei die Programmanweisungen, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren ferner zu mindestens Folgendem veranlassen: Erkennen ein Abspielen des Videos; und als Reaktion auf die Erkennung des Abspielens: Wiederaufnehmen des Videostreams mit der ersten Framerate und der ersten Komprimierung.
  14. Computersystem nach einem der Ansprüche 11, 12 oder 13, wobei die Programmanweisungen, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren ferner zu mindestens Folgendem veranlassen: Erhalten eines hochaufgelösten Bildes des angehaltenen Videos von einer Anwendung, die auf der Quellvorrichtung ausgeführt wird, als Reaktion auf das Erkennen der Pause; und wobei der geänderte Videostream das hochaufgelöste Bild einschließt.
  15. Computersystem nach einem der Ansprüche 11, 12, 13 oder 14, wobei das hochaufgelöste Bild der Zielvorrichtung zur Darstellung auf einer Anzeige der Zielvorrichtung bereitgestellt wird, während das Video angehalten wird. Komitee
DE112021001105.7T 2020-02-19 2021-02-18 Remote-videozusammenarbeit in echtzeit Pending DE112021001105T5 (de)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US202062978554P 2020-02-19 2020-02-19
US16/794,962 US10887633B1 (en) 2020-02-19 2020-02-19 Real time remote video collaboration
US62/978,554 2020-02-19
US16/794,962 2020-02-19
US17/139,472 2020-12-31
US17/139,472 US11902600B2 (en) 2020-02-19 2020-12-31 Real time remote video collaboration
PCT/US2021/018638 WO2021168160A1 (en) 2020-02-19 2021-02-18 Real time remote video collaboration
US17/179,381 2021-02-18
US17/179,381 US20210258623A1 (en) 2020-02-19 2021-02-18 Remote folders for real time remote collaboration

Publications (1)

Publication Number Publication Date
DE112021001105T5 true DE112021001105T5 (de) 2023-01-12

Family

ID=77273306

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112021001105.7T Pending DE112021001105T5 (de) 2020-02-19 2021-02-18 Remote-videozusammenarbeit in echtzeit

Country Status (5)

Country Link
US (2) US20210258623A1 (de)
AU (1) AU2021222010B2 (de)
DE (1) DE112021001105T5 (de)
GB (1) GB2608078B (de)
WO (1) WO2021168160A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110442366B (zh) * 2019-08-09 2021-06-15 广州视源电子科技股份有限公司 一种传屏处理方法、装置、设备和存储介质
US20220400143A1 (en) * 2021-06-11 2022-12-15 Javid Vahid Real-time visualization module and method for providing the same
US11532333B1 (en) * 2021-06-23 2022-12-20 Microsoft Technology Licensing, Llc Smart summarization, indexing, and post-processing for recorded document presentation
US11716215B2 (en) * 2021-12-18 2023-08-01 Zoom Video Communications, Inc. Dynamic note generation with capturing of communication session content

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8661496B2 (en) * 2002-12-10 2014-02-25 Ol2, Inc. System for combining a plurality of views of real-time streaming interactive video
US8379821B1 (en) * 2005-11-18 2013-02-19 At&T Intellectual Property Ii, L.P. Per-conference-leg recording control for multimedia conferencing
US20100050221A1 (en) * 2008-06-20 2010-02-25 Mccutchen David J Image Delivery System with Image Quality Varying with Frame Rate
WO2011120204A1 (en) * 2010-04-02 2011-10-06 Telefonaktiebolaget L M Ericsson (Publ) Methods, apparatuses and computer program products for pausing video streaming content
WO2012057733A1 (en) * 2010-10-25 2012-05-03 Hewlett-Packard Development Company, L.P. Systems, methods, and devices for adjusting video conference parameters to maintain system performance
JP6229360B2 (ja) * 2012-09-12 2017-11-15 株式会社リコー 通信サーバ、通信システム、プログラム及び通信方法
US9602557B2 (en) * 2012-10-15 2017-03-21 Wowza Media Systems, LLC Systems and methods of communication using a message header that includes header flags
US10887633B1 (en) * 2020-02-19 2021-01-05 Evercast, LLC Real time remote video collaboration

Also Published As

Publication number Publication date
US20240348845A1 (en) 2024-10-17
GB2608078A (en) 2022-12-21
AU2021222010A1 (en) 2022-09-29
AU2021222010B2 (en) 2024-04-04
WO2021168160A1 (en) 2021-08-26
GB2608078B (en) 2024-07-31
GB202213739D0 (en) 2022-11-02
US20210258623A1 (en) 2021-08-19

Similar Documents

Publication Publication Date Title
DE112021001105T5 (de) Remote-videozusammenarbeit in echtzeit
US9049338B2 (en) Interactive video collaboration framework
DE102015100911B4 (de) Verbesserte Kommunikation zwischen entfernten Teilnehmern/Teilnehmerinnen mittels erweiterter und virtueller Realität
US11165840B2 (en) Systems and methods for multiple device control and content curation
JP6138962B2 (ja) 写真の変換提案
CN1694528B (zh) 实时音频-视频通信和数据协作的系统和方法
US20150181265A1 (en) Network synchronized camera settings
DE102017218559A1 (de) Aufzeichnen digitaler umfassender erfahrungen mit hoher wiedergabetreue durch berechnungen ausserhalb einer vorrichtung
US10887633B1 (en) Real time remote video collaboration
DE102013003409B4 (de) Techniken zum intelligenten Ausgeben von Medien auf mehreren Vorrichtungen
US10574892B2 (en) Depth camera based image stabilization
US20210311910A1 (en) Media production system and method
US20120281970A1 (en) Medical video production and distribution system
CN111246150A (zh) 视频会议的控制方法、系统、服务器和可读存储介质
DE102022121067A1 (de) Screen, video-, audio- und textfreigabe in mehrparteien-video-konferenzen
US6570585B1 (en) Systems and methods for preparing and transmitting digital motion video
US10182204B1 (en) Generating images of video chat sessions
EP3437321B1 (de) Telekonferenzübertragung
US12081899B2 (en) Immersive scenes
McNaughton Video Film Recording: A New Production Paradigm For 1960s BBC Drama
US11973813B2 (en) Systems and methods for multiple device control and content curation
US20240348842A1 (en) Real time streaming in collaborative workspace environment
US20240364840A1 (en) Immersive scenes

Legal Events

Date Code Title Description
R012 Request for examination validly filed