DE69837887T2

DE69837887T2 - Einteilbare, vernetzte multimediale systeme und anwendungen

Info

Publication number: DE69837887T2
Application number: DE69837887T
Authority: DE
Inventors: Lester Hillsborough LUDWIG; William Blake Los Gatos BROWN; Inn J. Cupertino YUL; Anh T. Sunnyvale VUONG; Richard W. San Francisco VANDERLIPPE; Gerald Atherton BURNETT; Chris Menlo Park LAUWERS; Richard Union City LUI; Daniel Incline Village APPLEBAUM
Original assignee: Collaboration Properties Inc
Current assignee: PRAGMATUS AV LLC,, ALEXANDRIA, VA., US
Priority date: 1997-11-04
Filing date: 1998-11-04
Publication date: 2008-02-14
Anticipated expiration: 2018-11-05
Also published as: WO1999023560A1; DE69837887D1; ATE364203T1; EP1029273A4; EP1029273B1; AU1451599A; CA2308147C; CA2308147A1; EP1029273A1; ATE419580T1; DE69840427D1

Description

1. HINTERGRUND DER ERFINDUNG
1.1 Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich allgemein auf ein skalierbares vernetztes Multimedia-System und insbesondere auf ein skalierbares Audio-Video-Server-System und auf eine Anwendungsprogrammschnittstelle (API) zusammen mit einer Palette zugeordneter Softwareanwendungen, die zusammen hochwertige Audio-Video- und Multimedia-Verarbeitungsfähigkeiten bereitstellen.
1.2 Hintergrund
In den letzten Jahren ist beträchtliche Anstrengung auf die Entwicklung von Hardware und Software für netzgestütztes Audio-Video (A/V) und allgemeiner auf vernetzte Multimedia-Systeme gerichtet worden. Diese Entwicklung wird durch einen Technologieschub von Geräteherstellern sowie durch das kommerziellen Potential von Unterhaltungsanwendungen wie etwa einem Videoabrufdienst und Mehrspieler-Spielen sowie von Geschäftsanwendungen wie etwa Videomitteilungsübermittlung und Multimedia-Konferenzzusammenarbeit vorangetrieben.
Ein entscheidender Faktor, der die Nützlichkeit und den Wert eines netzgestützten Multimedia-Systems beeinflusst, ist die Art und Weise, in der Computerbetriebsmittel organisiert sind, um ein Videodatei-Speicherungs-/Codierungs-/Decodierungs-/Verteilungs-System, im Folgenden als ein Audio-Video-Speichersystem (AVSS) bezeichnet, zu definieren. Hinsichtlich der Definition eines auf Geschäftsanwendungen anwendbaren Audio-Video-Speichersystems gibt es mehrere Schlüsselanforderungen. Mit besonderer Betonung der Entwicklung in einer Geschäftsumgebung, die eine Multimedia-Konferenzzusammenarbeit unterstützt und durch Standortnetze (d. h. lokale Netze) und Weitverkehrsnetze charakterisiert ist, enthalten diese Anforderungen die Folgenden:

1) universelle Standortskalierbarkeit;
2) universelle Weitverkehrsskalierbarkeit;
3) beschränkter Einfluss auf die Netzbelastung;
4) niedrige Implementierungs- und Betriebskosten;
5) Anpassung an mehrere Desktop-Plattformen (modern, vorhanden und veraltet);
6) Anpassung an mehrere Kompressionsstandards;
7) Unterstützung für einen weiten Bereich hochwertiger videofähiger Hochleistungsanwendungen;
8) kostengünstige Fähigkeit zum Aktualisieren über aufeinander folgende Technologie- und Standardgenerationen; und
9) API-Erweiterbarkeit.

Eine Zusammenarbeits-Multimedia-Umgebung, die ein Videospeichersystem nutzt, enthält notwendig mehrere Desktop-Workstations, Codierungs- und Decodierungsbetriebsmittel, Videodatei-Speicherbetriebsmittel und ein Standort-Videoverteilungsnetz. Zwei Architekturentwurfsfaktoren beeinflussen stark den Umfang, in dem die oben erwähnten Schlüsselanforderungen gleichzeitig erfüllt werden können, d. h., 1) die Organisation der Codierungs-/Decodierungs-Betriebsmittel und der Videodatei-Speicherbetriebsmittel in Bezug auf die Desktop-Workstations und das Videoverteilungsnetz und 2) das Wesen des Videoverteilungsnetzes selbst.
Codierungs- und Decodierungsbetriebsmittel sowie Videodatei-Speicherbetriebsmittel können auf einer Desktop-Grundlage oder auf einer Netzgrundlage (d. h. auf einer Mehrfachnutzungsgrundlage) zugeordnet werden. 1 veranschaulicht eine beispielhafte Erlang-Betriebsmittel-Mehrfachnutzungsbeziehung 2, die die Computerbetriebsmittel-Nutzungseffizienz 1 in Bezug auf die Anzahl der Anwender zeigt, die das Betriebsmittel 6 unter festen Blockierungsbedingungen gemeinsam nutzen. Wie in 1 angegeben ist, führt die netzgestützte Betriebsmittelzuordnung 3, 4 zu viel höherer Betriebsmittelnutzungseffizienz als dem Desktop zugeordnete Betriebsmittel, die vollständig jeweils einem Anwender zugeordnet sind (5). Dies führt wiederum dazu, dass Videospeichersysteme, die durch eine desktopgestützte Betriebsmittelzuordnung charakterisiert sind, Technologieinvestitionen insbesondere in Situationen, die eine erhebliche Anzahl von Workstation-Anwendern 3 und/oder verhältnismäßig niedrige Nutzungsraten (< 20 % des Arbeitstags) durch die Anwender umfassen, wesentlich ineffizienter als Systeme einsetzen, die die Betriebsmittelmehrfachnutzung nutzen. Außerdem führt die desktopgestützte Betriebsmittelzuordnung unerwünscht zu höheren Systemaufrüstungskosten.
Ein Videoverteilungsnetz kann auf der Analogtechnologie, auf der Digitaltechnologie oder auf ihrer Kombination beruhen. 2 ist eine graphische Darstellung, die die relativen Kosten 2.1 der lokalen Analog- und Digital-Videosignal-Verteilungstechnologie als Funktion der Videoqualität 2.2 zeigt und somit eine Kurve 2.3 der analogen Kosten gegenüber der Leistung/Qualität und eine Kurve 2.4 der digitalen Kosten gegenüber der Leistung/Qualität enthält. Über ein erstes Gebiet 2.5 niedrigerer Leistung und niedrigerer Qualität in 2, das Leistung und Qualität bereitstellen könnte, die z. B. für Technologieexperimente geeignet ist, ist die Digitalsignal-Verteilungstechnologie wesentlich teurer als ihr analoges Gegenstück. Der Anstieg der Kurve 2.4 der digitalen Kosten gegenüber der Leistung/Qualität über dieses gesamte erste Gebiet 2.5 ist nahezu konstant, während der für die analogen Kosten gegenüber der Leistung/Qualität 2.3 mit zunehmender Leistung und Bildqualität 2.2 allmählich ansteigt. Ein zweites in 2 gezeigtes Gebiet 2.6 überspannt ein praktisches Betriebsgebiet 2.7 in Bezug auf Geschäfts-Leistungs- und Geschäfts-Qualitätsniveaus, die hier Video entsprechen, das mit 30 Teilbildern pro Sekunde mit einer Auflösung im Bereich von näherungsweise 320 × 240 bis 640 × 480 Pixel oder mit einer anderen Standardauflösung geliefert wird. Die Kurve 2.3 der analogen Kosten gegenüber der Leistung/Qualität beginnt über das zweite Gebiet 2.6 schnell zuzunehmen, während sich die Leistung und die Qualität 2.2 verbessern, wobei sie schließlich die Kurve 2.4 der digitalen Kosten gegenüber der Leistung/Qualität treffen und übersteigen. Allerdings bleibt über den größten Teil des oben erwähnten praktischen Betriebsgebiets 2.7 die analoge Signalverteilungstechnologie wesentlich preiswerter als ihr digitales Gegenstück. Somit ist die analoge Signalverteilungstechnologie für die meisten Geschäftsumgebungs-leistungsanforderungen und -qualitätsanforderungen kostengünstiger als die digitale Signalverteilungstechnologie. Die leicht verfügbare digitale Netztech nologie besitzt keine ausreichende Bandbreite, um Echtzeit- oder nahezu Echtzeitvideo in Geschäftsqualität zu einer großen Anzahl von Anwendern zu liefern. Schließlich überspannt ein drittes Gebiet 2.8 in 2 High-End- oder Spezialsituations-Leistungsniveaus und -Qualitätsniveaus 2.2. Innerhalb des dritten Bereichs 2.8 beginnen die Kosten der digitalen Signalverteilungstechnologie schnell, sprunghaft in die Höhe zu gehen.
Außerdem gibt 2 die Art und Weise an, in der zu erwarten ist, dass sich die analogen und die digitalen Kurven 2.3, 2.4 der Kosten gegenüber der Leistung/Qualität mit der Zeit entwickeln. Während sich die Technologie entwickelt, nehmen die Gesamtkosten 2.1 für jeden Technologietyp in Bezug auf ein gegebenes Leistungs- und Qualitätsniveau 2.2 ab. Allerdings ist zu erwarten, dass die in 2 gezeigte allgemeine Form der Kurven 2.3, 2.4 im Wesentlichen dieselbe bleibt. Darüber hinaus wird sich die digitale Signalverteilungstechnologie in naher Zukunft mit einem viel schnelleren Schrittmaß als die analoge Verteilungstechnologie entwickeln, was wegen der Systemaufrüstungshäufigkeit höhere Kosten 2.1 über die Lebensdauer eines Systems bedeutet. Somit sind Videospeichersysteme, die sich auf die rein digitale Videoverteilungstechnologie stützen, wesentlich weniger kostengünstig als jene, die die analoge Verteilungstechnologie nutzen.
Bekannte standortgestützte vernetzte Videospeichersysteme erfüllen die oben erwähnten Schlüsselanforderungen nicht annähernd. Zum großen Teil ergibt sich das aus den Entwurfsansätzen, die in Bezug auf die oben erwähnten Architekturbetrachtungen insbesondere dann gewählt werden, wenn die Grundpfeiler der Architektur eher durch bestehende Technologievertriebstrends vorwärts getrieben werden als dass sie so entworfen werden, dass sie die tatsächlichen Geschäftsanforderungen erfüllen. Es besteht ein Bedarf an einem Videospeichersystem, das die gemeinsame Betriebsmittelnutzung und den vollständig entwickelbaren Bereich vernetzter Signalverteilungstechnologie nutzt, um die oben beschriebenen Schlüsselkosten- und Anwendungsqualitätsanforderungen zu erfüllen.
2. ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung ist ein vernetztes Multimedia-System, das mehrere Workstations und wenigstens einen Speicherserver umfasst. Wenigstens ein Signalweg verbindet die Workstations und den Speicherserver miteinander. Jede Workstation enthält Video- und Audio-Wiedergabe- sowie Video- und Audioerfassungsfähigkeiten. Irgendein gegebener Speicherserver umfasst eine Menge von Speicherzellen, die unter der Anweisung eines Speicherzellenmanagers arbeiten. Eine Speicherzelle kann einen oder mehrere Codierungs- und/oder Transcodierungskonverter enthalten, die so konfiguriert sind, dass sie Audio- und Videosignale, die von einer Workstation ausgehen, in eine für die digitale Speicherung geeignete Form konvertieren oder transformieren. Ferner kann eine Speicherzelle einen oder mehrere Decodierungskonverter enthalten, die so konfiguriert sind, dass sie digital gespeicherte Signale in eine für die Audio- und Videosignal-Wiedergabe bei einer Workstation geeignete Form konvertieren. Außerdem enthält jede Speicherzelle wenigstens eine Speichervorrichtung und eine Speichervorrichtungssteuerung, die durch einen oder mehrere Konverter erzeugte Signale zum späteren Abrufen speichern können.
Der Speicherzellenmanager reagiert auf von den Workstations empfangene Signale und überwacht den Betrieb der Speicherzellen, um die Speicherung konvertierter Audio- und Videosignale in wenigstens einer Datei zu erleichtern, auf die durch eines oder mehrere Anwendungsprogramme, die in einer oder mehreren Workstations ausgeführt werden, gleichzeitig zugegriffen werden kann. In einer Ausführungsform leitet der Speicherzellenmanager die Speicherung konvertierter Signale dadurch, dass er eine Speicherzelle auswählt und ermittelt, ob ein darin enthaltener Konverter verfügbare Bandbreite oder Kapazität besitzt. Wenn das der Fall ist, wählt der Speicherzellenmanager eine Speichervorrichtungssteuerung in der gewählten Speicherzelle aus und ermittelt, ob die Steuerung verfügbare Bandbreite oder Kapazität besitzt. Wenn das der Fall ist, ermittelt der Speicherzellenmanager, ob eine der Steuerung zugeordnete Speichervorrichtung verfügbare Bandbreite oder Kapazität besitzt, wobei der Speicherzellenmanager in diesem Fall den Konverter und die gewählte Speichervorrichtungssteuerung anweist, die Signale zu konvertieren und die konvertierten Signale in der gewählten Speichervorrichtung zu speichern. Wenn diese Bandbreite oder Kapazität für den Konverter, die Speichervorrichtungssteuerung oder die Speichervorrichtung nicht zur Verfügung steht, wählt der Speicherzellenmanager andere solche Vorrichtungen in der gewählten Speicherzelle zur Betrachtung in Bezug auf die Bandbreiten- oder Kapazitätsverfügbarkeit aus. Wenn die gewählte Speicherzelle eine Bandbreiten- oder Kapazitätsgrenze erreicht hat, wählt der Speicherzellenmanager eine weitere Speicherzelle zur Betrachtung aus. Wenn der Speicherzellenmanager oder der Speicherserver selbst eine Bandbreiten- oder Kapazitätsgrenze erreicht hat, fordert der Speicherzellenmanager einen weiteren Speicherzellenmanager an, um die Speicherung der konvertierten Signale zu leiten.
Ferner leitet der Speicherzellenmanager wahlweise das Kopieren oder Übertragen gespeicherter konvertierter Signale zwischen 1) irgendwelchen mehreren Speichervorrichtungen in einer gegebenen Speicherzelle und/oder 2) irgendeiner Menge von Speicherzellen, wobei eine oder mehrere solcher Speicherzellen unter der Steuerung eines anderen Speicherzellenmanagers stehen können. Dieses Kopieren oder Übertragen maximiert die Wahrscheinlichkeit, dass irgendeine gegebene Datei, die konvertierte Signale enthält, für eines oder mehrere Anwendungsprogramme, die in mehreren Workstations ausgeführt werden, gleichzeitig zugänglich ist. Außerdem kann der Speicherzellenmanager die Übertragung gespeicherter konvertierter Signale zu Workstations oder zu anderen Typen mit dem vernetzten Multimedia-System gekoppelter Server leiten.
Außerdem überwacht der Speicherzellenmanager das Abrufen und die Decodierungskonvertierung gespeicherter konvertierter Signale unter der Leitung eines oder mehrerer Anwendungsprogramme, die in einer oder mehreren Workstations ausgeführt werden. Dieser Abruf und diese Decodierungskonvertierung erleichtern die Echtzeit- und/oder Nahezu-Echtzeit-Audio- und -Videosignalwiedergabe in diesen Workstations.
Eine Multimedia-Datei umfasst bei der gemeinsamen Nutzung einen oder mehrere Typen von Dateien und/oder Bezugnahmen auf Dateien, wobei diese Dateien Text-, Graphik-, Bild-, Audio- und/oder Videoinformationen und/oder Befehle oder Ereignisfolgen zum Erzeugen oder Rendern dieser Informationen enthalten können. Außerdem enthält die Multimedia-Datei Zeitkorrelationsdaten, die eine oder mehrere Arten angeben, auf die ihre Bestandteildateien und/oder Bestandteildateibezugnahmen in der Zeit zugeordnet sind. In einer Ausführungsform überwacht der Speicherzellenmanager außer den obigen Operationen die Speicherung dieser Multimedia-Dateien oder Abschnitte von ihnen. Ferner überwacht der Speicherzellenmanager in einer durch die Zeitkorrelationsdaten angegebenen Art das Abrufen von Multimedia-Dateiinhalten und die Verteilung dieser Inhalte auf eine oder mehrere Workstations in Verbindung mit der Audio- und Videosignalwiedergabe in diesen Workstations.
Das System ist so konfiguriert, dass es einen Zeiger erzeugt, der auf eine vorgegebene Datei oder Gruppe von Dateien in einer oder in mehreren der Speicherzellen Bezug nimmt, wenigstens den Zeiger zu einem Empfangsanwendungsprogramm sendet und den Inhalt der Datei oder Gruppe von Dateien durch Abrufen der Daten von der durch den Zeiger identifizierten Datei oder Gruppe in einer Workstation rendert.
Außerdem schafft das System eine Betrachteranwendung zum Aufbauen von Verbindungen und Sitzungen, zum Vorbereiten von Dateien zum Betrachten und zum Bereitstellen der notwendigen Betrachterschnittstelle, um zu ermöglichen, dass ein Anwender je nach Berechtigung auf Dateien in der Workstation zugreift und sie manipuliert.
Ferner besitzt das System in dem Speicherteilsystem und/oder in einer Workstation wenigstens ein gespeichertes Videoanwendungsprogramm, wobei es wenigstens ein Prozessgrundelement über wenigstens zwei der gespeicherten Videoanwendungsprogramme gemeinsam nutzt. Die gespeicherten Videoanwendungsprogramme sind eines oder mehrere aus der Gruppe, die aus Folgenden besteht: Videokonferenzaufzeichnung, Video-Mail, Videoanrufbeantwortersystem, Videodokumente und Video-Publizieren. Ferner ist das System so konfiguriert, dass es wenigstens ein Datengrundelement über wenigstens zwei der mehreren gespeicherten Videoanwendungsprogramme gemeinsam nutzt.
Außerdem kann das System ein Prozessgrundelement und ein Datengrundelement als standardisierte Anhänge zu einer Datei aufrufen. Dieser Anhang ist in einem Format, das in Übereinstimmung mit einem Standarddatenaustauschprotokoll durch Drittanbieter akzeptiert wird.
Außerdem kann das System so konfiguriert sein, dass es unter Verwendung eines synchronisierten Datenmehrfachnutzungsprozesses als ein gemeinsam genutztes Konferenzfenster Echtzeit-Datenmehrfachnutzungssitzungen zwischen wenigstens zwei Workstations aufbaut. Es kann eine Videokonferenzanwendung zum Aufbauen einer Videokonferenzsitzung zwischen den miteinander verbundenen Workstations und zur Verwendung einer Videokonferenz-Aufzeichnungsanwendung zum Aufzeichnen wenigstens eines Abschnitts der aufgebauten Videokonferenzsitzung in wenigstens einem Speicherteilsystem verwenden.
Ferner ist das System so konfiguriert, dass es wenigstens eine Video-Mail-Anwendung schafft, die das Verfassen einer Video-Mail-Nachricht zur Sendung an ein Speicherteilsystem und/oder das Lesen einer Video-Mail-Nachricht, die zuvor in dem Speicherteilsystem gespeichert worden ist, ausführen kann. Üblicherweise nutzt das System eine Speicherzelle, um eine Audio- und/oder eine Videonachricht und/oder eine Multimedia-Nachricht von einem ankommenden Anrufer aufzuzeichnen, dessen Anrufversuch durch den Empfänger nicht beantwortet worden ist oder durch den Empfänger abgelehnt worden ist und der lediglich erfolgte, um eine Nachricht zu hinterlassen, ohne sich mit dem Empfänger zu verbinden. Videodateien, die in einer Speicherzelle gespeichert sind, können in einem elektronischen Online-Dokument enthalten sein.
Ferner kann das System eine Shareboard- oder andere Fenster-Mehrfachnutzungssitzung, entweder statisch oder mit Video- oder Audioinformationen synchronisiert, enthalten, um eine Multimedia-Implementierung der Videokonferenz-Aufzeichnung und/oder der Video-Mail und/oder des Videoanrufbeantwortersystems und/oder der Videodokumente und/oder des Video-Publizierens zu ermöglichen.
Darüber hinaus kann das System ein Videoeditierprogramm enthalten. Das Videoeditierprogramm kann entweder als ein integraler Bestandteil wenigstens einer der Anwendungen oder durch Aufnahme eines Drittanbieter-Videoeditors implementiert sein.
Das System kann Video-Mail-Anwendungen entweder unter Verwendung herkömmlicher Drittanbieter-E-Mail-Systeme oder von E-Mail-Systemen, die verbessert worden sind, um die Fähigkeit zu bieten, Ereignisse aus dem E-Mail-System zu erhalten und/oder abzulegen/zu kopieren, unterstützen.
Das System kann Videodokumentanwendungen entweder unter Verwendung herkömmlicher Drittanbieterdokumentsysteme oder von Dokumentsystemen, die verbessert worden sind, um die Fähigkeit zu bieten, Ereignissen aus dem Dokumentsystem zu erhalten und/oder abzulegen/zu kopieren, unterstützen.
Außerdem kann das System zum Verringern der Gesamtzahl von Kopien von Videodateien in dem Unternehmen durch gemeinsame Dateinutzung oder durch Verringern der Unternehmensnetzlast durch den Transport von Videodateien über ein getrenntes Audio-Video-Netz oder durch das Transcodieren zwischen mehreren Audio-Video-Dateien als ein Internet-Proxy-Server arbeiten und/oder ermöglichen, dass irgendeine Audio-Video-Workstation in dem Unternehmen als ein Video-Verleger für das Unternehmen dient. Schließlich ermöglicht das als ein Internet-Proxy-Server arbeitende System die Implementierung wenigstens einer animierten Anmerkung im Internet.
3. KURZBESCHREIBUNG DER ZEICHNUNG
Für ein umfassenderes Verständnis der Prinzipien der vorliegenden Erfindung wird nun auf die mehreren Figuren der Zeichnung Bezug genommen. In der Zeichnung ist:
1 ein beispielhaftes Erlang-Diagramm, das die Computerbetriebsmittel-Nutzungseffizienz in Bezug auf die Anzahl der Anwender zeigt, die das Betriebsmittel unter festen Blockierungsbedingungen gemeinsam nutzen.
2 eine graphische Darstellung ist, die die relativen Kosten der analogen und der digitalen Verteilungstechnologie als eine Funktion der Leistung und der Bildqualität zeigt.
3 ein Blockschaltplan einer Zusammenarbeits-Multimedia-Computerumgebung (CMCE), die ein Audio/Video-Serversystem (AVSS) nutzt, das in Übereinstimmung mit der vorliegenden Erfindung konstruiert ist.
4 ein Blockschaltplan einer alternativen Ausführungsform einer CMCE, die in Übereinstimmung mit der vorliegenden Erfindung konstruiert ist.
5 ein Blockschaltplan einer Audio/Video-Speicherzelle (AVSC), die in Übereinstimmung mit der vorliegenden Erfindung konstruiert ist.
6 ein Blockschaltplan einer ersten Ausführungsform einer gemeinsam genutzten Codierungseinheit der vorliegenden Erfindung.
7 ein Blockschaltplan einer zweiten Ausführungsform der gemeinsam genutzten Codierungseinheit.
8 ein Blockschaltplan einer dritten Ausführungsform der gemeinsam genutzten Codierungseinheit.
9 ein Blockschaltplan eines Audio/Video-Servermanagers (AVSM), der in Übereinstimmung mit der vorliegenden Erfindung konstruiert ist.
10 ein Blockschaltplan, der eine Client-Server-Sitzungskommunikation in einer Ausführungsform der vorliegenden Erfindung veranschaulicht.
11 ein Blockdiagramm, das eine beispielhafte graphische Anwenderschnittstelle (GUI) einer Aufzeichnungssteuerung zeigt.
12 ein Blockdiagramm, das eine beispielhafte Wiedergabesteuerungs-GUI zeigt.
13 ein Blockdiagramm, das eine beispielhafte Browsing-Steuerungs-GUI zeigt.
14 ein Blockschaltplan einer beispielhaften vernetzten AVSS-Organisation.
15 eine Darstellung einer Kommunikationsklassenhierarchie in der vorliegenden Erfindung.
16 eine Darstellung einer AVSM-Klassen-Beziehung in der vorliegenden Erfindung.
17 eine Darstellung einer AVSC-Klassen-Beziehung in der vorliegenden Erfindung.
18 ein beispielhaftes Anforderungsfolgediagramm, das einer AVSC-Kanalerfassung entspricht.
19 ein beispielhaftes Anforderungsfolgediagramm für eine "Open"-Anforderung.
20 ein beispielhaftes Anforderungsfolgediagramm für eine "Close"-Anforderung.
21 ein beispielhaftes Anforderungsfolgediagramm für eine "Delete"-Anforderung.
22 ein beispielhaftes Anforderungsfolgediagramm für eine "Record"-Anforderung.
23 ein beispielhaftes Anforderungsfolgediagramm, das einer Anforderung für eine Dateiübertragung von einem Nicht-Standort-AVSS entspricht.
24 ein beispielhaftes Anforderungsfolgediagramm, das Dateireplikationsoperationen entspricht.
25 ein beispielhaftes Anforderungsfolgediagramm, das bestimmten AVSS-Organisationsoperationen entspricht.
26 ein Blockschaltplan, der Clientanwendungsprogramme zeigt, die mit dem AVSM und mit dem A/V-Netz-Manager kommunizieren.
27 eine Übersicht der Dateihierarchie.
28 ein beispielhaftes Datengrundelement.
29 ein beispielhaftes Datengrundelement, das als ein Anhang implementiert ist.
30 ein beispielhaftes System zur Implementierung der Softwareanwendungen der vorliegenden Erfindung.
31 ein Transaktionsablaufplan zwischen den Anwendungselementen, die lokale Video-Mail ermöglichen.
32 ein Transaktionsablaufplan zwischen den Anwendungselementen, die Weitverkehrs-Video-Mail ermöglichen.
33 eine Darstellung des Lebenszyklus einer beispielhaften Videonachrichtendatei.
34 ein Vergleichsdiagramm des Eigentums und der Lesbarkeit von Videodateien, die einem Video-Mail-Anhang zugeordnet sind, über die Nachrichtenlebensdauer.
35 eine Übersicht über eine Ausführungsform des Videoanrufbeantwortersystems der vorliegenden Erfindung.
36 ein Datenablaufplan, der den Betrieb einer Ausführungsform der vorliegenden Erfindung genau beschreibt.
37 eine Übersicht über die Videokonferenz-Aufzeichnungsanwendung der vorliegenden Erfindung.
38 eine Übersicht über mehrere der Komponenten der vorliegenden Erfindung, die zur Implementierung der Videokonferenzaufzeichnung erforderlich sind.
39 ein Signalzustandsdiagramm einer Zwei-Teilnehmer-Videokonferenz.
40 ein Signalzustandsdiagramm einer Videokonferenz, die einen Drittanbieter enthält oder eine Konferenzaufzeichnung implementiert.
41 ein Signalzustandsdiagramm der Initiierung der Konferenzaufzeichnung.
42 ein Signalzustandsdiagramm einer ersten Videokonferenzdarstellung.
43 ein Signalzustandsdiagramm einer zweiten Videokonferenzdarstellung.
44 ein Signalzustandsdiagramm einer dritten Videokonferenzdarstellung.
45 ein Datenablaufplan einer Softwareimplementierung der Videokonferenzanwendung der vorliegenden Erfindung.
46 ein Signalzustandsdiagramm der Initiierung einer Videokonferenzwiedergabe.
4. AUSFÜHRLICHE BESCHREIBUNG
4.1 Architektursystem
Die vorliegende Erfindung umfasst wenigstens ein gemeinsam genutztes zentralisiertes Audio-Video-(A/V-)Datei-Speichersystem und Audio-Video-(A/V-)Datei-Verarbeitungssystem in einer Zusammenarbeits-Multimedia-Computerumgebung oder vernetzten Multimedia-Computerumgebung. Diese Zusammenarbeits-Multimedia-Computerumgebung oder vernetzte Multimedia-Computerumgebung umfasst hier mehrere Anwender-Workstations zuzüglich Multimedia-fähiger Server, die über eines oder mehrere Netze miteinander verbunden sind. Ferner umfasst die vorliegende Erfindung workstationgestützte Anwendungsprogramme zuzüglich auf den Servern ausgeführter Steuersoftware, die den Austausch von A/V- und/oder Multimedia-Informationen zwischen den Workstations und Servern in Echtzeit, nahezu in Echtzeit und/oder nicht in Echtzeit ermöglichen. Das A/V-Datei-Speichersystem und A/V-Datei-Verarbeitungssystem stellt einen weiten Bereich von Videospeicher- und Videowiedergabediensten für Workstationanwendungsprogramme und/oder für andere Server einschließlich mehrerer der Operationen der Analog-Digital-Codierung, der Digital-Analog-Decodierung, der Transcodierung einer Digitaldateispeicherung, der Multimedia-Dateiaufzeichnung, der digitalen Formattranscodierung des analogen Streaming der Multimedia-Datei-Wiedergabe, des digitalen Datei-Streaming, der digitalen Dateiübertragung und der Dateiorganisationsoperationen bereit, die die Aufzeichnung/Codierung, die Speicherung, die Verteilung, die Decodierung, die Wiedergabe, das Kopieren, die Archivierung und das Löschen von A/V- und/oder Multimedia-Dateien ermöglichen.
3 ist ein Blockschaltplan einer Zusammenarbeits-Multimedia-Computerumgebung (CMCE) 10, die ein Audio/Video-Serversystem (AVSS) 100 nutzt, das in Übereinstimmung mit der vorliegenden Erfindung konstruiert ist. Die CMCE 10 umfasst ein Datennetz 20, ein A/V-Netz 30, mehrere Anwender-Workstations 40 und/oder eine Menge von A/V-Konferenz-Räumen 45, ein Audio/Video-Serversystem (AVSS) 100 und eine Menge von Unterstützungsserversystemen, die ein E-Mail-System 50, ein Intranet-Serversystem 60 und ein Firewall/Internet-Gateway-System 70 enthalten. Das Datennetz 20 koppelt das A/V-Netz 30, die Workstations 40, den A/V-Konferenzraum bzw. die A/V-Konferenz-Räume 45, jedes Unterstützungsserversystem 50, 60, 70 und das AVSS 100. Außerdem unterhält das Datennetz 20 eine Weitverkehrsübertragungsstrecke, die mit einem Weitverkehrsnetz-Gateway (WAN-Gateway) 25 gekoppelt ist, das mit einem ersten WAN 29 gekoppelt ist. Das A/V-Netz 30 koppelt die Workstations 40, die A/V-Konferenz-Räume 45 und das AVSS 100. Das A/V-Netz 30 unterhält wenigstens eine Verbindungsleitungskopplung 16 zu einem entfernten und/oder zu einem weiteren lokalen AV-Netz 30. Außerdem enthält das A/V-Netz 30 eine Verbindungsleitungskopplung 16 zu einem Codierer/Decodierer-Gateway (Codec-Gateway) 38, das mit einem zweiten WAN 39 gekoppelt ist.
4.2 Signalverteilungsnetze
Die vorliegende Erfindung unterstützt sowohl den Echtzeit- oder Nahezu-Echtzeit-Signalaustausch oder die Echtzeit- oder Nahezu-Echtzeit-Signalverteilung als auch den verzögerten A/V-Signal-Austausch oder die verzögerte A/V-Signal-Verteilung auf einer lokalen und/oder entfernten Grundlage. Im Kontext der Echtzeit-A/V-Signal-Verteilung über momentan verfügbare Vernetzungstechnologien schafft die analoge Standortvernetzung für die vorhersehbare Zukunft höhere Videoqualität und -echtzeitleistung bei niedrigeren Kosten als die digitale Standortvernetzung. In der in 3 gezeigten Ausführungsform stützt sich die CMCE 10 auf das Datennetz 20, um den Austausch digitaler Informationen zwischen CMCE-Elementen zu ermöglichen, und auf das A/V-Netz 30, um den Austausch analoger Signale zu ermöglichen. Somit schafft das in 3 gezeigte analoge Standortsignalverteilungsnetz eine preiswerte CMCE-Implementierung, die in Echtzeit hochwertige A/V-Signale (d. h. Video mit 640 × 480 Pixel in NTSC-Fernsehqualität oder mit einer ähnlichen Fernsehnormauflösung, zuzüglich 7-15 kHz Hi-Fi-Audio) liefern kann. Außerdem stellt diese Ausführungsform sicher, dass die Echtzeit-A/V-Signal-Verteilung im Wesentlichen keine Auswirkungen auf die Belastung des lokalen Datennetzes hat. Wie im Folgenden ausführlich beschrieben wird, könnten sich alternative CMCE-Ausführungsformen auf ein einzelnes physikalisches Netz stützen, das irgendeines einer Vielzahl geeigneter analoger und/oder digitaler Multiplexierungsschemata nutzt; wie durch die Zeitentwicklung der Kurven in 2 nahegelegt wird, werden diese mit der Zeit zunehmend wichtig.
In 3 schafft das Datennetz 20 sowohl eine digitale lokale Vernetzung als auch eine digitale Weitverkehrsvernetzung, während das A/V-Netz 30 sowohl eine analoge lokale Vernetzung als auch eine analoge Weitverkehrsvernetzung schafft. Hinsichtlich der lokalen analogen Vernetzung dient eine einzelne Instanz des A/V-Netzes 30 üblicherweise direkt einem AVSS 100 zuzüglich einer zugeordneten Gruppe von Workstations 40 und/oder A/V-Konferenz-Räumen 45, die sich an einem einzigen Standort befinden. Somit werden ein A/V-Netz 30, sein entsprechendes AVSS 100 und die Workstations 40 und die A/V-Konferenz-Räume 45 hier als eine Standortgruppe bezeichnet. Mehrere nahe Standortgruppen können zwischen den entsprechenden Daten- und A/V-Netzen 20, 30 lokal über Verbindungsleitungen verbunden sein, um einen gemeinsamen Campus zu bilden. Ein Beispiel hierfür ist ein großes Bürogebäude, bei dem verschiedene Bereiche oder Gebäudestockwerke durch verschiedene Standortgruppen bedient werden. Ein weiteres Beispiel umfasst Situationen, in denen eine Unternehmenssitzeinrichtung mehrere allgemein nahe Gebäude enthält, wobei in jedem Gebäude eine oder mehrere Standortgruppen eingesetzt sein können. Jede der Standortgruppen in diesen Gebäuden könnte dann in einer der allgemein akzeptierten Verwendung des Begriffs "Campus" in Unternehmensumgebungen entsprechenden Weise weiter gekoppelt sein, um einen üblichen Campus zu bilden. Die Struktur und die Funktionalität der Daten- und A/V-Netze 20, 30 und die Arten, in denen sie die Standort-, Campus- und Weitverkehrsvernetzung oder entfernte Vernetzung unterstützen, werden im Folgenden ausführlich beschrieben.
4.2.1 Datennetz
Das Datennetz 20 umfasst einen herkömmlichen Netzknoten zuzüglich Datenübertragungsstrecken 12, die ein Ethernet, einen asynchronen Übertragungsmodus (ATM) oder einen anderen Netztyp, das/der den Austausch von Daten und Steuersignalen zwischen den Elementen ermöglicht, mit denen es/er entweder lokal oder über die Weitverkehrsübertragungsstrecke gekoppelt ist, implementieren. Im Kontext der vorliegenden Erfindung ist das Datennetz 20 ein lokales Netz (LAN), das einen Umfang überspannt, der von annähernd wenigen zehn Metern bis vielleicht einem Kilometer reicht. Die Datenübertragungsstrecken 12 können eine Verdrahtung mit einem nicht abgeschirmten verdrillten Aderpaar (UTP-Verdrahtung), die mit der Standardtelephonsystemverdrahtung kompatibel ist, oder im Wesentlichen irgendeinen anderen Typ einer Netzkommunikationskopplung (koax, optisch, drahtloser Funk usw.) umfassen.
Das Datennetz 20 ermöglicht die digitale Kommunikation wenigstens innerhalb einer Standortgruppe, wobei diese Kommunikation die Steuersignalübertragung, die Übertragung digitaler Dateien und/oder das digitale Streaming enthalten kann. Über eine Menge von Datenübertragungsstrecken 12, die lokal mit herkömmlichen Routern, Datenvermittlungsknoten oder einem Netz-Backbone gekoppelt sind, können eines oder mehrere Datennetze 20 in einer für den Fachmann auf dem Gebiet leicht verständlichen Weise leicht mehreren Standortgruppen (d. h. einem gemeinsamen Campus) dienen, die geographischen, Netzbelastungs- und Signalqualitätsbeschränkungen unterliegen. Die Weitverkehrsübertragungsstrecke des Datennetzes ermöglicht die digitale Kommunikation zwischen Standort und Nicht-Campus- oder entfernten CMCE-Elementen. Die Weitverkehrsübertragungsstrecke ist mit dem Gateway und mit dem WAN 25, 29 gekoppelt, die auf herkömmliche Weise implementiert sind, wie es etwa im US-Patent Nr. 5.617.539 beschrieben ist.
4.2.2 A/V-Netz
Das A/V-Netz 30 verteilt unter der Anweisung eines Servers, der auf Anforderungen und Nachrichten reagiert, die von anderen CMCE-Elementen empfangen werden, A/V-Signale. Das A/V-Netz 30 umfasst eine A/V-Vermittlung 32, einen A/V-Netz-Manager 34 und eine Konferenzbrücke 36. Die A/V-Vermittlung 32 ist über analoge Übertragungsstrecken 14 mit der Konferenzbrücke 36, mit den Workstations 40 und mit dem AVSS 100 gekoppelt. Die A/V-Vermittlung 32 unterhält Verbindungsleitungskopplungen 16 zu einem oder zu mehreren Campus-A/V-Netzen und außerdem zu dem Codec-Gateway 38, das die A/V-Vermittlung 32 mit dem zweiten WAN 39 koppelt. Der A/V-Netz-Manager 34 ist über digitale Übertragungsstrecken 12 mit dem Datennetz 20, mit der A/V-Vermittlung 32 und mit der Konferenzbrücke 36 gekoppelt.
Die A/V-Vermittlung 32 umfasst eine kommerziell verfügbare Standardschaltungsanordnung, um wahlweise Analogsignalkopplungen zwischen einem Quellport und einem oder mehreren Ausgangsports herzustellen. Die A/V-Vermittlung 32 kann unter Verwendung analoger CMOS-Vermittlungselemente implementiert sein, die durch Busse verbunden sind, um eine Kreuzschienenvermittlung zu bilden. Solche analogen CMOS-Vermittlungen werden durch einen oder mehrere Mikroprozessoren gesteuert, die über serielle oder Datennetzports Befehle empfangen.
Eine Verbindungsleitung 16 koppelt die A/V-Vermittlung 32 mit weiteren campusgestützten A/V-Vermittlungen 32. Außerdem koppelt eine Verbindungsleitung 16 die A/V-Vermittlung 32 mit dem Codec-Gateway 38. In einer Ausführungsform ist das Codec-Gateway 38 herkömmlich. Weitere Ausführungsformen können physikalisch getrennte Vermittlungsmultiplexer und/oder Zugriffsmultiplexer umfassen. Das Codec-Gateway 38 könnte z. B. unter Verwendung eines Zydacron-Codecs (Zydacron, Inc., Manchester, NH) oder eines Tandberg-Codecs (Tandberg, Lysaker, Norwegen und Herndon, VA) implementiert sein. Das Codec-Gateway 38 ist mit dem zweiten WAN 39 gekoppelt und ermöglicht dadurch eine Weitverkehrs-A/V-Vernetzung. Im Allgemeinen umfasst das zweite WAN 39 ein herkömmliches Netz, das ein garantiertes Dienstqualitätsniveau und eine Datenübertragung mit niedriger Latenzzeit sicherstellen kann, wie etwa T1, DS3, ISDN, ein öffentliches Fernsprechwählnetz oder ein anderes Netz. Der Fachmann auf dem Gebiet versteht, dass das für die Weitverkehrs-A/V-Vernetzung genutzte WAN 39 dasselbe wie das, das für die Weitverkehrsdatenvernetzung verwendet wird (d. h. ein einzelnes herkömmliches ISDN-, T-Träger-, ATM- oder Frame-Relay-Telekommunikations-WAN), sein kann, wobei die A/V- und die Datensignale auf Standardart in Übereinstimmung mit Prioritäts- und Dienstqualitätsbetrachtun gen multiplexiert werden. Das heißt, die vorliegende Erfindung könnte eher durch ein einzelnes WAN als durch getrennte WANs 29, 39 bedient werden.
Die Konferenzbrücke 36 umfasst eine herkömmliche Audiomisch- und Videomosaikschaltungsanordnung. Die Konferenzbrücke 36 versorgt wahlweise A/V- und/oder Multimedia-Konferenzteilnehmer mit einem oder mit mehreren Konferenz-Videobildern sowie Konferenz-Audioströmen. In einer Ausführungsform umfassen die Konferenz-Videobilder Mosaikteilmengen von Videobildern, die durch Konferenzteilnehmer erzeugt worden sind, sowie ein Videomosaik jedes allen Konferenzteilnehmern zugeordneten Videobilds. Ähnlich umfassen die Konferenz-Audioströme Teilmengen durch Konferenzteilnehmer erzeugter Audiosignale zuzüglich eines Audiostroms, der allen Konferenzteilnehmern entspricht.
Der A/V-Netz-Manager 34 umfasst einen Server zuzüglich zugehöriger Software, die in Reaktion auf über das Datennetz 20 empfangene Anforderungen den Betrieb der A/V-Vermittlung 32 und der Konferenzbrücke 36 koordiniert oder managt. Der A/V-Netz-Manager 34 stellt eine Anwendungsprogrammschnittstelle (API) bereit, über die Clientanwendungsprogramme A/V- und/oder Multimedia-Vermittlungs- und/oder Konferenzdienste anfordern können. Somit leitet der A/V-Manager 34 die A/V-Vermittlung 32 beim Aufbau von A/V- und/oder Multimedia-Sitzungen und/oder Konferenzsitzungen zwischen Workstations 40, A/V-Konferenz-Räumen 45, dem AVSS 100 und/oder der Verbindungsleitung 16.
In einer Ausführungsform umfasst der A/V-Netz-Manager ein Zusammenarbeits-A/V- und/oder Zusammenarbeits-Multimedia-Konferenzsystem, das in der im US-Patent Nr. 5.617.539 mit dem Titel "Multimedia Collaboration System with Separate Data Network and A/V Network Controlled by Information Transmitting an the Data Network" beschriebenen Weise implementiert ist.
4.2.3 Multimedia-Netz
Das Datennetz 20 und das A/V-Netz 30 umfassen zusammengenommen ein lokales Multimedia-Netz (MLAN). Die Weitverkehrsvernetzung wird durch das Weitverkehrs-Übertragungsstrecken-Gateway und durch das WAN 25, 29 des Datennetzes zuzüglich der Verbindungsleitungskopplung 16 des A/V-Netzes mit dem Codec-Gateway und mit dem WAN 38, 39 ermöglicht. Die MLAN-WANs 29, 39 der vorliegenden Erfindung können in der im US-Patent Nr. 5.617.539 beschriebenen Weise implementiert sein. Eine Sammlung von durch das WAN 29, 39 gekoppelten MLANs ermöglicht den Austausch von A/V- und/oder Multimedia-Informationen zwischen Standort-, Campus- und/oder entfernten CMCE-Elementen.
4.2.4 Alternative Signalverteilungsarchitektur
Wie zuvor angegeben wurde, könnte sich die vorliegende Erfindung für die Verteilung sowohl von Daten- als auch von A/V-Signalen auf ein einzelnes Netz stützen. 4 ist ein Blockschaltplan einer alternativen Ausführungsform einer CMCE 11, die in Übereinstimmung mit der vorliegenden Erfindung konstruiert ist. Hinsichtlich 3 sind in 4 zur Bezeichnung gleicher Elemente gleiche Bezugszeichen verwendet. In der alternativen Ausführungsform umfasst die CMCE 11 ein Datennetz 20, einen A/V-Konferenz-Manager 34, der mit einer Konferenzbrücke 36 gekoppelt ist, eine Menge von Workstations 40 und möglicherweise einen oder mehrere A/V-Konferenz-Räume 45, eine Menge von Unterstützungsserversystemen 50, 60, 70 und ein AVSS 100. Das Datennetz 20 koppelt den A/V-Konferenz-Manager 34, die Konferenzbrücke 36, die Workstations 40 und den A/V-Konferenzraum bzw. die A/V-Konferenz-Räume 45, die jeweils das Serversystem 50, 60, 70 und das AVSS 100 unterstützen.
In der Einzelnetz-CMCE 11 ist das Datennetz 20 üblicherweise als ein IP- oder ATM-Netz implementiert. Der A/V-Datei-Austausch zwischen CMCE-Elementen wie etwa dem AVSS 100 und den Workstations 40 oder den A/V-Konferenz-Räumen 45 würde über Streaming oder Dateiübertragung stattfinden, wobei jede Workstation 40 Komprimierungs/Dekomprimierungs-Betriebsmittel enthalten kann.
4.3 Workstations und A/V-Konferenz-Räume
Die Anwender treten mit den CMCE-Elementen einschließlich des AVSS 100 über Anwendungsprogramme in Wechselwirkung, die in Workstations 40 ausgeführt werden. Jede Workstation 40 umfasst ein herkömmliches Desktopgestütztes Computersystem mit einer Verarbeitungseinheit, einem Speicher, einem Plattenlaufwerk, einer Anzeigevorrichtung, einer Tastatur, einer Maus und einem oder mehreren Lautsprechern. Irgendeine bestimmte Workstation 40 kann im Wesentlichen in Übereinstimmung mit irgendeiner Hardware/Software-Plattform wie etwa einem Windows-gestützten (Microsoft Corporation, Redmond, WA) Personal Computer, einem Apple-gestützten (Apple Computer Corporation, Cupertino, CA) Computer, einem Unix-gestützten Computer oder einem anderen Systemtyp implementiert sein. Außerdem ist jede Workstation 40, etwa in der im US-Patent Nr. 5.617.539 beschriebenen Weise, mit einer Videokamera und mit einem Mikrophon ausgestattet. Die Videokamera und das Mikrophon erzeugen ein hochwertiges A/V-Signal, das über eine analoge Leitung 14 zu dem A/V-Netz 30 geführt wird. Auf die gleiche Weise empfängt die Anzeigevorrichtung über die analoge Leitung 14 ein hochwertiges A/V-Signal von dem A/V-Netz 30.
In Ausführungsformen, in denen jede Workstation 40 sowohl mit dem Datennetz 20 als auch mit dem A/V-Netz 30 gekoppelt ist, gibt es eine Vielzahl von Möglichkeiten für die Übertragung von A/V- und/oder Multimedia-Daten zu irgendeiner gegebenen Workstation 40. Insbesondere unterstützt die vorliegende Erfindung die analoge "Echtzeit"-A/V-Datei-Übertragung (d. h. analoges Streaming) zu irgendeiner Workstation über das A/V-Netz 30 sowie sowohl digitales Streaming als auch die Übertragung ganzer digitaler Dateien zu irgendeiner Workstation 40 über das Datennetz 20. Außerdem unterstützt die vorliegende Erfindung die analoge Echtzeit-A/V-Datei-Übertragung entweder gleichzeitig mit digitalem Streaming oder gleichzeitig mit digitaler Dateiübertragung zu irgendeiner Kombination der Workstations 40. Die bestimmten Typen der Dateiübertragung, die zu irgendeinem gegebenen Moment genutzt werden, sind durch die in den Workstations 40 ausgeführten Anwendungsprogramme 40 sowie durch die mit der CMCE 10 gekoppelten Standort- und/oder Nicht-Standort-Anwendungsserver bestimmt.
Außer dem Austausch von A/V-Signalen mit den Workstations 40 kann das A/V-Netz 30 A/V-Signale mit Präsentations-, Konferenz- und/oder Computerbetriebsmitteln austauschen, die sich in einem oder in mehreren A/V-Konferenz-Räumen 45 befinden, wobei diese Betriebsmittel Kameras, Monitore, Fernsehgeräte, Mikrophone und Lautsprecher enthalten können. Dies heißt wiederum, dass ein Gruppentreffen, das in einem A/V-Konferenzraum 45 abgehalten wird, mit einzelnen Workstations 40 oder mit anderen A/V-Konferenz-Räumen 45 auf einer Standort-, Campus- oder entfernten Grundlage A/V- und/oder Multimedia-Informationen austauschen kann.
4.4 Unterstützungsserver
Wie im Folgenden ausführlich beschrieben wird, stellt das AVSS 100 eine neue A/V- und/oder Multimedia-Funktionalität für verschiedene Anwendungsprogramme bereit. Dabei setzt das AVSS 100 selektiv wirksam die Fähigkeiten der Unterstützungsserversysteme 50, 60, 70 ein. Das E-Mail-System 50 umfasst vorzugsweise herkömmliche E-Mail-Server-Hardware und -Software, die E-Mail-Nachrichten mit angehängten Dateien zwischen Anwendern oder Zielbestimmungsorten erzeugen, speichern und verteilen kann. Die Arten, in denen das AVSS 100 mit dem E-Mail-System 50 in Wechselwirkung tritt, um Videoanhänge und andere Multimedia-E-Mail-Fähigkeiten bereitzustellen, werden im Folgenden ausführlich beschrieben.
Viele Gesellschaften oder Unternehmen nutzen ein Intranet-System, das ein privates Netz umfasst, auf dem unternehmensbezogene Informationen in Übereinstimmung mit herkömmlichen Internet-Protokollen verteilt und/oder ausgetauscht werden. Ein Intranet-System setzt wirksam leicht verfügbare preiswerte Internet-Softwarehilfsmittel ein, um für Mitarbeiter- oder Unternehmensmitglieder effizient einen Zugang zu unternehmensweiten Informationen bereitzustellen. Solche unternehmensweiten Informationen können Geschäftskommunikationsdokumente oder -mitteilungen, Ausbildungsmaterialien, Produkt- und/oder Projektinformationen, Personalverzeichnisse und mitglieds- oder mitarbeiterspezifische Daten enthalten, die in einer Unternehmensdatenbank unterhalten werden, wobei der Zugang zu diesen Daten nur für berechtigte Mitglieder gewährt wird. Das Intranet-Serversystem 60 umfasst herkömmliche Hardware und Software, die für Angestellte oder berechtigte Mitglieder in einer Gesellschaft oder Organisation Informationsmehrfachnutzungsdienste oder Informationsverteilungsdienste bereitstellt, wobei diese Informationsmehrfachnutzung in Übereinstimmung mit einer herkömmlichen Internet-Protokollfamilie (d. h. TCP/IP) stattfindet. Im Folgenden werden Einzelheiten gegeben, die die Arten betreffen, in denen das AVSS 100 mit dem Intranet-Serversystem 60 in Wechselwirkung tritt, um die A/V- und/oder Multimedia-Informationsmehrfachnutzung zu ermöglichen.
Das Internet-Gateway/Firewall-System 70 umfasst Hardware und Software, die ein herkömmliches Internet-Firewall-Sicherheits-Gateway- und Dateiübertragungsprotokoll-Gateway-System (FTP-Gateway-System) für den Austausch von Nachrichten und A/V- oder Multimedia-Dateien zwischen dem AVSS 100 und dem öffentlichen Internet 80 implementieren. Die diesbezügliche spezifische AVSS-Funktionalität wird im Folgenden ausführlich beschrieben.
4.5 AVSS-Architektur
Das AVSS 100 umfasst ein Datenlexikon für die A/V-Datei-Speicherung sowie Verarbeitungsbetriebsmittel, auf die Anwendungsprogramme, die in Standort-, Campus- und/oder entfernten CMCE-Elementen ausgeführt werden, gemeinsamen Zugriff haben. In der vorliegenden Erfindung initiieren oder erzeugen Anwendungsprogramme in Reaktion auf Anwenderaktionen an das AVSS 100 gerichtete Dienstanforderungen. Diese Anwendungsprogramme können in Standort-, Campus- oder entfernten Workstations 40 sowie in Computern, die mit einem Unternehmens-Intranet oder mit dem öffentlichen Internet gekoppelt sind, ausgeführt werden: Dienstanforderungen umfassen eine Bitte entweder für a) eine A/V-Betriebsmittel-Zuordnung oder -Dienst-Zuordnung oder b) A/V-Betriebsmittel-Informationen oder Dienstzustands-Informationen. Das AVSS 100 empfängt die Dienstanforderungen über das Datennetz 20 und baut nachrichtengestützte Dienstsitzungen mit dem A/V-Netz 30, mit den Workstations 40, mit den Unterstützungsservern 50, 60, 70 und/oder mit einem oder mit mehreren campusgestützten oder entfernten CMCE-Elementen auf, um in Übereinstimmung mit diesen Anforderungen A/V- und/oder Multimedia-Dienste bereitzustellen. Während einer Dienstsitzung erzeugte Nachrichten können Zustandsinformationen, Steuerbefehle und Bestätigungen umfassen. Die Struktur und die Funktionalität des AVSS 100 und die Arten, in denen das AVSS 100 Dienstanforderungen verarbeitet und Nachrichten erzeugt, werden im Folgenden ausführlich beschrieben.
Wie in 3 gezeigt ist, umfasst das AVSS 100 ein internes Netz 110, wenigstens eine Audio/Video-Speicherzelle (AVSC) 120 und einen Audio/Video-Servermanager (AVSM) 160. Das interne Netz 110 koppelt jede AVSC 120, den AVSM 160, das Datennetz 20, den Intranet-Server 60 und das Internet-Gateway/Firewall-System 70. Wie im Folgenden weiter beschrieben wird, unter stützt der AVSM 160 außerdem über ein dediziertes Teilnetz 112 die Kopplung mit jeder AVSC 110. Darüber hinaus koppelt eine analoge Leitung 14 jede AVSC 110 mit dem A/V-Netz 30.
Jede AVSC 120 dient als ein A/V-Datei-Datenlexikon sowie als ein Datenlexikon für gemeinsam genutzte A/V-Verarbeitungsbetriebsmittel einschließlich Codierern, Decodierern und möglicherweise Transcodern. Der AVSM 160 koordiniert die Aktivitäten der AVSCs 120 und managt Prozesse, die sowohl intern als auch extern zu dem AVSS 100 sind, um Anforderungen auszuführen, die durch Standort- oder Campus- oder entfernte CMCE-Elemente erzeugt werden. Die Struktur und die Funktionalität jeder AVSC 120 und des AVSM 160 werden im Folgenden ausführlich beschrieben.
Das interne Netz 110 umfasst ein herkömmliches Netz hoher Bandbreite, das die schnelle Übertragung von A/V-Dateien zwischen a) einzelnen AVSCs 120, b) AVSCs 120 und dem Datennetz 20 und c) AVSCs 120 und dem Intranet-Serversystem 60 oder dem Internet-Gateway-Firewall-System 70 ermöglicht. Außerdem dient das interne Netz 110 als das Medium, durch das Dienstanforderungen und Nachrichten zwischen dem AVSM 160 und dem Datennetz 20 ausgetauscht werden. Die Bandbreite des internen Netzes 110 reicht aus, um Dienstanforderungen, Steuernachrichten, Dateiübertragungen und die Datei-Streaming-Kapazität des zusammengesetzten AVSS 100 zu übermitteln. In einer Ausführungsform kann das interne Netz 110 als ein Abschnitt des Datennetzes 20 implementiert sein.
Das dedizierte Teilnetz 112 sichert den Austausch von Nachrichten und Steuersignalen zwischen dem AVSM 160 und einzelnen AVSCs 120. Wenn das AVSS 100 wenige AVSCs 120 nutzt, können diese Nachrichten und Steuersignale durch das interne Netz 110 übermittelt werden, was die Notwendigkeit des Teilnetzes 112 beseitigt. Da das AVSS 100 skaliert wird, ist die Verwendung des Teilnetzes 112 dagegen erwünscht, um die innere Netzbelastung zu minimieren.
4.5.1 AVSC-Architektur
Wie zuvor angegeben wurde, stellt jede AVSC 120 A/V-Datei-Speicherungs- und A/V-Datei-Verarbeitungsbetriebsmittel bereit, die von anderen CMCE-Elementen gemeinsam genutzt werden. 5 ist ein Blockschaltplan einer AVSC 120, die in Übereinstimmung mit der vorliegenden Erfindung konstruiert ist. Die AVSC 120 umfasst eine Verarbeitungseinheit 122, eine gemeinsam genutzte Datenspeichereinheit 124, wenigstens eine Netzschnittstelle 126, eine AVSM-Schnittstelle 128, wenigstens eine gemeinsam genutzte Codierungseinheit 130, wenigstens eine A/V-Schnittstelleneinheit 140 und einen Arbeitsspeicher 150, der einen AVSC-Objektarbeitsspeicher 152, einen AVSC-Zustandsarbeitsspeicher 154 und ein Betriebssystem 156 enthält. Mit Ausnahme der A/V-Schnittstelleneinheit 140 ist jedes AVSC-Element mit einem gemeinsamen AVSC-Bus 159 gekoppelt. Die A/V-Schnittstelleneinheit 140 dient als eine Schnittstelle zwischen jeder gemeinsam genutzten Codierungseinheit 130 und der A/V-Vermittlung 32. Schließlich koppeln die Netzschnittstelle 126 und die AVSM-Schnittstelle 128 die AVSC 120 mit dem AVSS-internen Netz 110 bzw. Teilnetz 112.
Die Verarbeitungseinheit 122 umfasst einen herkömmlichen Hochleistungsprozessor zur Ausführung von in dem Arbeitsspeicher 150 gespeicherten Programmanweisungen. Die Netzschnittstelle 126 umfasst eine herkömmliche Netzschnittstellen-Schaltungsanordnung für das Management von Datenaustauschen zwischen der AVSC 120 und dem internen Netz 110. In gleicher Weise umfasst die AVSM-Schnittstelle 128 eine herkömmliche Netzschnittstellen-Schaltungsanordnung für das Management des Austauschs von Nachrichten und Steuersignalen zwischen der AVSC 120 und dem AVSM 160. Das Betriebssystem 156 umfasst vorzugsweise herkömmliche Echtzeit-Multitasking-Betriebssystemsoftware wie etwa Windows NT (Microsoft Corporation, Redmond, WA) oder Echtzeit-Unix.
Wie im Folgenden ausführlich beschrieben wird, speichert der AVSC-Objektarbeitsspeicher 152 mehrere AVSC-Softwareobjekte, die die AVSC-Hardwarezuordnung und -Betriebsmittelverriegelung, A/V-Datei-Codierungs-, A/V-Datei-Decodierungs- und A/V-Datei-Transcodierungsoperationen sowie Dateimanagementoperationen wie etwa die Dateireplikation, -übertragung und -löschung leiten. Außerdem unterhalten die AVSC-Objekte den Inhalt des AVSC-Zustandsarbeitsspeichers 154, der die folgenden Informationen enthält:

1) Codierer/Decodierer/Transcoder-Betriebsmittelfähigkeit und momentaner Status/momentane Nutzung;
2) Momentane Speichervorrichtungskapazität und -nutzung;
3) eine zeitgestempelte und indizierte Anforderungswarteschlange sowohl für ankommende als auch für abgehende Anforderungen;
4) eine zeitgestempelte und indizierte Nachrichtenwarteschlange sowohl für ankommende als auch für abgehende Nachrichten;
5) eine zeitgestempelte und indizierte Dateiübertragungsereignis-Warteschlange; und
6) ein AVSC-Ereignisprotokoll, das zeitgestempelte Standardereignisse sowie das Auftreten von Codierer-, Decodierer-, Transcoder-, Speichervorrichtungs- und/oder Netzstörungen angibt.

Um die Menge der zur Erfüllung irgendwelcher bestimmter A/V-Datei-Speicher- und/oder Mehranwender-A/V-Datei-Zugriffs-Leistungsanforderungen erforderlichen Hardware zu minimieren, sollte die Standort-A/V-Datei-Speicherhardware eher gemeinsam genutzt oder zentralisiert als in jeder Workstation 40 lokalisiert sein. Außerdem maximiert die Zentralisierung der Datenspeicherhardware wegen statistischer Mittelung die Effizienz der systemweiten Nutzung und Organisation und kann außerdem die Fehlertoleranz verbessern. Die gemeinsam genutzte Dateispeichereinheit 124 umfasst wenigstens ein Plattenlaufwerk hoher Kapazität zum Speichern von A/V-Dateien und -Daten sowie eine entsprechende Plattenlaufwerkssteuerung. Die A/V-Datei-Speicherbetriebsmittel in einer CMCE 10 mit einem analogen Standortsignalverteilungsnetz sind eher vollständig AVSC-gestützt als workstationgestützt. Wie im Folgenden ausführlich beschrieben wird, können in AVSS-Implementierungen mit mehr als einer AVSC 120 mehrere Kopien irgendeiner gegebenen A/V-Datei über verschiedene AVSCs 120 gespeichert werden, um die Systemreaktion auf den Zugriff auf Dateien, auf die gemeinsam zugegriffen wird, zu verbessern. Wenn ein AVSS 100 eine einzelne AVSC 120 nutzt, könnten ferner mehrere Kopien irgendeiner gegebenen A/V-Datei über mehrere 1) gemeinsam genutzte Datenspeichereinheiten 124 in der AVSC 120 und/oder 2) mit der AVSC 120 gekoppelte Speichervorrichtungen ge speichert werden. Aus einem äußeren Blickwinkel stellt das AVSS 100, das auf diese Weise arbeitet, eine zentralisierte A/V-Datei-Speicherung bereit, während die A/V-Dateien zwischen den gemeinsam genutzten Datenspeichereinheiten 124 intern über die Menge der AVSCs 120 verteilt werden.
Jede gemeinsam genutzte Codierungseinheit 130 umfasst wenigstens eine Instanz von Codierungs-, Decodierungs- und/oder Transcodierungsbetriebsmitteln. Für gemeinsam genutzte Codierungseinheiten mit mehr als einem Codierer und/oder Decodierer ist eine Mehrkanalversion der A/V-Schnittstelle 140 erforderlich (während alternativ für eine einzelne Codierungseinheit 130 mehrere A/V-Schnittstellen 140 vorgesehen sein können). In einigen Ausführungsformen kann die Transcodierung durch die Verarbeitungseinheit in Software erfolgen. In anderen Ausführungsformen kann ein dedizierter Hardwaretranscoder verwendet werden – eine solche Instanz von 130 würde keine AV-Schnittstelle 140 erfordern. Die vorliegende Erfindung kann im Wesentlichen irgendein Codierungsformat einschließlich MPEG-gestützter Formate, Real-Media-Formate und NetShow-Formate unterstützen. In einer Ausführungsform verwendet die AVSC 120 als ein Standardformat ein gegebenes Codierungsformat, z. B. die MPEG1-Codierung, die innerhalb eines Kompressionsleistungsbereichs von näherungsweise 1,1 bis 3 Megabit/s abstimmbar ist. Wie im Folgenden weiter beschrieben wird, ist das bestimmte zu irgendeiner gegebenen Zeit genutzte Codierungsformat ein anwendungsabhängiger und/oder anwenderabhängiger Parameter.
Üblicherweise erfordert die Erzeugung und Umcodierung einer A/V-Datei eine einzelne Codierungssitzung, die nach Bedarf angehalten oder unterbrochen und neu gestartet werden kann. Da eine A/V-Datei wahrscheinlich entweder in wiederholten oder in gleichzeitigen Sitzungen mehrmals wiedergegeben wird, ist die Decodierung wahrscheinlich eine viel häufiger angeforderte Operation als die Codierung. Eine oder mehrere gemeinsam genutzte Codierungseinheiten 130 können über die Menge der AVSCs 120 in dem AVSS 100 verschiedene Codierungs-, Decodierungs- und/oder Transcodierungssitzungsoptionen unterstützen. Zum Beispiel könnte die Hardware in der gemeinsam genutzten Codierungseinheit 130 in irgendeiner bestimmten AVSC 120 z. B. irgendeines der Folgenden unterstützen:

1) eine Codierungssitzung oder eine Decodierungssitzung, die sich gegenseitig ausschließen;
2) eine Codierungssitzung gleichzeitig mit einer Decodierungssitzung;
3) mehrere gleichzeitige Codierungs- und Decodierungssitzungen;
4) mehrere gleichzeitige Decodierungssitzungen; oder
5) eine oder mehrere Transcodierungssitzungen in Verbindung mit irgendeinem des obigen.

Außerdem könnte irgendeine AVSC 120 eines der obigen entweder sich gegenseitig ausschließend oder gleichzeitig mit der Dateiübertragung zu oder von der gemeinsam genutzten Datenspeichereinheit 124 unterstützen.
Im Allgemeinen kann wenigstens eine AVSC 120 sowohl A/V-Datei-Codierungssitzungen als auch -Decodierungssitzungen gleichzeitig sowie mehrere Sitzungen zur gleichen Zeit unterstützen. Außerdem ist jede AVSC 120 in Bezug auf die Anzahl der zur Erfüllung sich entwickelnder AVSS-Implementierungsnotwendigkeiten erforderlichen Codierungs-, Decodierungs- und Transcodierungsbetriebsmittel stark skalierbar. Darüber hinaus kann jede AVSC 120 ohne Architekturänderung im Wesentlichen irgendeinen Typ von Codierungs-, Decodierungs- und/oder Transcodierungsbetriebsmitteln unterstützen und dadurch leicht an die A/V-Verarbeitungsbetriebsmittel-Entwicklung über die Zeit angepasst werden. Somit gibt es eine breite Vielfalt von Ausführungsformen gemeinsam genutzter Codierungseinheiten, von denen im Folgenden Beispiele beschrieben werden.
Nunmehr anhand von 6 ist ein Blockschaltplan einer ersten Ausführungsform der gemeinsam genutzten Codierungseinheit 130 gezeigt. In der ersten Ausführungsform umfasst die gemeinsam genutzte Codierungseinheit 130 wenigstens einen Codierer 132 zuzüglich einer Menge von Decodierern 134, die mehrere gleichzeitige Decodierungssitzungen unterstützen können. Diese Anforderung kann unter Verwendung mehrerer sich wechselweise ausschließender Decodierer 134 oder eines oder mehrerer gleichzeitig fähiger Decodierer 134 erfüllt werden.
Nunmehr ebenfalls anhand von 7 ist ein Blockschaltplan einer zweiten Ausführungsform der gemeinsam genutzten Codierungseinheit 130 gezeigt. In der zweiten Ausführungsform umfasst die gemeinsam genutzte Codierungseinheit 130 eine Menge von Decodierern 134, die mehrere gleichzeitige Decodierungssitzungen unterstützen können. Wie in der Beispielausführungsform kann die Menge der Decodierer 134 über mehrere sich wechselweise ausschließende Decodierer 134 oder über wenigstens einen gleichzeitig fähigen Decodierer 134 implementiert sein. In der zweiten Ausführungsform ist die AVSC 120, in der die Menge der Decodierer 134 liegt, ausschließlich für die Erfüllung von Decodierungsanforderungen vorgesehen, was wiederum bedeutet, dass wenigstens ein Codierer 132 in einer weiteren AVSC 120 vorhanden wäre.
Der Fachmann auf dem Gebiet versteht, dass A/V-Dateien in Übereinstimmung mit einer Vielzahl von Formaten codiert werden können. Somit kann gelegentlich eine Transcodierung erforderlich sein, um eine A/V-Datei in ein anderes Format zu konvertieren als das, das zum Aufzeichnen der A/V-Datei genutzt wurde. Nunmehr anhand von 8 ist ein Blockschaltplan einer dritten Ausführungsform der gemeinsam genutzten Codierungseinheit 130 gezeigt, die wenigstens einen Codierer 132, wenigstens einen Decodierer 134 und einen Transcoder 136 umfasst. Wenn eine AVSC 120 einen oder mehrere Transcoder 136 enthält, stellt die vorliegende Erfindung vorzugsweise eine Echtzeittranscodierung bereit, sodass die Wiedergabe von A/V-Dateien, die eine Formatkonvertierung erfordern, ohne Verzögerungen durch sequentielle Konvertierung der vollständigen Datei stattfinden kann.
Die Codierungs-, Decodierungs- und Transcodierungsbetriebsmittel sind in der vorliegenden Erfindung auf analoge Weise wie die gemeinsam genutzte Datenspeichereinheit 124 eher AVSC-gestützt als workstationgestützt. Aus einem externen Blickwinkel stellt das AVSS 100 zentralisierte Codierungs-, Decodierungs- und Transcodierungsbetriebsmittel bereit, während die oben erwähnten Betriebsmittel intern über eine oder mehrere AVSCs 120 verteilt sind. Diese Pool-Betriebsmittelorganisation maximiert die Codierungs-, Decodierungs- und Transcodierungs-Betriebsmittel-Nutzungseffizienz, während sie die Anzahl dieser zur Erfüllung irgendwelcher gegebenen Leistungsanforderungen erforderlichen Betriebsmittel minimiert.
In einer beispielhaften Ausführungsform ist eine AVSC 120 als ein Personal-Computer-Server mit einem Pentium-II-Prozessor (Intel Corporation, Santa Clara, CA) oder mit einem allgemein äquivalenten Mikroprozessor, 128 Megabyte Schreib-Lese-Speicher (RAM), einem Optibase-MovieMaker-Codierer und einem Optibase-VideoPlex-Decodierer (Optibase Inc., San Jose, CA), einer Netzschnittstellenkarte und einem UltraWide und Fast-SCSI-18-Gigabyte- oder größeren Plattenlaufwerk zum Speichern von A/V- und verwandten Dateien implementiert.
4.5.2 AVSM-Architektur
Der AVSM 160 umfasst Hardware und Software, die die Verarbeitung von Anforderungen, die von standortgestützten, campusgestützten oder entfernten CMCE-Elementen empfangen werden, managt oder koordiniert. Wie im Folgenden ausführlich beschrieben wird, kann die Verarbeitung solcher Anforderungen im Kontext der Konferenzaufzeichnung, des Telephonanrufbeantworters, der E-Mail, der Dokumenterzeugung, der Dokumentveröffentlichung oder anderer Anwendungen zur Erzeugung, Umcodierung/Codierung, Speicherung, Verteilung, Decodierung/Wiedergabe, Archivierung oder Löschung von A/V- oder Multimedia-Dateien führen. Der Fachmann auf dem Gebiet versteht, dass viele in Bezug auf die Architektur veränderliche Ausführungsformen möglich sind. Die im Folgenden beschriebene Ausführungsform schafft ein befähigendes Architekturbeispiel.
Der AVSM 160 umfasst einen netzgestützten Multitasking-Computer. 9 ist ein Blockschaltplan eines AVSM 160, der in Übereinstimmung mit der vorliegenden Erfindung konstruiert ist. Der AVSM 160 umfasst eine Verarbeitungseinheit 162, eine Netzschnittstelle 164, eine AVSC-Schnittstelleneinheit 166, eine Datenspeichereinheit 168 und einen Arbeitsspeicher 170, in dem ein AVSM-Objektarbeitsspeicher 172, ein AVSS-Zustandsarbeitsspeicher 174, ein AVSS-Datenbankarbeitsspeicher 176 und ein Betriebssystem 178 liegen. Jedes Element in dem AVSM 160 ist mit einem gemeinsamen AVSM-Bus 199 gekoppelt.
Die Verarbeitungseinheit 162 umfasst einen herkömmlichen Hochleistungsprozessor für die Ausführung gespeicherter Programmanweisungen und die Datenspeichereinheit 168 umfasst wenigstens ein Plattenlaufwerk. Die Netzschnittstelle 164 und die AVSC-Schnittstelleneinheit 166 umfassen eine herkömm liche Netzschnittstellen-Schaltungsanordnung für das Management der Kommunikation mit dem internen Netz 110 bzw. mit den AVSCs 120. Das Betriebssystem 178 umfasst ein herkömmliches Multitasking-Betriebssystem wie etwa Windows NT.
Der AVSM-Objektarbeitsspeicher 172 speichert mehrere AVSM-Softwareobjekte, die die im Folgenden ausführlich beschriebenen AVSS-Dienste und Betriebsmittel-Managementoperationen ausführen oder managen, die Folgende enthalten: a) den Aufbau von Anwenderanforderungs-Verarbeitungssitzungen, b) die Zuordnung von AVSC-Betriebsmitteln und die zugeordnete Betriebsmittelverriegelung, c) den Aufbau von A/V-Netz-Kommunikationskopplungen, d) Anwenderanwendungsschnittstellen und Nachrichten-Routing, e) die Inter- und Intra-AVSS-Dateiübertragungsinitiierung und f) Organisationsoperationen, wie sie im Folgenden ausführlich beschrieben werden. Außerdem unterhalten die AVSM-Objekte den Inhalt der AVSS-Datenbank, die in dem AVSS-Datenbankspeicher 176 und/oder in der Datenspeichereinheit 168 gespeichert ist.
Die AVSS-Datenbank speichert eine Vielzahl von Informationen, die Folgendes definieren: a) die AVSS-Kommunikationsumgebung, b) das Wesen und die Fähigkeiten der gemeinsam genutzten AVSC-Betriebsmittel, c) Organisationsparameter und Nutzungsdaten und d) Eigenschaften der in den AVSCs 120 gespeicherten A/V-Dateien. In Bezug auf die AVSS-Kommunikationsumgebung enthalten die Informationen, die die AVSS-Datenbank speichert, die Folgenden:

1) die Anzahl und die Typen der Dateiübertragungskanäle einschließlich digitaler Dateiübertragungskanäle, die sich aus AVSC-Kopplungen zu dem internen Netz 110 und zu dem Datennetz 20 ergeben, zuzüglich analoger Dateiübertragungskanäle, die den AVSC-Kopplungen zu dem A/V-Netz 30 entsprechen;
2) den Standort-AVSS-Host-Namen und die Standort-AVSS-Portkennung;
3) einen oder mehrere Nicht-Standort-AVSS-Host-Namen und -Portkennungen zuzüglich Verbindungsaufbauinformationen, die jedem Nicht-Standort-AVSS 100 zugeordnet sind;
4) A/V-Netz-Konfigurationsparameter;
5) Unterstützungsserversystem-Konfigurationsparameter;
6) eine Anwenderkennung (ID) oder einen Namen für jeden Anwender in der Standortgruppe, zu der das AVSS 100 gehört, zuzüglich jeder Anwender-ID entsprechender Kennwortinformationen; und
7) jeder Anwender-ID entsprechende Kommunikationspräferenzen wie etwa ein bevorzugtes Codierungsformat und/oder A/V-Datei-Lieferungsformat.

In Bezug auf gemeinsam genutzte AVSC-Betriebsmittel enthält die AVSS-Datenbank die folgenden Informationen:

1) die Anzahl, Typen und Fähigkeiten der Speicherbetriebsmittel in jeder AVSC 120; und
2) die Anzahl, Typen und Fähigkeiten der Codierungs-, Decodierungs- und Transcodierungsbetriebsmittel in jeder AVSC 120.

Die Organisationsparameter, die in der AVSS-Datenbank liegen, enthalten eine maximal zulässige A/V-Datei-Größe und ein maximal zulässiges A/V-Datei-Alter. Das maximal zulässige A/V-Datei-Alter kann in Bezug auf die Erzeugungszeit und auf das Erzeugungsdatum einer A/V-Datei oder in Bezug auf den letzten Zugriff definiert werden. Die Nutzungsdaten enthalten eine Ereignisstatistikdatei, die Ereignisauftretenshäufigkeiten wie etwa die Anzahl der Anwender, die in einem gegebenen Zeitintervall auf das AVSS 100 zugegriffen haben, eine Anzahl, in der auf die A/V-Datei zugegriffen worden ist, ein Datum und eine Zeit des letzten Zugriffs für eine A/V-Datei und eine Zeitdauer, die während eines bestimmten Zeitintervalls bei der Ausführung von A/V-Datei-Wiedergabeoperationen verbracht wurde, genau beschreibt.
Die AVSS-Datenbank speichert für jede einzelne A/V-Datei, die in den AVSCs 120 gespeichert ist, eine Dateiparametertabelle, die die folgenden Informationen enthält:

1) einen Dateinamen;
2) ein Dateikennwort;
3) eine Anwender-ID, die die Dateiautorschaft angibt,
4) eine Dateieigentum- oder Zugriffsrechteliste gemäß Anwender-ID, die ein Zugriffsablaufdatum und eine Zugriffsablaufzeit sowie die der Anwender-ID zugeordnete Historie des letzten Zugriffs (Datum und Zeit) enthält;
5) das A/V-Codierungsformat;
6) die Zeit und das Datum der letzten Änderung;
7) die Dateigröße;
8) die Wiedergabedauer;
9) das Dateialter;
10) den Ort jeder Kopie der Datei über die AVSCs 120;
11) eine Liste, die irgendwelche der A/V-Datei zugeordnete in dem AVSS liegende Multimedia-Synchronisationsdateien identifiziert und lokalisiert; und
12) eine Liste, die irgendwelche Nicht-AVSS-Zielserver angibt, zu denen die Datei, wie im Folgenden ausführlich beschrieben wird, veröffentlicht worden ist.

Außerdem könnten die AVSM-Objekte für jede Standortgruppen-Anwender-ID eine anwenderspezifische Dateiliste in der AVSS-Datenbank unterhalten. In einer solchen Ausführungsform enthält die anwenderspezifische Dateiliste den Namen jeder A/V-Datei, für die die Anwender-ID in der Zugriffsrechteliste der Datei angegeben worden ist, wobei sie angibt, ob die Anwender-ID in den Autorschaftsdaten der Datei angegeben ist.
Außerdem unterhalten die AVSM-Objekte den Inhalt des AVSS-Zustandsarbeitsspeichers 174, um den momentanen Betriebsmittel-, Anforderungs- und Nachrichtenstatus über alle momentan aktiven Anforderungsverarbeitungssitzungen zu widerspiegeln. Der Inhalt des AVSS-Zustandsarbeitsspeichers 174 enthält das Folgende:

1) eine Liste momentaner Anwender, die die momentan angemeldeten Anwendern entsprechende Anwender-IDs angibt;
2) eine Liste momentan aktiver Anwendungsverarbeitungssitzungen;
3) eine zeitgestempelte und indizierte Anforderungswarteschlange, die sowohl für ankommende als auch für abgehende Anforderungen momentan anstehende Anforderungen identifiziert;
4) die momentan verfügbare Kapazität und Nutzung für jedes AVSS-Speicherbetriebsmittel;
5) die momentane Codierungs/Decodierungs/Transcodierungs-Betriebsmittelnutzung; und
6) ein AVSM-Ereignisprotokoll, das Sitzungszeitablaufvorkommen, Anwendungsfehler, AVSC-Störungen, Netzstörungen, Änderungen der Liste momentaner Anwender und der Liste momentan aktiver Sitzungen, Änderungen der Speicherbetriebsmittelnutzung und des verfügbaren Speicherplatzes und Änderungen der Codierungs-, Decodierungs- und/oder Transcodierungsbetriebsmittelnutzung angibt. Der Inhalt des AVSM-Ereignisprotokolls wird zur Aktualisierung der Ereignisstatistikdatei verwendet.

In einer beispielhaften Ausführungsform ist der AVSM 160 als ein Personal-Computer-Server mit einem Pentium-II-Prozessor oder mit einem allgemein äquivalenten Prozessor, mit einer Netzschnittstellenkarte, mit 128 Megabytes RAM und mit einem 10-Gigabyte- oder größeren Festplattenlaufwerk implementiert. Der Fachmann auf dem Gebiet versteht, dass der AVSM 160 unter Verwendung einer Hardware/Software-Plattform implementiert sein könnte, die im Wesentlichen gleich der zur Implementierung einer AVSC 120 verwendeten ist.
4.5.3 Skalierungshierarchie
Die vorliegende Erfindung kann skaliert werden, um verbesserte Leistung und/oder zusätzliche Fähigkeiten bereitzustellen. Es sind zwei Skalierungstypen, die zahlenmäßige und die evolutionäre Skalierung, möglich. Die zahlenmäßige Skalierung bedeutet die Aufnahme zusätzlicher Hardwareelemente, während die evolutionäre Skalierung den Ersatz vorhandener Hardwareelemente durch Hardware mit höherer Leistung oder "technologisch entwickeltere" Hardware bedeutet. Die hier beschriebenen Architekturen lassen sich an die zahlenmäßige und/oder an die evolutionäre Skalierung flexibel über mehrere miteinander verknüpfte hierarchische Leistungsgrenzen oder -niveaus anpassen, die die Folgenden enthalten:

4.5.3.1 Bus- und Prozessordurchsatz – Die Fähigkeiten des Busses und des Prozessors in einer AVSC 120 oder in einem AVSM 160 definieren einen Typ einer AVSC- bzw. AVSM-Leistungsgrenze. Zum Beispiel begrenzen Busdurchsatzbeschränkungen die Menge der für die Übertragung von Informationen zwischen Elementen in irgendeiner gegebenen AVSC 120 oder in irgendeinem gegebenen AVSM 160 verfügbaren Bandbreite. Diese Leistungsgrenze kann über eine Hardwareplattformaktualisierung, die eine evolutionäre Skalierung ist, überschritten oder erweitert werden.
4.5.3.2 Durchsatz und Kapazität der gemeinsam genutzten Datenspeichereinheit – Die Datenübertragungsrate und die Speicherkapazität der gemeinsam genutzten Datenspeichereinheit 124 in irgendeiner bestimmten AVSC 120 definieren eine weitere Leistungsgrenze. Diese Grenze kann durch die Aufnahme zusätzlicher Datenspeichervorrichtungen in die gemeinsam genutzte Datenspeichereinheit 124 und/oder durch die Verwendung von Datenspeichervorrichtungen höherer Leistung überschritten werden. Der durch die zahlenmäßige oder evolutionäre Skalierung erzielte Leistungsgewinn hängt in diesem Fall von der oben beschriebenen Busdurchsatzgrenze ab.
4.5.3.3 Der Durchsatz der gemeinsam genutzten Codierungseinheit und die Fähigkeiten der A/V-Datei-Verarbeitungsfähigkeiten der gemeinsam genutzten Codierungseinheit 130 in irgendeiner gegebenen AVSC 120 definieren ebenfalls eine Leistungsgrenze. Die Aufnahme zusätzlicher Codierungs-, Decodierungs- und/oder Transcodierungsbetriebsmittel in eine gemeinsam genutzte Codierungseinheit und/oder die Verwendung von A/V-Verarbeitungsbetriebsmitteln höherer Leistung führen zur Erweiterung dieser Grenze. Der Fachmann auf dem Gebiet versteht, dass Betriebsmittel mit hö herer Leistung in diesem Fall wahrscheinlich im Wesentlichen gleichzeitige Codierungs-, Decodierungs- und/oder Transcodierungsoperationen in mehreren Ausführungs-Threads ausführen würden. Außerdem erkennt der Fachmann auf dem Gebiet, dass der durch zahlenmäßige oder evolutionäre Skalierung erzielte Leistungsgewinn hier von der oben erwähnten Busdurchsatzgrenze abhängt.
4.5.3.4 Gemeinsame AVSC-Fähigkeiten und -Durchsatz – Die gesamte A/V-Datei-Verarbeitungsleistung und die gesamten A/V-Datei-Verarbeitungsfähigkeiten der Menge der AVSCs 120 in dem AVSS führen eine weitere Leistungsgrenze ein, die durch die Aufnahme zusätzlicher AVSCs 120 in das AVSS und/oder unter Verwendung von AVSCs 120 höherer Leistung überschritten werden kann. Der Fachmann auf dem Gebiet versteht, dass die Erhöhung der Leistung irgendeiner gegebenen AVSC 120 das Überschreiten einer oder mehrerer der zuvor beschriebenen Leistungsgrenzen umfasst.
4.5.3.5 Interne Netzbandbreite – Die Datenübertragungsfähigkeiten oder Belastungsbeschränkungen des AVSS-internen Netzes 110 führen eine weitere Leistungsgrenze ein, die durch evolutionäre Skalierung überschritten werden kann.
4.5.3.6 Gemeinsame vernetzte AVSS-Leistung und -Fähigkeiten – Die Leistung und die Fähigkeiten einer gesamten über einen Campus und/oder über ein Weitverkehrsnetz gekoppelten AVSS-Gruppe führen ebenfalls eine Leistungsgrenze ein, die durch zahlenmäßige und/oder evolutionäre Skalierung in Übereinstimmung mit den Leistungsanforderungen in Bezug auf Kostenbeschränkungen leicht überschritten werden kann.

Der Fachmann auf dem Gebiet erkennt, dass ein System ebenso, wie es in Bezug auf die Leistung nach oben skaliert werden kann, ebenfalls nach unten skaliert werden kann, was z. B. stattfinden könnte, wenn Kostenbeschränkungen von höchster Wichtigkeit sind. Allerdings kann die Architektur der vorliegenden Erfindung eine hohe A/V- und/oder Multimedia-Verarbeitungsleistung bereitstellen, während sie die Fähigkeiten leicht verfügbarer kostengünstiger Technologie wirksam einsetzt.
4.6 Funktionsaufteilung zwischen AVSM und AVSCs
Die Typen der durch den AVSM 160 ausgeführten Funktionen werden in Bezug auf jene, die durch die AVSCs 120 ausgeführt werden, so aufgeteilt, dass insbesondere angesichts der zahlenmäßigen und evolutionären Skalierbarkeit über irgendeine interne AVSS-Implementierung im Wesentlichen eine gleichbleibende Betriebsfähigkeit sichergestellt wird. Im Ergebnis kann der AVSM 160 ohne Änderung einen sich ständig entwickelnden Bereich von AVSC-Implementierungen unterstützen.
Der AVSM 160 sichert das zentralisierte Management der AVSS-Funktionalität. Der AVSM 160 empfängt von Anwenderanwendungen AVSS-Dienstanforderungen und -Steuernachrichten. Wie im Folgenden ausführlich beschrieben wird, baut der AVSM 160 in Reaktion auf Dienstanforderungen Anforderungsverarbeitungssitzungen auf. Der AVSM erzeugt eine Sitzungszugriffsnummer, um jede solche Sitzung eindeutig zu identifizieren. Beispielhafte AVSS-Dienstanforderungen enthalten die Folgenden:

1) Anmeldung {Anwender-ID, Kennwort};
2) erzeuge und codiere A/V-Datei {Sitzungszugriffsnummer, Dateiname, Dateikennwort zuzüglich weiterer im Folgenden beschriebener Parameter};
3) hole und decodiere A/V-Datei {Sitzungszugriffsnummer, Dateiname, Dateikennwort};
4) lösche A/V-Datei {Sitzungszugriffsnummer, Dateiname, Dateikennwort};
5) kopiere A/V-Datei {Quelladresse, Quellsitzungszugriffsnummer, Zieladresse, Zielsitzungszugriffsnummer zuzüglich weiterer im Folgenden beschriebener Parameter}; und
6) verschiebe A/V-Datei {Quelladresse, Quellsitzungszugriffsnummer, Zieladresse, Zielsitzungszugriffsnummer zuzüglich weiterer im Folgenden be schriebener Parameter}.

Weitere Typen von AVSS-Dienstanforderungen enthalten Anforderungen für das Senden oder Empfangen von Datenströmen, für das Abrufen oder Verteilen von Dateien und für das Ausführen von Organisations- und Diagnoseoperationen. Von Anwenderanwendungen empfangene Steuernachrichten enthalten Quittierungen, Fehlercodes und interaktive Steueranforderungen wie etwa Start-, Stopp-, Pause-, Rücklauf- und/oder Schneller-Vorlauf-Befehle, die während der Aufzeichnung, während der Wiedergabe und/oder während des Editierens von A/V-Dateien ausgegeben werden.
Der AVSM 160 kann in Reaktion auf AVSS-Dienstanforderungen eine oder mehrere Funktionen direkt ausführen und/oder in Übereinstimmung mit den AVSC-Fähigkeiten und mit der AVSC-Verfügbarkeit eine Menge höherer Anforderungen an seine zugeordneten AVSCs 120 ausgeben. Hinsichtlich direkt ausgeführter Funktionen baut der AVSM 160 Anforderungsverarbeitungssitzungen mit Anwenderanwendungen auf und managt sie, ordnet er A/V-Dateinamen zu und verfolgt er den A/V-Datei-Ort und die A/V-Datei-Nutzungsinformationen, ordnet er auf der Grundlage der AVSC-Fähigkeiten und -Verfügbarkeit AVSC-Betriebsmittel zu, um Verarbeitungssitzungen anzufordern, ordnet er Datei-Kopier- und Datei-Verschiebungstransaktionen AVSC-Betriebsmittel zu, leitet er die Datei-Kopier- und Datei-Verschiebungsanforderungen zu Campus- oder entfernten Systemen weiter, wenn eine A/V-Datei nicht in einer der Standort-AVSCs 120 liegt, und gibt er Anforderungen an das A/V-Netz 30 aus, um eine A/V-Kommunikation aufzubauen und A/V-Netz-Dienste (wie etwa Konferenzen) für Anwenderanwendungen auszuführen.
Irgendeine gegebene AVSC 120, die von dem AVSM 160 eine höhere Anforderung empfängt, führt die Anforderung durch Ausführen einer Menge von Operationen in Übereinstimmung mit ihren eigenen Methoden und Beschränkungen aus. Auf diese Weise kann der AVSM 160 so konstruiert sein, dass er ein "Mikromanagement" der Einzelheiten des Betriebs der AVSC 120 vermeidet. Eine AVSC 120 kann je nach dem Wesen einer höheren Anforderung ein Codierungs-, Decodierungs- oder Transcodierungsbetriebsmittel zuordnen und verriegeln, Dateispeicherplatz zuordnen, eine Codierungs-, Decodierungs- oder Transcodie rungsprozedur ausführen, eine Dateiübertragungs- oder Dateikopieroperation zu oder von einem lokalen oder entfernten Zielbestimmungsort oder zu oder von einer lokalen oder entfernten Quelle ausführen, eine Datei löschen oder den Anforderungsverarbeitungs-, Nachrichten-, Speichervorrichtungs-, und/oder Codierungs-, Decodierungs-, oder Transcodierungs-Betriebsmittelstatus an den AVSM 160 berichten.
4.7 AVSS-Dienste
Der AVSM 160 managt eine Vielzahl von AVSS-Diensten einschließlich des Sitzungsmanagements, des Dateimanagements, des Vorrichtungsmanagements und von Organisationsdiensten oder stellt sie bereit. Im Folgenden werden Einzelheiten dieser Dienste und die Arten beschrieben, in denen sie implementiert werden.
4.7.1 Sitzungsmanagementdienste
Aus dem Blickwinkel von Anwendungsprogrammen, die in Anwender-Workstations 40 oder in anderen mit der CMCE 10 gekoppelten Computern ausgeführt werden, stellt der Standort-AVSM 160 den Zugriff auf Dienste bereit, die Standort-, Campus- und/oder Weitverkehrs-AVSS-Betriebsmitteln zugeordnet sind. Wie im Folgenden ausführlich beschrieben wird, erzeugt irgendein gegebenes Anwendungsprogramm üblicherweise eines oder mehrere Graphikfenster zuzüglich Menüs sowie Steuer-, Listen-, Dialog- und/oder andere Graphikfelder, die einen Teil einer graphischen Anwenderschnittstelle (GUI) bilden. Das Anwendungsprogramm ist in einer vom Fachmann auf dem Gebiet gut verstandenen Weise für Auswahlen verantwortlich, die ein Anwender graphisch angibt.
Insbesondere geben Anwenderauswahlen an, dass der Anwender AVSS-bezogene Dienste anfordert. Das Anwendungsprogramm gibt in Reaktion auf diese Auswahlen Dienstanforderungen an den zugeordneten Standort-AVSM 160 aus. Beim Empfang einer Dienstanforderung baut der AVSM 160 eine Anforderungsverarbeitungssitzung auf, um die Bereitstellung des geforderten Dienstes sicherzustellen oder zu überwachen. Während der Sitzung kann der AVSM 160 eine oder mehrere Operationen direkt ausführen und/oder kann der AVSM 160 eine oder mehrere an die Standort-AVSCs 120, an den Standort-A/V-Netz- Manager 34 und/oder an die Campus- oder entfernten AVSMs 160 gerichtete Anforderungen erzeugen. Außerdem können an der Sitzung beteiligte Standort-, Campus- oder entfernte CMCE-Elemente Anforderungen erzeugen, die zueinander und/oder zu dem Anwendungsprogramm gerichtet sind.
10 ist ein Blockschaltplan, der Sitzungskommunikationsprotokolle veranschaulicht, die in einer Ausführungsform der vorliegenden Erfindung genutzt werden. Im Wesentlichen irgendeine Anzahl von Instanzen einer breiten Vielfalt von Anwendungsprogrammen kommunizieren über ein AVSM-Client-Protokoll mit ihren entsprechenden Standort-AVSM 160. Ein gegebener Standort-AVSM 160 kommuniziert über ein AVSC-Client-Protokoll mit seinen zugeordneten AVSCs 120 und über ein A/V-Netz-Client-Protokoll mit dem Standort-A/V-Netz-Manager 34. Die Kommunikation von AVSM zu AVSM über den Standort beruht auf einem AVSM-Peer-Protokoll, während die analoge A/V-Netz-Manager-Kommunikation auf einem A/V-Netz-Peer-Protokoll beruht.
Bevor ein Workstation-Anwender Zugang zu A/V-Verarbeitungsbetriebsmitteln oder -diensten erhält, muss er ein AVSS-Zugriffsprogramm ausführen, das eine Anmeldeanforderung an den AVSM 160 ausgibt. Wie im Folgenden ausführlich beschrieben wird, enthält die Anmeldeanforderung eine Anwender-ID, die für den AVSM 160 zur Dateieigentums- und Dateizugriffsberechtigungsprüfung die Identität des Anwenders festsetzt. Außerdem stellt die Anwender-ID für den AVSM 160 die A/V-Netz-Port-Informationen bereit, die für den Aufbau irgendwelcher erforderlichen A/V-Netz-Verbindungen notwendig sind. In einer Ausführungsform enthält die Anmeldeanforderung zusätzlich Kennwortinformationen, die verschlüsselt sein können. Wenn ein Anwender keinen Zugriff auf A/V-Verarbeitungsbetriebsmittel oder -dienste mehr benötigt, kann der Anwender das AVSS-Zugriffsprogramm nutzen, um an den AVSM 160 eine Abmeldeanforderung auszugeben, was zur Entfernung der entsprechenden Anwender-ID aus der Liste momentaner Anwender in dem AVSS-Zustandsarbeitsspeicher 174 führt.
Nach einer erfolgreichen Anmeldung kann ein auf der Workstation 40 des Anwenders ausgeführtes Anwendungsprogramm eine Anforderung für A/V-Verarbeitungsbetriebsmittel und/oder für A/V-Datei-Managementdienste an den AVSM 160 ausgeben. Beim Empfang einer Anforderung baut der AVSM 160 eine Sitzung auf, indem er irgendwelche wie im Folgenden beschriebenen notwendigen Dateizugriffsberechtigungsoperationen ausführt, eine Sitzungszugriffsnummer erzeugt, die die Sitzung eindeutig identifiziert, die Sitzungszugriffsnummer zu der Liste momentan aktiver Sitzungen in dem AVSS-Zustandsarbeitsspeicher 174 hinzufügt, geeignete AVSC-Betriebsmittel identifiziert und zuordnet, geeignete AV-Netz-Betriebsmittel identifiziert und zuordnet und eine Sitzungskennungsnachricht an den anfordernden Client ausgibt, wobei die Sitzungskennungsnachricht eine Sitzungszugriffsnummer enthält. Nach dem Sitzungsaufbau managt der AVSM 160 die Sitzung, indem er direkt Operationen ausführt und/oder Anforderungen, Steuernachrichten und/oder Statusnachrichten an die AVSCs 120, an den A/V-Netz-Manager 34, an andere AVSMs 160 und/oder an das Anwendungsprogramm ausgibt oder leitet. Der AVSM 160 schließt die Sitzung ab, indem er die Zuweisung der Betriebsmittel aufhebt, eine Abschlussnachricht oder -antwort an das Anwendungsprogramm ausgibt und die Sitzungszugriffsnummer aus der Liste momentan aktiver Sitzungen löscht. Der AVSM 160 unterstützt wenigstens drei Typen von Sitzungen, d. h. 1) Betrachterhilfsmittelsitzungen, 2) Pflegehilfsmittelsitzungen und 3) Organisationshilfsmittelsitzungen. Die Eigenschaften jedes dieser Sitzungstypen sowie die von dem AVSM 160 zu seiner Unterstützung unternommenen Operationen werden im Folgenden ausführlich beschrieben.
4.7.1.1 Betrachterhilfsmittelsitzungen
Ein Betrachterhilfsmittel umfasst hier ein Anwendungsprogramm, das über eines oder mehrere Graphikfenster, Menüs sowie Steuer-, Dialog- oder andere Felder, die die Anwendereingabe ermöglichen, die A/V-Datei-Aufzeichnung sowie die analoge oder digitale Echtzeit-Streaming-A/V-Datei-Lieferung oder -Betrachtung steuert. Wenn eine Betrachterhilfsmittelanwendung, die auf einer Workstation 40 oder auf einem anderen Computer ausgeführt wird, eine Anforderung ausgibt, die angibt, dass entweder eine analoge oder eine digitale Echtzeit-(oder Nahezu-Echtzeit-)Streaming-Lieferung einer A/V- oder Multimedia-Datei erforderlich ist (d. h., wenn ein Anwender eine A/V-Datei betrachten muss), baut der AVSM 160 eine Betrachterhilfsmittelsitzung auf. Eine analoge oder digitale Echtzeit-Streaming-Lieferung ist z. B. während der A/V-Datei-Aufzeichnung, während des A/V-Datei-Editierens und/oder während der A/V-Datei-Wiedergabe erfor derlich und umfasst die A/V-Signal-Lieferung an eine Anzeigevorrichtung (wie etwa an einen Workstation-Monitor oder an ein Fernsehgerät) unter der Anweisung des Betrachterhilfsmittel-Anwendungsprogramms.
Um eine Betrachterhilfsmittelsitzung zu initiieren, ermittelt der AVSM 160, ob die von der Betrachterhilfsmittelanwendung empfangene Anforderung eine existierende A/V- oder Multimedia-Datei angibt. Wenn das der Fall ist, führt der AVSM 160 im Folgenden ausführlich beschriebene Dateizugriffsberechtigungsoperationen aus, um zu überprüfen, ob dem Betrachterhilfsmittelanwender Zugriff auf die Datei gewährt werden sollte. Wenn die Dateizugriffsberechtigungsoperationen erfolglos sind, gibt der AVSM 160 an die anfordernde Betrachterhilfsmittelanwendung eine Antwort aus, die angibt, dass keine richtige Zugriffsberechtigung existiert, wobei die Betrachterhilfsmittelsitzung endet.
Beim erfolgreichen Abschluss der Dateizugriffsberechtigungsoperationen erzeugt der AVSM 160 eine Sitzungszugriffsnummer und fügt sie zur Liste momentan aktiver Sitzungen hinzu. Nachfolgend identifiziert der AVSM 160 eine AVSC 120, die A/V-Verarbeitungsbetriebsmittel enthält, die die für die Betrachterhilfsmittelanwendung erforderlichen Operationen ausführen können. In einer Ausführungsform wird die AVSC-Auswahl in Übereinstimmung mit den im Folgenden ausführlich beschriebenen Betriebsmittelzuordnungsoperationen ausgeführt. Für die Erzeugung (d. h. Aufzeichnung) einer neuen A/V- oder Multimedia-Datei wählt der AVSM 160 eine AVSC 120 aus, in der ausreichend Speicherplatz und ein geeigneter Codierertyp existieren. Für die Wiedergabe oder für das Editieren einer existierenden A/V- oder Multimedia-Datei wählt der AVSM 160 eine AVSC 120 aus, in der eine Kopie der Datei liegt und geeignete Decodierungs- oder Transcodierungsbetriebsmittel vorhanden sind.
Nachdem eine geeignete AVSC 120 identifiziert worden ist, sendet der AVSM 160 an die AVSC 120 eine Anforderung zum Zuordnen der Betriebsmittel, die erforderlich sind, um die von dem Betrachterhilfsmittel-Anwendungsprogramm geforderte Operation bzw. die von ihm geforderten Operationen auszuführen. In einer Ausführungsform gibt der AVSM 160 nachfolgend an den AV-Netzmanager 34 eine Anforderung zum Aufbau irgendwelcher erforderlichen A/V-Netz-Verbindungen aus. In einer alternativen Ausführungsform gibt das Betrachter hilfsmittel-Anwendungsprogramm an den A/V-Netz-Manager 34 eine Anforderung zum Aufbau dieser Verbindungen aus. Nach der AVSC-Auswahl/Betriebsmittelzuordnung und dem A/V-Netz-Verbindungsaufbau gibt der AVSM 160 an die Betrachterhilfsmittelanwendung eine Sitzungskennungsnachricht aus, die die Sitzungszugriffsnummer enthält und angibt, dass die Betrachterhilfsmittelsitzung fortgeführt werden kann.
Während der Betrachterhilfsmittelsitzung leitet der AVSM 160 die von der Betrachterhilfsmittelanwendung empfangenen Steuernachrichten zu der gewählten AVSC 120 und ermöglicht dadurch die AVSC-Ausführung von Datei öffnen, Abspielen, Einstellen der Wiedergabegeschwindigkeit, Stopp, Suchen, Pause, Rücklauf, schneller Vorlauf, Aufzeichnen, Datei sichern oder anderen Operationen, wie sie durch das Betrachterhilfsmittel-Anwendungsprogramm unterstützt werden. Außerdem kann der AVSM 160 an die Betrachterhilfsmittelanwendung Statusnachrichten ausgeben, die Videoteilbildnummern und/oder die laufende oder verstrichene Zeit enthalten können. In einer Ausführungsform ruft der AVSM 160 die AVSC 120 wegen Statusinformationen ab und leitet sie an das Betrachterhilfsmittel-Anwendungsprogramm weiter.
Eine Multimedia-Datei umfasst einen oder mehrere Typen von Dateien und/oder Bezugnahmen auf Dateien, wobei diese Dateien Text-, Graphik-, Bild-, Audio- und/oder Videoinformationen sowie Befehle oder Ereignisfolgen zum Erzeugen oder Rendern dieser Informationen enthalten können. Ferner kann die Multimedia-Datei Zeitkorrelationsdaten enthalten, die eine oder mehrere Arten angeben, in denen ihre Bestandteildateien und/oder -dateibezugnahmen in der Zeit zugeordnet sind. Im Kontext der vorliegenden Erfindung umfasst eine Multimedia-Datei eine oder mehrere Omnidateien, wobei eine Omnidatei als eine Metadatei zuzüglich einer entsprechenden Zeigerdatei definiert ist. Die Metadatei enthält einen oder mehrere der folgenden Dateitypen:

1) A/V-Dateien;
2) reine Audiodateien;
3) reine Videodateien;
4) Bitmapdateien;
5) Postskript-Dateien;
6) Graphikdateien;
7) Textdateien;
8) Anwendungsdateien; und
9) Synchronisationsdateien.

Die Synchronisationsdateien ordnen Ereignissen oder Befehlen, die im Kontext eines oder mehrerer Anwendungsprogramme auftreten, besonderen Zeitbezugnahmen zu, die A/V-Datei-Teilbildnummern sein können. Wie im Folgenden weiter beschrieben wird, können Synchronisationsdateien Anwendungsstart-Ereignisdateien, Textereignisdateien, Fensterereignisdateien, Graphik-Rendering-Ereignisdateien und Shareboard-Ereignisdateien umfassen. In einer Ausführungsform kann eine Synchronisationsdatei für jeden darin angegebenen Befehl oder für jedes darin angegebene Ereignis ein Prioritätsniveau enthalten. Die verschiedenen Dateien, die die Metadatei umfasst, können über eine oder mehrere Workstations 40, AVSCs 120, Server oder andere mit der CMCE 10 gekoppelte Computer gespeichert sein. Die einer Metadatei zugeordnete Zeigerdatei enthält Zeiger oder Bezugnahmen auf jedes Element in der Metadatei.
In einer Ausführungsform werden die Synchronisationsdateien in AVSCs 120 gespeichert. Wenn die Betrachterhilfsmittelsitzung die Multimedia-Dateiaufzeichnung umfasst, überträgt der AVSM 160 Anwendungsprogramm-Synchronisationsinformationen oder -befehle, die von der Betrachterhilfsmittelanwendung empfangen werden, in der Weise an die AVSC 120, dass die Synchronisationsinformationen in einer Synchronisationsdatei gesichert werden können. Für die Multimedia-Datei-Wiedergabe und/oder für das Multimedia-Datei-Editieren fordert der AVSM 160 von der richtigen AVSC 120 die Synchronisationsdatei an. Um während der Wiedergabeoperationen die zeitliche Konsistenz sicherzustellen, ruft der AVSM 160 die zur Bedienung der momentanen Betrachterhilfsmittelsitzung zugeordnete AVSC 120 wegen der Teilbildnummer oder wegen zeitgestützten A/V-Datei-Daten ab und gibt zu den richtigen Zeiten oder in den richtigen In tervallen in Übereinstimmung mit einer momentan angegebenen Wiedergabe-Bildwiederholrate oder -geschwindigkeit Synchronisationsnachrichten an die Betrachterhilfsmittelanwendung aus. Die Synchronisationsnachrichten enthalten Ereignisinformationen, Befehle und Befehlsprioritätsebenen, die in der Synchronisationsdatei angegeben sind. Die Betrachterhilfsmittelanwendung führt beim Empfang einer Synchronisationsnachricht darin angegebene Befehle aus oder ermöglicht die Ausführung dieser Befehle über ihre Übertragung an andere Anwendungsprogramme und regeneriert dadurch zu den richtigen Zeiten, während die A/V-Datei-Wiedergabe stattfindet, Anwendungsereignisse und/oder die Darstellung von Text-, Graphik-, Bild- oder anderen Multimedia-Inhaltsinformationen.
Alternativ könnte der AVSM 160 die Synchronisationsdatei an die Betrachterhilfsmittelanwendung übertragen, die AVSC 120 wegen der Teilbildnummer oder zeitgestützter A/V-Datei-Daten abrufen und Teilbild- oder Zeitstatusnachrichten an das Betrachterhilfsmittel ausgeben. Die Betrachterhilfsmittelanwendung könnte daraufhin beim Empfang der Teilbild- oder Zeitstatusnachrichten, die Teilbildnummern oder Zeiten entsprechen, die in der Synchronisationsdatei angegeben sind, die richtigen Befehle zum Ermöglichen der Multimedia-Synchronisation ausführen oder ausgeben. In anderen Ausführungsformen könnten die Synchronisationsdateien selbst eher in dem AVSM 160 als in AVSCs 120 gespeichert sein oder könnten die Synchronisationsdateien normalerweise in der Anwender-Workstation 40 liegen.
In einer Ausführungsform führt der AVSM 160, wenn die Betrachterhilfsmittelsitzung das A/V-Datei- oder Multimedia-Datei-Editieren umfasst und die Dateieditierungen oder -änderungen gesichert wurden, während der Dateiname beibehalten wurde, Änderungsfortpflanzungsoperationen aus, wie sie im Folgenden ausführlich beschrieben werden, um sicherzustellen, dass sich die Dateiänderungen zu jeder Kopie der in den AVSCs 120 gespeicherten A/V-Datei fortpflanzen.
Die oben beschriebenen Operationen betreffen Betrachterhilfsmittelsitzungen innerhalb eines Standorts. Nicht-Standort-Betrachterhilfsmittelsitzungen finden auf analoge Weise statt. Wenn eine Betrachterhilfsmittelanwendung die analoge oder digitale Echtzeit/Nahezu-Echtzeit-Streaming-A/V-Datei-Lieferung von einem Nicht-Standort-AVSS 100 anfordert, gibt die Betrachterhilfsmittelanwen dung in einer Ausführungsform an den richtigen Nicht-Standort-AVSM 160 eine Anforderung aus. Der Nicht-Standort-AVSM 160 baut in Reaktion darauf in der oben beschriebenen Weise eine Betrachterhilfsmittelsitzung auf, sodass über die Standort-Workstation 40, über das Standort-Codec-Gateway 38, über das zweite WAN 39 und über das Nicht-Standort-Codec-Gateway 38, das dem Nicht-Standort-AVSS 100 dient, analoge A/V-Signale ausgetauscht werden.
Ein Betrachterhilfsmittel stellt für einen Workstation-Anwender eine graphische Anwenderschnittstelle (GUI) zum Steuern der A/V-Datei-Aufzeichnungs- und A/V-Datei-Wiedergabeoperationen bereit. 11 ist ein Blockdiagramm, das eine beispielhafte Aufzeichnungssteuerungs-GUI 500 zeigt. Die Aufzeichnungssteuerungs-GUI 500 umfasst ein Graphikfenster, das eine Menüleiste 502, ein Titelfeld 504, ein Aufzeichnungsbedienfeld 506 und ein Zeitfeld 520 enthält. Die Menüleiste 502 stellt für einen Workstation-Anwender Zugriff auf herkömmliche Untermenütypen einschließlich Datei-, Optionen- und Hilfe-Untermenüs bereit. Durch den Anwender wählbare Operationen aus dem Optionen-Untermenü enthalten Anmelde- und Kennwortänderungsoperationen. Durch den Anwender wählbare Operationen aus dem Datei-Untermenü enthalten die Folgenden:

1) Neu – öffnet in der im Folgenden beschriebenen Weise eine neue A/V-Datei für die Aufzeichnung;
2) Öffnen – ruft ein Browser-Hilfsmittel auf, das wie im Folgenden beschrieben das Öffnen und die nachfolgende Wiedergabe einer existierenden A/V-Datei ermöglicht;
2) Sichern – sichert eine A/V-Datei mit einem gegebenen Dateinamen;
3) Eigenschaften – ermöglicht die Eingabe und das Editieren von Eigenschaften, die einer A/V-Datei, die aufgezeichnet wird, zugeordnet sind wie etwa Codierungstyp und einem Titel in natürlicher Sprache; und
4) Beenden – schließt die Betrachterhilfsmittelsitzung ab.

Das Titelfeld 504 identifiziert den momentanen Titel einer betrachteten A/V-Datei. Das Aufzeichnungsbedienfeld 506 stellt eine Menge durch den Anwender wählbarer Schaltflächen zum Steuern von Aufzeichnungsoperationen bereit.
Diese Schaltflächen umfassen eine Aufzeichnungsstart-Schaltfläche 510, eine Aufzeichnungspause-Schaltfläche 512, eine Aufzeichnungsstopp- oder Aufzeichnungsende-Schaltfläche 514 und eine Schaltfläche 516 zum Löschen oder Verwerfen aufgezeichneter Informationen. Das Zeitfeld 520 gibt graphisch über die Bereitstellung eines Bildlaufbalkens 522 und eines Zeitfelds 524 eine momentane Aufzeichnungslänge oder -zeit an.
12 ist ein Blockdiagramm, das eine beispielhafte Wiedergabesteuerungs-GUI 600 zeigt. Zur Erleichterung des Verständnisses sind in den 11 und 12 gezeigte gemeinsame Elemente mit gemeinsamen Bezugszeichen bezeichnet. Die Wiedergabesteuerungs-GUI 600 umfasst ein Graphikfenster, das eine Menüleiste 502, ein Titelfeld 504, ein Wiedergabebedienfeld 606 und ein Zeitfeld 520 enthält. Die Menüleiste 502 ermöglicht, dass der Anwender aus den oben anhand von 11 beschriebenen Operationen auswählt. Ähnlich gibt das Titelfeld 504 den momentanen Titel der betrachteten A/V-Datei an. Das Wiedergabebedienfeld 606 enthält mehrere durch den Anwender wählbare Schaltflächen, die Wiedergabesteueroperationen ermöglichen, einschließlich einer Schaltfläche 610 zum Rücklauf zum Beginn, einer Zurückspringen-Schaltfläche 612, die das Zurückbewegen oder -springen zu einer früheren Stelle in einer A/V-Datei ermöglicht, wobei die frühere Stelle einem vorgegebenen oder durch den Anwender definierbaren Zeitinkrement, z. B. 3 Sekunden, entspricht, einer Wiedergabestart-Schaltfläche 614, einer Wiedergabepause-Schaltfläche 616, einer Vorwärtsspringen-Schaltfläche 618, die das Rückwärtsbewegen oder -springen zu einer späteren Stelle in einer A/V-Datei ermöglicht, wobei die spätere Stelle einem vorgegebenen oder durch den Anwender definierbaren Zeitinkrement, z. B. 3 Sekunden, entspricht, und einer Datei-Löschen-Schaltfläche 619. Das Zeitfeld 520 gibt auf analoge Weise zu dem für die Aufzeichnungssteuerungs-GUI 500 über die Bereitstellung eines Bildlaufbalkens 522 und eines Zeitfelds 524 graphisch eine momentane Wiedergabelänge oder -zeit an. Der Fachmann auf dem Gebiet versteht, dass die Aufzeichnungs- und Wiedergabesteuerungs-GUIs 500, 600 für die Workstation-Anwender eine graphische Schnittstelle bereitstellen, die visuell mit den Steuerungen vereinbar ist, die an üblichen Vorrichtungen wie etwa Videokassettenrekordern (VCRs) zu finden sind.
Das Betrachterhilfsmittel überträgt in Reaktion auf bestimmte Untermenüauswahlen wie etwa Öffnen innerhalb des Dateiuntermenüs die Steuerung an ein Browsing- oder Organisationshilfsmittel oder ruft Funktionalität innerhalb dessen oder die ihm zugeordnet ist auf, um für einen Workstation-Anwender eine GUI für das Browsen und Auswählen von A/V-Dateien und/oder für das Ausführen von A/V-Datei-Organisationsoperationen, wie sie im Folgenden ausführlich beschrieben werden, bereitzustellen. 13 ist ein Blockdiagramm, das eine beispielhafte Browsing-Steuerungs-GUI 700 zeigt. Die Browsing-Steuerungs-GUI 700 umfasst ein Dialogfeld, das ein Dateiquellen-Auswahllistenfenster 702 und Dateiquellen-Steuerschaltflächen 704, Anzeigeformatsteuerungs-Schaltflächen 706, ein Dateiinformations-Auswahllistenfenster 710, ein Dateinamenfenster 722, ein Dateityp-Auswahllistenfenster 724 und Betriebssteuerungs-Schaltflächen 730, 732, 734 umfasst. Das Dateiquellen-Auswahllistenfenster 702 und die zugeordneten Dateiquellensteuerungs-Schaltflächen 704 ermöglichen die Anwenderidentifizierung einer Dateiquelle, aus der A/V-Dateien zur Betrachtung gewählt werden können. Die Anzeigeformatsteuerungs-Schaltflächen 706 ermöglichen die Anwenderauswahl von Dateiinformations-Anzeigeformaten, wobei die verfügbaren Anzeigeformate Anzeige durch Icon und Anzeige durch Attribute enthalten. Für jede A/V-Datei, für die der Workstation-Anwender als ein Eigentümer identifiziert ist, zeigt das Dateiinformations-Auswahllistenfenster 710 in Übereinstimmung mit dem gewählten Dateiparameteranzeigeformat Dateiinformationen an. Diese Informationen können einen Dateinamen, einen Dateiort, einen Titel in natürlicher Sprache, eine Beschreibung, die Dateiautorschaft und die Wiedergabedauer enthalten. Das Dateinamenfeld 722 ermöglicht die Anwendereingabe eines spezifischen Dateinamens und das Dateityp-Auswahllistenfenster 724 ermöglicht Browsing-Operationen, die auf Dateien eines spezifischen Typs gerichtet sind. Schließlich enthalten die Betriebssteuerungs-Schaltflächen eine Öffnen-Schaltfläche 730, deren Auswahl zum Öffnen einer angegebenen oder gewählten A/V-Datei für Wiedergabeoperationen führt, eine Abbrechen-Schaltfläche 732 und eine Hilfe-Schaltfläche 734.
4.7.2 Pflegehilfsmittelsitzungen
In Reaktion auf eine Anforderung, die angibt, dass eine oder mehrere anwendergeschützte Dateipflegeoperationen erforderlich sind, baut der AVSM 160 eine Pflegehilfsmittelsitzung auf. Im Kontext der vorliegenden Erfindung umfasst ein Pflegehilfsmittel ein Anwendungsprogramm, das in einer Anwender-Workstation 40 oder in einem anderen Computer ausgeführt wird und das in Reaktion auf eine Anwendereingabe eines oder mehrerer graphische Fenster, Menüs und/oder Felder erzeugt, die bestimmte A/V-Datei-Pflegeoperationen ermöglichen. In einer Ausführungsform kann die Anwendereingabe die Form von Text, Graphikauswahlen oder graphischen Ziehen- und Ablegen-Folgen haben.
Wie im Folgenden ausführlich beschrieben wird, unterstützt der AVSM 160 viele Dateimanagementoperationen, von denen eine Teilmenge Dateipflegeoperationen umfasst, die direkt für Workstation-Anwender verfügbar sind. In einer Ausführungsform umfassen die Dateipflegeoperationen die Dateizugriffslistenpflege, die Dateiablaufdatumpflege, die Dateiumbenennung, die Dateiübertragung entweder in Form von Kopieren oder in Form von Verschieben, die Dateilöschung, die anwenderspezifische Dateiauflistung, anwenderspezifische Archivierungsoperationen und Dateiattributabfragen. Jede dieser Operationen wird im Folgenden ausführlich im Kontext von AVSM-Dateimanagementoperationen beschrieben. Der Fachmann auf dem Gebiet erkennt, dass die Dateipflegeoperationen in einer anderen Ausführungsform zusätzliche oder weniger Typen von Operationen enthalten könnten.
Der AVSM 160 initiiert eine Pflegehilfsmittelsitzung dadurch, dass er wie im Folgenden ausführlich beschriebene A/V-Datei-Zugriffsberechtigungsoperationen ausführt. Wenn die Zugriffsberechtigung erfolglos ist, schließt der AVSM 160 die Sitzung ab. Andernfalls erzeugt der AVSM 160 eine Sitzungszugriffsnummer, fügt sie zur Liste momentan aktiver Sitzungen hinzu und gibt eine Sitzungskennungsnachricht an die Pflegehilfsmittelanwendung aus. Der AVSM 160 ermittelt, ob für die Verarbeitung der Dateipflegeanforderung der Zugriff auf einen oder mehrere Campus- und/oder entfernte AVSMs 160 erforderlich ist, und gibt Anforderungen zum Zuordnen der erforderlichen Campus- und/oder entfernten Betriebsmittel aus, wenn das der Fall ist. Wenn diese Betriebsmittel zugeordnet worden sind, geben die Campus- und/oder entfernten AVSMs 160 nach Bedarf an den Standort-AVSM 160 eine Antwort aus, die AVSC-Netzadresseninformationen angibt. Nachfolgend ermittelt der AVSM 160, welche Standort-AVSCs 120 für die Verarbeitung der Dateipflegeanforderung erforderlich sind, und gibt an die Standort-AVSCs 120 Anforderungen zum Zuweisen der richtigen Betriebsmittel und zum Beginnen der Ausführung der geforderten Operation aus.
Während der Ausführung von Dateipflegeoperationen gibt der AVSM 160 Statusanforderungen an die Standort- und/oder Nicht-Standort-AVSCs 120 aus, die mit Statusinformationen antworten. Daraufhin sendet der AVSM 160 dementsprechend Statusnachrichten an die Dateipflegehilfsmittelanwendung. Diese Statusnachrichten können z. B. einen Prozentsatz der Operation, der abgeschlossen worden ist, oder eine geschätzte bis zum Abschluss verbleibende Zeitdauer angeben. Wenn die Dateipflegeoperation abgeschlossen ist, gibt der AVSM 160 an das Pflegehilfsmittel eine Sitzungsabschlussantwort aus.
Einige Dateipflegeoperationen wie etwa eine A/V-Datei-Umbenennung oder ein A/V-Datei-Kopieren können im Kontext einer Betrachterhilfsmittelsitzung angefordert werden. Das heißt, in einem Betrachtungshilfsmittel können einer oder mehrere Aspekte der Pflegehilfsmittelfunktionalität enthalten sein. In diesen Situationen führt der AVSM 160 die Leistung der Dateipflegeoperation im Kontext der Betrachterhilfsmittelsitzung im Wesentlichen in gleicher oder analoger Weise aus, wie es für die Dateipflegehilfsmittelsitzung beschrieben worden ist, oder überwacht sie auf diese Weise. Darüber hinaus kann ein Pflegehilfsmittel in einer Ausführungsform den Aufruf eines bestimmten Betrachterhilfsmittels in Reaktion auf eine Anwendereingabe sicherstellen, wobei der AVSM 160 in diesem Fall im Ergebnis eine Betrachterhilfsmittelsitzung aufbaut.
4.7.3 Organisationshilfsmittelsitzungen
Ein Organisationshilfsmittel umfasst hier ein Anwendungsprogramm, das in Reaktion auf eine Anwendereingabe auf einer workstationgestützten oder auf einer anderen Anzeigevorrichtung Organisationsinformationen erzeugt, darstellt und/oder managt. Der AVSM 160 baut in Reaktion auf eine Anforderung von für den Anwender zugänglichen Informationen, die in der AVSS-Datenbank gespeichert sind, eine Organisationshilfsmittelsitzung auf. Diese Informationen können z. B. Anwenderkonto- und Anwenderkennwortinformationen oder bestimmte Daten in der Ereignisstatistikdatei enthalten.
Beim Empfang einer Organisationsinformationsanforderung erzeugt der AVSM 160 eine Sitzungszugriffsnummer und fügt sie zur Liste momentan aktiver Sitzungen hinzu. Daraufhin überträgt der AVSM 160 an das Organisationshilfsmittel der Anforderung entsprechende Daten. Das Organisationshilfsmittel erzeugt beim Empfang der Daten für den Anwender Organisationsinformationen und/oder stellt sie für den Anwender dar. Wenn die Organisationsdaten durch den Anwender änderbar sind, wie es für Anwenderkennwörter der Fall sein könnte, ändert der AVSM 160 in Reaktion auf eine von dem Organisationshilfsmittel empfangene Anforderung die Daten in der AVSS-Datenbank. Einige Organisationsdaten wie etwa die momentane AVSS-Nutzung, die AVSS-Nutzungshistorie für den Anwender, die die durchschnittliche Sitzungslänge nach dem Sitzungstyp enthalten kann, und/oder momentane dem Anwender in Rechnung gestellte Gebühren können nicht durch den Anwender änderbar sein.
4.7.4 Dateimanagementdienste
Wie oben angegeben wurde, sichert der AVSM 160 die Bereitstellung einer Vielzahl von Dateimanagementdiensten oder überwacht sie. Eine Teilmenge der Dateimanagementdienste umfasst die für den Anwender zugänglichen Dateipflegeoperationen, während andere Dateimanagementdienste durch den AVSM 160 auf einer rein internen Grundlage ausgeführt werden. In einer Ausführungsform enthalten die Dateimanagementdienste die Folgenden:
4.7.4.1 Zugriffsberechtigungsdienste
AVSM-Softwareobjekte unterhalten die Zugriffsrechteliste innerhalb der Parametertabelle jeder A/V-Datei in der AVSS-Datenbank. Die Zugriffsrechteliste umfasst eine Liste von Anwender-IDs, die angibt, "Eigentum" welcher Anwender die A/V-Datei ist, wobei das Eigentum grundlegende Zugriffsrechte auf die A/V-Datei bedeutet. Wie im Folgenden ausführlich beschrieben wird, kann der Umfang der A/V-Datei-Zugriffsrechte davon abhängen, ob ein Anwender wie etwa der Autor der A/V-Datei in einer bestimmten Kategorie oder in einer anderen Kategorie liegt. In einer Ausführungsform enthält eine durch ein Clientanwendungsprogramm erzeugte A/V-Datei-Zugriffsanforderung eine Anwender-ID, einen Dateinamen und ein Kennwort. Der AVSM 160 ermittelt beim Empfang einer solchen Anforderung, ob die der Anforderung zugeordnete Anwender-ID innerhalb der Zugriffsrechteliste der A/V-Datei angegeben ist. Wenn das der Fall ist, fährt der AVSM 160 mit der Verarbeitung der Dateizugriffsanforderung fort. Wenn die Anwender-ID in der Zugriffsrechteliste nicht angegeben ist, vergleicht der AVSM 160 das in der A/V-Datei-Zugriffsanforderung angegebene Kennwort mit dem in der Dateiparametertabelle. Wenn die Kennwörter übereinstimmen, fügt der AVSM 160 die Anwender-ID zu der Zugriffsrechteliste hinzu und fährt mit den Anforderungsverarbeitungsoperationen fort. Andernfalls gibt der AVSM 160 an das Clientanwendungsprogramm eine Antwort aus, die einen Fehlercode enthält, um anzugeben, dass der A/V-Datei-Zugriff abgelehnt worden ist.
In einer Ausführungsform gibt die Anwesenheit einer reservierten Anwender-ID in dem Zugriffsrecht einer A/V-Datei an, dass durch irgendeinen Anwender auf die Datei zugegriffen werden kann, d. h., dass die Datei allgemein oder öffentlich zugänglich ist. Eine Ausführungsform der vorliegenden Erfindung stellt außerdem einen "bevorzugten" Organisations-"Anwender" bereit, der dadurch definiert ist, dass er im Wesentlichen unbeschränkte Zugriffsrechte für irgendeine A/V-Datei besitzt. In Reaktion auf eine von einem dem bevorzugten Anwender zugeordneten Anwendungsprogramm empfangene Anforderung für einen A/V-Datei-Zugriff fährt der AVSM 160 mit den Anforderungsverarbeitungsoperationen fort.
4.7.4.2 Zugriffslistenpflege
In Reaktion auf eine von einem Clientanwendungsprogramm empfangene Zugriffslisten-Pflegeanforderung fügt der AVSM 160 wahlweise Anwender-IDs zur Zugriffsberechtigungsliste einer A/V-Datei hinzu oder löscht Anwender-IDs aus ihr. In Abhängigkeit davon, ob ein Anwender der A/V-Datei-Autor, ein Eigentümer oder ein bevorzugter Anwender ist, führt der AVSM 160 Zugriffslisten-Pflegeoperationen nur für Anwender mit einer in der Zugriffsrechteliste angegebenen Anwender-ID aus. Der AVSM 160 Isst zu, dass ein A/V-Datei-Autor oder ein bevorzugter Anwender die Zugriffsrechteliste nach Bedarf ändert. Der AVSM 160 Isst zu, dass irgendein gegebener A/V-Datei-Eigentümer, der nicht der Autor der Datei ist, seine Anwender-ID aus der Zugriffsberechtigungsliste entfernt.
In einer Ausführungsform fügt der AVSM 160 die Anwender-ID eines Anwenders, der Autor einer A/V-Datei ist, standardmäßig zur Zugriffsberechtigungsliste der A/V-Datei hinzu. In Reaktion auf Clientanwendungsprogrammanforderungen kann der AVSM 160 weitere Anwender-IDs zu der Zugriffsberechtigungsliste hinzufügen. Zum Beispiel ermöglicht ein A/V- oder Multimedia-fähiges E-Mail-Anwendungsprogramm, wie es im Folgenden ausführlich beschrieben wird, dass Nachrichtenautoren eine A/V- oder Multimedia-Datei als einen MIME-gestützten Nachrichtenanhang aufnehmen. Der AVSM 160 fügt die jedem Nachrichtenempfänger entsprechende Anwender-ID, wie durch das E-Mail-Anwendungsprogramm angewiesen wird, zu der Zugriffsberechtigungsliste der A/V-Datei hinzu. Außerdem oder alternativ kann der AVSM 160 die Anwender-ID eines Nachrichtenempfängers in Reaktion auf eine A/V-Datei-Zugriffsanforderung, die eine Anwender-ID, einen Dateinamen und ein gültiges Kennwort angibt, zu der Zugriffsberechtigungsliste hinzufügen.
4.7.4.3 Anwenderspezifische Dateiauflistung
Ein Anwendungsprogramm, das einem Anwender zugeordnet ist oder in seinem Namen ausgeführt wird, kann an den AVSM 160 eine Dateiauflistungsanforderung ausgeben. Der AVSM 160 führt seinerseits eine Verzeichnungssortieroperation aus und antwortet auf das Anwendungsprogramm mit einer Liste, die jede A/V-Datei identifiziert, für die der Anwender in der Zugriffsberechtigungsliste der Datei als ein Eigentümer angegeben ist. In einer alternativen Ausführungsform, in der der AVSM 160 wie oben beschrieben in der AVSS-Datenbank eine anwenderspezifische Dateiliste unterhält, könnte der AVSM 160 an das Anwendungsprogramm mit Daten aus der anwenderspezifischen Dateiliste antworten.
Nachfolgend kann das Anwendungsprogramm eine Menge von Dateinamen anzeigen, für die der Anwender als ein Eigentümer angegeben ist. In einer Ausführungsform kann die Dateiauflistungsanforderung angeben, dass ebenfalls Daten für öffentlich verfügbare Dateien erforderlich sind. Wenn das der Fall ist, stellt der AVSM 160 diese Daten für das anfordernde Anwendungsprogramm bereit.
4.7.4.4 Anwenderspezifische Dateiarchivierung
Außerdem kann ein Anwendungsprogramm eine Dateiarchivierungsanforderung an den AVSM 160 ausgeben, wobei die Dateiarchivierungsanforderung eine oder mehrere A/V-Dateien identifiziert, die Eigentum des Anwenders sind, der dem anfordernden Anwendungsprogramm zugeordnet ist, für das die Archivierungsoperationen angefordert werden. Nachfolgend managt der AVSM 160 Archivierungsoperationen, in denen die identifizierten A/V-Dateien oder Kopien davon in einem Anwender-ID-gestützten Standort- oder Nicht-Standort-Archiv gespeichert werden. Die Archivierungsoperationen enthalten einen oder mehrere wie im Folgenden beschriebene Dateiübertragungsdienste.
4.7.4.5 Attributabfrage
In Reaktion auf eine von einem Eigentümer einer A/V-Datei empfangene Attributanforderung stellt der AVSM 160 für die A/V-Datei Attributinformationen wie etwa den Dateiautor, die Dateigröße, den Dateicodierungstyp, die Dateiwiedergabedauer, das momentane Dateialter, die Zeit und das Datum, zu denen der Eigentümer das letzte Mal auf die Datei zugegriffen hat, das Dateiablaufdatum (d. h. das Zugriffsablaufdatum) für den Anwender und/oder das Datum der letzten Änderung bereit.
4.7.4.6 Dateiübertragungsdienste
Dateiübertragungsdienste, die durch den AVSM 160 unterstützt werden, enthalten: a) A/V-Datei-Kopier- und/oder Verschiebungsoperationen (d. h. Verlagerungsoperationen) zu und/oder von einem Zielbestimmungsort oder einer Zielquelle, b) Dateiimportoperationen oder -exportoperationen zwischen einer Workstation 40 oder einem anderen Computer und einer AVSC 120 und c) digitale Dateiveröffentlichungsoperationen zwischen einer AVSC 120 und einem Server, der gegenüber dem AVSS 100, in dem die AVSC 120 liegt, extern ist. Hinsichtlich der A/V-Datei-Kopieroperationen oder -Verschiebungsoperationen kann der Zielbestimmungsort oder die Zielquelle standort-, campus- oder weitverkehrsgestützt sein. Da irgendein gegebenes AVSS 100 über ein LAN oder über ein WAN mit einem weiteren AVSS 100 verknüpft sein kann, sind im Kontext der vorliegenden Erfindung sowohl Intra- als auch Inter-AVSS-Dateiübertragungen möglich. 14 ist ein Blockschaltplan einer beispielhaften vernetzten AVSS-Organisation. In einer beispielhaften vernetzten AVSS-Organisation dienen ein erstes AVSS 100.1 bis ein k-tes AVSS 100.2 als ein gemeinsamer Campus und sind somit mit einem gemeinsamen Datennetz 20 gekoppelt. Ein entferntes AVSS 100.3 ist über ein WAN 29 mit dem gemeinsamen Datennetz 20 gekoppelt. Der Fachmann auf dem Gebiet erkennt, dass die in 14 gezeigte beispielhafte vernetzte AVSS-Organisation verallgemeinert werden kann, um sie im Wesentlichen an irgendeine erforderliche Netzorganisation oder geographische Skalierung anzupassen.
In 14 enthält jedes AVSS 100 eine Menge von AVSCs 120, wobei jede AVSC 120 eine Anzahl von Plattenlaufwerken oder anderen Vorrichtungen zum Speichern von A/V-Dateien enthält. Die Anzahl der AVSCs 120 kann ebenso von einem AVSS 100 zu einem anderen variieren wie die Anzahl und der Typ der Speichervorrichtungen von einer AVSC 120 zu einer anderen variieren können. In Bezug auf Intra-AVSS-Dateiübertragungen können A/V-Dateien entweder a) innerhalb derselben AVSC 120, d. h. "innerhalb der Zelle" (WC) oder b) über verschiedene AVSCs 120 in demselben AVSS 100 oder "von Zelle zu Zelle" (CC) von einer Speichervorrichtung zu einer anderen übertragen werden. Hinsichtlich A/V-Datei-Übertragungen, die von einer AVSC-Speichervorrichtung in einem AVSS 100 zu einer AVSC-Speichervorrichtung in einem anderen AVSS 100 gerichtet sind, können diese Übertragungen entweder a) innerhalb des gemeinsamen Campus oder lokalen Bereichs (LA) oder b) auf einer Weitverkehrsgrundlage (WA-Grundlage) zwischen einem gemeinsamen Campus AVSS 100 und dem entfernten AVSS 100 stattfinden.
Der AVSM 160 wählt in Reaktion auf eine Anforderung, die eine A/V-Datei-Übertragung von Zelle zu Zelle oder innerhalb einer Zelle erfordert, eine Quell- und eine Bestimmungsstandort-AVSC 120 aus und ordnet sie zu und gibt an den einen der gewählten AVSCs 120 eine Anforderung zum Ausführen der geforderten Übertragung aus. In einer Ausführungsform kann die Anforderung eine Kopieren-von-, Verschieben-von-, Kopieren-zu- oder Verschieben-zu-Operation angeben. Nachdem die Dateiübertragung abgeschlossen ist, gibt die AVSC 120, die die Anforderung erfüllt hat, an den AVSM 160 eine Antwort 160 aus.
Wenn eine Dateiübertragungsanforderung eine A/V-Datei-Übertragung zwischen einem Standort- und einem Nicht-Standort-AVSS 100 anfordert, gibt der Standort-AVSM 160 an den Nicht-Standort-AVSM 160 eine Anforderung aus, um Netzadresseninformationen für eine zugeordnete Nicht-Standort-AVSC 120 zu erhalten, die sich an der Erfüllung der Anforderung beteiligen kann. Der Standort-AVSM 160 wählt beim Empfang dieser Informationen von dem Nicht-Standort-AVSM 160 eine geeignete Standort-AVSC 120 aus und ordnet sie zu und gibt an die Standort-AVSC 120 eine Anforderung zur Ausführung der geforderten Dateiübertragungsoperation aus. Wenn die Dateiübertragungsanforderung eine Kopieren-zu- oder Verschieben-zu-Operation angibt, wird die A/V-Datei dementsprechend von der Standort-AVSC 120 zu der Nicht-Standort-AVSC 120 übertragen. Wenn die Dateiübertragungsanforderung eine Kopieren-von- oder Verschieben-von-Operation angibt, wird die A/V-Datei dementsprechend von der Nicht-Standort-AVSC 120 zu der Standort-AVSC 120 kopiert bzw. verschoben. Nachdem die Dateiübertragung abgeschlossen ist, gibt die Standort-AVSC 120 eine Antwort an den Standort-AVSM 160 aus. Daraufhin gibt der Standort-AVSM 160 an den Nicht-Standort-AVSM 160 eine Meldung aus, um anzugeben, dass die Dateiübertragungssitzung abgeschlossen ist.
Außerdem zeigt 14 eine Workstation 40, die mit dem gemeinsamen Datennetz 20 gekoppelt ist. Dateiimportoperationen umfassen die Übertragung einer digitalen Datei von einer Workstation 40 oder von einem anderen Computer zu einer AVSC 120, während Dateiexportoperationen die Übertragung einer digitalen Datei von einer AVSC 120 zu einer Workstation 40 oder zu einem anderen Computer umfassen. Der AVSM 160 wählt in Reaktion auf eine von einem Clientanwendungsprogramm empfangene Dateiimportanforderung eine verfügbare AVSC 120 mit ausreichend Speicherplatz aus und ordnet sie zu und gibt an die AVSC 120 eine Anforderung zum Abrufen der Datei von der Workstation 40 oder vom anderen Computer, von dem die Importanforderung ausgegangen ist, aus. Ähnlich wählt der AVSM 160 in Reaktion auf eine Dateiexportanforderung, die eine A/V-Datei angibt, eine AVSC 120 aus, in der eine Kopie der Datei liegt, und ordnet sie zu und gibt eine Anforderung zum Übertragen der Datei an die Workstation 40 oder an den anderen Computer, von dem die Exportanforderung ausgegangen ist, an die AVSC 120 aus. Beim Abschluss der einer Import- oder/und Export-Anforderung entsprechenden Dateiübertragungsoperationen gibt die AVSC 120 an den AVSM 160 eine Antwort aus.
Dateiveröffentlichungsoperationen umfassen die Übertragung einer digitalen Datei von einer AVSC 120 zu einem Server. Der Server kann im Wesentlichen irgendein Computersystem, das gegenüber dem AVSS 120, in dem die AVSC 120 liegt, extern ist, z. B. ein Intranet-Serversystem 60 oder ein mit dem Internet 80 gekoppelter Server, sein. 14 zeigt außerdem ein Intranet-Serversystem 60, das mit dem gemeinsamen Datennetz 20 gekoppelt ist. In Reaktion auf eine Dateiveröffentlichungsanforderung, die einen Dateinamen, ein Zieldateiformat und eine Netz- oder IP-Adresse eines Servers angibt, wählt der AVSM 160 eine AVSC 120, in der eine Kopie der Datei liegt, aus und ordnet sie zu. Daraufhin gibt der AVSM 160 eine Veröffentlichungsanforderung an die AVSC 120 aus, die irgendeine notwendige Dateiformatkonvertierung ausführt, und überträgt die Datei an den angegebenen Server. Beim Abschluss der Übertragung gibt die AVSC 120 an den AVSM 160 eine Antwort aus.
Im Allgemeinen kann eine AVSC 120 direkt sowohl A/V-Datei-Codierungs-, A/V-Datei-Decodierungs und/oder A/V-Datei-Transcodierungsoperationen als auch Dateiübertragungsoperationen ausführen. Irgendeine bestimmte AVSC 120 hat eine maximale Anzahl gleichzeitig aktiver Dateiübertragungen, die sie ausführen kann, während sie weiter eine hochwertige Codierungs-, Decodierungs- oder Transcodierungsleistung liefert. Somit müssen Dateiübertragungsanforderungen gegenüber Codierungs-, Decodierungs- und/oder Transcodierungsanforderungen im Gleichgewicht gehalten werden. Üblicherweise erhalten Codierungs-, Decodierungs- und/oder Transcodierungsoperationen eine höhere Priorität als Dateiübertragungsoperationen. In einer Ausführungsform ermöglicht ein Organisationsanwendungsprogramm das Definieren einer AVSC-Bus- und -Plattenbandbreitenpartition erster Priorität und einer zweiter Priorität. Die Bandbreitenpartition erster Priorität wird für die Ausführung von Codierungs/Decodierungs/Transcodierungs-Operationen reserviert, während die Partition zweiter Priorität für Dateiübertragungsoperationen reserviert wird. Während einer AVSC 120 Dateiübertragungsanforderungen zugeordnet werden, bedient sie sie unter Verwendung der Bandbreite in der Partition zweiter Priorität sofort. Wenn die AVSC 120 eine Dateiübertragungsanforderung empfängt, die sie nicht sofort bedienen kann, ordnet die AVSC 120 die Anforderung in der Anforderungswarteschlange in ihrem Zustandsarbeitsspeicher 154 an. Anforderungen in dieser War teschlange werden bedient, während mehr Bandbreite innerhalb der Partition zweiter Priorität verfügbar wird. In einer Ausführungsform ist die Anforderungswarteschlange auf herkömmliche Weise als eine Zuerst-Eingeben/Zuerst-Ausgeben-Warteschlange (FIFO-Warteschlange) implementiert. Alternativ könnte die Anforderungswarteschlange als eine priorisierte Warteschlange und/oder als eine Warteschlange, von der Anforderungen in Übereinstimmung mit der momentanen Betriebsmittelverfügbarkeit bedient werden, implementiert sein. Alternativ könnten Anforderungen, die nicht sofort bedient werden können, abgeschlossen werden, wobei eine Antwort zurückgesendet wird, die angibt, dass momentan keine Betriebsmittel verfügbar sind, wodurch zugelassen wird, dass der AVSM 160 und/oder die Clientanwendung ein anderes Mittel zur Bedienung der Anforderung suchen.
4.7.4.7 Dateireplikation
Um sicherzustellen, dass zu irgendeiner gegebenen Zeit auf die Datei durch eine recht große Anzahl von Anwendern unabhängig zugegriffen werden kann, sollte eine A/V-Datei auf mehreren AVSCs 120 vorhanden sein. Somit initiiert der AVSM 160 nach einer A/V-Datei-Erzeugung (d. h., nachdem eine neue A/V-Datei erzeugt und gesichert worden ist) oder nach der Übertragung einer neuen A/V-Datei in eine der Standort-AVSCs 120 die Replikationsoperationen. Während der Dateireplikationsoperationen werden in mehreren Standort-AVSCs 120 Kopien der A/V-Datei gespeichert. In einer Ausführungsform werden Kopien zugeordneter Multimedia-Synchronisationsdateien ebenfalls repliziert.
Die bestimmte Dateireplikationsstrategie, die zu irgendeiner gegebenen Zeit genutzt wird, hängt von mehreren Faktoren einschließlich der Anzahl der vorhandenen Standort-AVSCs 120, von den Leistungsfähigkeiten jeder AVSC 120, von der AVSS-internen Netzbandbreite und/oder von dem momentanen Anwenderbedarf für AVSC-Betriebsmittel ab. In einem AVSS 100, das eine einzelne AVSC 120 nutzt, braucht die Dateireplikation nicht ausgeführt zu werden oder kann zwischen getrennten Speichervorrichtungen in der AVSC 120 eine beschränkte Dateireplikation stattfinden. Für ein AVSS mit einer kleinen Anzahl von AVSCs 120 – z. B. mit drei AVSCs 120, die näherungsweise 100 Anwendern dienen – kann eine vollständige Replikation ausgeführt werden. In diesem Fall über wacht der AVSM 160 automatisch das Kopieren einer neuen A/V-Datei zu jeder AVSC 120 in dem AVSS 100. Für Zelle-Zelle-Dateiübertragungsoperationen werden die Kopieroperationen in der oben beschriebenen Weise ausgeführt. Im Allgemeinen wird die A/V-Datei in Abwesenheit einer Anwendungsebenenanforderung, dies zu tun, nicht zu einer Nicht-Standort-AVSC 120 repliziert.
Je nach den Leistungsfähigkeiten jeder AVSC 120 sowie der Anzahl vorhandener Standort-AVSCs kann eine vollständige Replikation die AVSC-Verfügbarkeit für die Ausführung anderer Operationen wesentlich beschränken. Somit managt der AVSM 160 für ein AVSS 100, das ein Medium zu einer etwas großen Anzahl von Standort-AVSCs 120 nutzt – wobei z. B. fünf AVSCs 120 wenige einhundert bis mehrere einhundert Anwender bedienen – Teildateireplikationsoperationen. Während der Teildateireplikationsoperationen überwacht der AVSM 160 das A/V-Datei-Kopieren zu einer Teilmenge der Standort-AVSCs 120, wobei die Kopieroperationen in der oben für die Zelle-Zelle-Dateiübertragung beschriebenen Weise ausgeführt werden. Die A/V-Datei wird nur dann allgemein zu einer Nicht-Standort-AVSC repliziert, wenn ein Anwendungsprogramm eine Anforderung ausgibt, die diese Replikation anfordert. Die Auswahl einer bestimmten AVSC 120 als ein Element der oben erwähnten Teilmenge kann auf der Anzahl der A/V-Dateien, auf dem verfügbaren Speicherplatz oder auf der Anzahl der in der AVSC 120 liegenden Decodierer und Transcoder beruhen.
Während die Anzahl der Standort-AVSCs 120 innerhalb des AVSS 100 sehr groß wird, wird die Teilreplikation an einem Punkt unhaltbar. In diesen Situationen werden eine Teilmenge der AVSCs 120 als Streaming-A/V-Datei-Server genutzt, während die anderen AVSCs als Aufbereitungspunkte für Codierungs-, Decodierungs- und/oder Transcodierungsoperationen wirken. In einer Ausführungsform managt der AVSM 160 Dateireplikationsoperationen für die Streaming-A/V-Datei-Server auf analoge Weise wie oben beschrieben.
4.7.4.8 Dateiumbenennung
In Reaktion auf eine Namensänderungsanforderung ändert der AVSM 160 den Namen einer A/V-Datei wie in der entsprechenden Dateiparametertabelle angegeben und überwacht nachfolgend, wie im Folgenden beschrieben wird, Änderungsfortpflanzungsoperationen, um den Namen jeder Kopie der über die Standort-AVSCs 120 gespeicherten A/V-Datei zu ändern. In einer Ausführungsform lässt der AVSM 160 eine Namensänderung nur dann zu, wenn sie von einem einem bevorzugten Anwender entsprechenden Anwendungsprogramm angefordert wird. Ferner kann der AVSM 160 eine Namensänderungsanforderung für den Autor der A/V-Datei zulassen, wenn der Autor momentan der einzige A/V-Datei-Eigentümer ist.
4.7.4.9 Dateilöschung
In Reaktion auf eine Dateilöschungsanforderung weist der AVSM 160 durch Ausgabe einer Löschanforderung an jede AVSC 120, in der eine Kopie der A/V-Datei liegt, die Löschung jeder Kopie der A/V-Datei von den Standort-AVSCs 120 an. In einer Ausführungsform lässt der AVSM 160 die Löschung nur dann zu, wenn sie von einem einem bevorzugten Anwender zugeordneten Anwendungsprogramm angefordert wird. Ferner kann der AVSM 160 die A/V-Datei-Löschung durch den Autor der A/V-Datei zulassen, wenn der Autor momentan der einzige A/V-Datei-Eigentümer ist. In einer Ausführungsform löscht der AVSM 160 außerdem irgendwelche Multimedia-Synchronisationsdateien, die der gelöschten A/V-Datei zugeordnet sind, oder überwacht ihre Löschung. Außerdem kann der AVSM 160 Löschanforderungen an den Nicht-Standort-AVSM 160 und an die Server 60 und 80, an die er die A/V-Datei übertragen hat, ausgeben.
4.7.4.10 Änderungsfortpflanzung
Wie zuvor angemerkt wurde, können in den Standort-AVSCs 120 mehrere Kopien irgendeiner gegebenen A/V-Datei liegen. Der AVSM 160 kann zulassen, dass ein gegebener Anwender wie etwa ein bevorzugter Anwender oder der Autor einer A/V-Datei den Namen oder den Inhalt der Datei nach ihrer Erzeugung editiert oder ändert. Jede Standortkopie der A/V-Datei muss aktualisiert werden, um diese Änderung zu widerspiegeln. Somit gibt der AVSM 160 in einer Ausführungsform nach einer A/V-Datei-Namenänderung oder -Inhaltsänderung an die AVSC 120, in der die geänderte Datei liegt, eine Folge von Kopieren-zu-Anforderungen aus, um die Namen- und Inhaltskonsistenz zwischen den in den AVSCs 120 gespeicherten A/V-Datei-Kopien sicherzustellen. In einer alternativen Ausführungs form könnte der AVSM 160 Kopieren-von-Anforderungen ausgeben. Außerdem kann der AVSM 160 Dateiänderungsanforderungen zum Nicht-Standort-AVSM 160 und zu Servern 60 und 80, zu denen er die A/V-Datei übertragen hat, ausgeben.
4.7.4.11 Ablaufoperationen
Die Zugriffsrechteliste einer A/V-Datei enthält für jede Anwender-ID ein Ablaufdatum und/oder eine Ablaufzeit, nach denen die Anwender-ID abläuft und nicht mehr gültig ist, um einen Dateizugriff zu erlangen. Der AVSM 160 ermittelt für jede A/V-Datei-Parametertabelle in der AVSS-Datenbank, ob irgendwelche in der Zugriffsrechteliste angegebenen Anwender-IDs abgelaufen sind. Wenn das der Fall ist, entfernt der AVSM 160 die abgelaufenen Anwender-IDs aus der Zugriffsrechteliste. Wenn keine nicht abgelaufenen Anwender-IDs in der Zugriffsrechteliste verbleiben, gibt der AVSM 160 an jede AVSC 120, in der eine Kopie der A/V-Datei liegt, eine Dateilöschanforderung aus. Nachdem jede solche AVSC 120 die A/V-Datei gelöscht hat, löscht der AVSM 160 die A/V-Datei-Parametertabelle aus der AVSS-Datenbank. Alternativ kann der AVSM 160 abgelaufene Dateien protokollieren und die Löschung durch ein einem bevorzugten Anwender zugeordnetes Anwendungsprogramm anfordern.
4.7.4.12 Datenbankkonsistenzoperationen
Der AVSM 160 führt periodisch Konsistenzprüfungen aus, um sicherzustellen, dass die Dateiparametertabellen innerhalb der AVSS-Datenbank 136 die momentane Standort-AVSC-Dateiumgebung richtig widerspiegeln. In einer Ausführungsform fragt der AVSM 160 periodisch jede Standort-AVSC 120 ab, um für jede darin gespeicherte A/V-Datei Daten zu erhalten, wobei diese Daten den Namen, die Größe, das Alter, das Codierungsformat, den Speicherort oder die Speicheradresse oder andere Informationen einer A/V-Datei enthalten können. Wenn eine AVSC 120 einen Dateinamen zurückgibt, der nicht in der AVSS-Datenbank angegeben ist, erzeugt der AVSM 160 eine dem Dateinamen entsprechende Dateiparametertabelle und fügt sie zu der AVSS-Datenbank hinzu. Wenn keine AVSC 120 einen bestimmten in der AVSS-Datenbank angegebenen Dateinamen zurückgibt, löscht der AVSM 160 die entsprechende Dateiparametertabelle aus der AVSS-Datenbank. Wenn die durch eine AVSC 120 zurückgegebenen Dateidaten eine Diskrepanz der Dateigröße, des Dateialters, des Dateicodierungsformats oder anderer Informationen angeben, kann der AVSM 160 die AVSS-Datenbank dementsprechend aktualisieren. Außerdem kann der AVSM 160 irgendwelche Diskrepanzen sowie den Typ der in Reaktion auf jede Diskrepanz ergriffenen Maßnahmen) protokollieren. Schließlich aktualisiert der AVSM 160, wenn eine bestimmte AVSC 120 einen in der AVSS-Datenbank angegebenen Dateinamen zurückgibt, für den die Dateiparametertabelle aber angibt, dass die Datei nicht in dieser AVSC 120 gespeichert ist, die Dateiparametertabelle mit dem Speicherort der A/V-Datei in der besagten AVSC 120.
4.7.5 Vorrichtungsmanagementdienste
Außerdem führt der AVSM 160 Vorrichtungsmanagementdienste aus, die AVSC-Planungs- und AVSC-Zuweisungsdienste enthalten. Die AVSS-Betriebsmittelplanung und -zuweisung unterliegt mehreren Einschränkungen:
Beschränkungen zusammenwirkender Betriebsmittel, die die Folgenden enthalten:

1. AVSM-Multithread-Betriebsmittel (d. h. gleichzeitige Verwendung durch mehrere Sitzungen):
a. CPU-Kapazität:
i. Codierungssitzungsmanagement
ii. Decodierungssitzungsmanagement
iii. Dateiübertragungssitzungsmanagement
b. Buskapazität
c. Netzportkapazität
2. AVSC-Multithread-Betriebsmittel (d. h. gleichzeitige Verwendung durch mehrere Sitzungen):
a. CPU-Kapazität:
i. Codierungssitzungsmanagement
ii. Decodierungssitzungsmanagement
iii. Dateiübertragungssitzungsmanagement
iv. Datenstrom-Sitzungsmanagement
v. Audio-Video-Datenstrom-Multiplexierungsprozesse
vi. Audio-Video-Datenstrom-Demultiplexierungsprozesse
vii. Codierungssitzungsprozesse
viii. Decodierungssitzungsprozesse
ix. Dateiübertragungsprozesse
x. Datenstrom-Sendeprozesse
xi. Datenstrom-Empfangsprozesse
b. Buskapazität
c. Plattensteuerungs/Plattenbus-Kapazität (z. B. SCSI-Kapazität)
d. Platten-Lese/Schreib/Such-Kapazität
e. Netzportkapazität
3. AVSC-Singlethread-Betriebsmittel (d. h. solche, die zu einem Zeitpunkt nur durch eine Sitzung verwendet werden können:
a. Codiererhardware und entsprechende Codierungssitzung(en)
b. Decodiererhardware und entsprechende Decodierungssitzung(en)

Irgendein Sitzungstyp besitzt eine spezifische Anzahl spezifischer Betriebsmittel, die zur Ausführung der Sitzung erforderlich sind. Einige Ausführungs formen können Dienstanforderungen ohne Berücksichtigung von Einzelheiten der momentanen Nutzung der Betriebsmittel gewähren; allerdings kann dies zur Unternutzung der Betriebsmittel oder zu inakzeptablen Leistungsnachteilen oder zu Störungsbetriebsarten führen, wenn die Betriebsartfähigkeiten überschritten werden. Eine Ausführungsform stützt die Anforderungsakzeptanz auf die Notwendigkeiten der Anforderung angesichts der verfügbaren ungenutzten Kapazität des Systems. Im Folgenden wird ein Beispiel beschrieben, wie dies erreicht werden kann.
In einigen Fällen können die Betriebsmittelanforderungen genau sein. In anderen Fällen können die Betriebsmittelanforderungen die Form von oberen Schranken, von geschätzten Mittelwerten oder von Mittelwerten, die nach oben vorgepolt sind, um Sicherheitsspannen sicherzustellen, haben. Diese Sitzungstyp-Betriebsmittelnutzungsschätzwerte können eine zusätzliche "Auffüllung" enthalten oder nicht enthalten, um einen Verarbeitungsorganisationsaufwand (Aufgabenumschaltung, Seitenwechsel usw.) zuzulassen. In Anwesenheit der Auffüllung kann in den Sitzungstyp-Betriebsmittelnutzungsschätzwerten ein Organisationsaufwand durch Folgendes vorgesehen werden:

• Verringern des Maximalwerts verfügbarer Betriebsmittel auf einen Wert, der den bei voller Betriebskapazität für den ungünstigsten Fall zugezogenen Organisationsaufwand sicher berücksichtigt, oder
• Einführung einer spezifischen linearen oder nichtlinearen Organisationsaufwandfunktion, die von der Anzahl verschiedener Sitzungen abhängt, die in dem AVSS 100 aktiv oder geplant sind.

Einige der Betriebsmittelnutzungsschätzwerte könnten fest festgesetzte Werte sein, z. B.:

• jede "Codierungs"-Sitzung könnte so entworfen sein, dass sie ein vollständig dediziertes Codiererhardware-Teilsystem erfordert;
• jede "Codierungs"-Sitzung könnte so entworfen sein, dass sie einen feststehenden Block des Plattenspeichers (wobei die Größe von der Anwendung abhängt) zuordnet, wobei Versuche, darüber hinaus aufzuzeichnen, verhindert werden; oder
• jede "Decodierungs"-Sitzung besitzt Kenntnis über die genaue Dateigröße.
Allerdings kann es wahrscheinlicher sein, dass die Betriebsmittelnutzungsschätzwerte nicht fest wären, z. B.:
• alle aktiven Codierungssitzungen könnten einen etwas kleineren Pool von Codierern gemeinsam nutzen;
• alle Codierungssitzungsanforderungen könnten mit Durchschnitten behandelt werden, wobei Versuche, darüber hinaus aufzuzeichnen, zulässig wären.

Um ein Beispiel des Betriebsmittelzuordnungsprozesses weiter zu veranschaulichen, liefert die folgende Tabelle ein Beispielsystem für Betriebsmittelanforderungen für mehrere verschiedene Typen von Sitzungen. Natürlich können weitere Ausführungsformen andere Sitzungstypen und Betriebsmittelanforderungen haben.
Jeder Betriebsmitteltyp oder jede Betriebsmittelgruppe hat einen endlichen maximalen Leistungswert, der durch die Umgebungen des AVSM 160 oder der AVSC 120 in dem AVSS 100 bereitgestellt werden kann.
Dieser endliche Maximalwert wird als eine "Kapazitätsschranke" bezeichnet.

M^MAX _SM: = maximale Kapazität des AVSM-CPU-Sitzungsmanagements
M^MAX _B: = maximale Kapazität des AVSM-Busses
M^MAX _N: = maximale Kapazität des AVSM-Netzports
C^MAX _SM: = maximale Kapazität des AVSC-CPU-Sitzungsmanagements
C^MAX _P: = maximale Kapazität des AVSC-CPU-Prozesses
C^MAX _B: = maximale Kapazität des AVSC-Busses
C^MAX _DC: = maximale Kapazität der AVSC-Plattensteuerung/des AVSC-Plattenbusses
C^MAX _RW: = maximale Kapazität des AVSC-Platten-Lesens/Schreibens/Suchens
C^MAX _N: = maximale Kapazität des AVSC-Netzports
C^MAX _EH: = maximale Kapazität der AVSC-Codiererhardware
C^MAX _DH: = maximale Kapazität der AVSC-Decodiererhardware

Die Menge der für eine potentielle Kombination gewährter Sitzungen erforderlichen Betriebsmittel wird in vielen Fällen durch die Summe der insgesamt zugewiesenen Betriebsmittelschätzwerte bestimmt. Ein Organisationsaufwand kann z. B. über die Aufnahme mehrerer Organisationsaufwandkonstanten enthalten sein, die die Folgenden enthalten:

M^OH _SM: = AVSM-CPU-Sitzungsmanagement-Organisationsaufwand
M^OH _B: = AVSM-Bus-Organisationsaufwand
M^OH _N: = AVSM-Netzport-Organisationsaufwand
C^OH _SM: = AVSC-CPU-Sitzungsmanagement-Organisationsaufwand
C^OH _P: = AVSC-CPU-Prozess-Organisationsaufwand
O^OH _B: = AVSC-Bus-Organisationsaufwand
C^OH _DC: = AVSC-Plattensteuerungs/AVSC-Plattenbus-Organisationsaufwand
C^OH _RW: = AVSC-Platten-Lese/Schreib/Such-Organisationsaufwand
C^OH _N: = AVSC-Netzport-Organisationsaufwand

Der Organisationsaufwand kann ebenfalls als eine lineare Funktion der Anzahl verschiedener Sitzungstypen behandelt werden. Die Aufnahme des Organisationsaufwands führt zu den unterstützbaren Betriebszuständen, die ein Gitter von Punkten in einer konvexen Hülle bilden, die durch den Schnittpunkt der in den Betriebsmittelkapazitätsschranken-Ungleichungen definierten Hyperebenen definiert sind. Zum Beispiel sind mit:

n^E: = Anzahl der Codierungssitzungen
n^D: = Anzahl der Decodierungssitzungen
n^PF: = Anzahl der Dateiablege-Übertragungssitzungen
n^GF: = Anzahl der Dateihol-Übertragungssitzungen
n^SS: = Anzahl der Streaming-Sendesitzungen
n^RS: = Anzahl der Streaming-Empfangssitzungen

160

100

• AVSM-CPU-Kapazität (Sitzungsmanagement)
• AVSM-Bus-Kapazität:
• AVSM-Netzportkapazität:

Für jede AVSC 120 (wenigstens eine, üblicherweise mehrere, pro AVSS 100):

• AVSC-CPU-Kapazität (Sitzungsmanagement):
• AVSC-CPU-Prozesskapazität:
• AVSC-Bus-Kapazität:
• AVSC-Plattensteuerungs/Plattenbus-Kapazität:
• AVSC-Platten-Lese/Schreib/Such-Kapazität:
• AVSC-Netzportkapazität:
• AVSC-Hardware:

Hier ist angenommen worden, dass jede Codierungssitzung entweder mit einer festen oder mit einer durchschnittlichen Menge an Plattenkapazität repräsentiert ist. Je nach den Entwurfswahlen kann eine Ausführungsform eine Dateigrößengrenze pro Sitzung erzwingen, während eine weitere Ausführungsform Dateigrößenüberläufe zulassen kann.
Zum Beispiel würde der AVSM 160 beim Empfang einer oder mehrerer Anforderungen für Dienste die folgenden Bewertungen ausführen:

• Serialisieren irgendwelcher mehrerer anstehender Anforderungen, sodass die folgenden Bewertungen für jede anstehende Anforderung vollständig getrennt nacheinander ausgeführt werden;
• Prüfen, ob die Akzeptanz der neuen Anforderung nicht die eigenen Kapazitätsanforderungen des AVSM überschreiten würde;
• Prüfen aller AVSCs 120 innerhalb dieses AVSS 100, um zu sehen, ob wenigstens eine AVSC 120 die neue Anforderung annehmen könnte, ohne die eigenen Kapazitätsanforderungen des AVSM zu überschreiten (dies könnte entweder über das eigene Bild des AVSM der AVSC-Zustände oder durch Abrufen wenigstens einer AVSC 120 erfolgen).
• Wenn mehr als eine AVSC 120 die Anforderung unterstützen kann:
• Auswählen einer gemäß einer herkömmlichen Prozedur wie etwa der ersten verfügbaren, Round Robin oder Betriebslebensdauer;
• Zuordnen der Sitzung zu der AVSC 120, was die direkte oder indirekte Benachrichtigung der anfordernden Anwendung und den Aufruf geeigneter Netzverbindungen sicherstellt; oder
• andernfalls Ablehnen der Anforderung.

Selbstverständlich gibt es viele weitere mögliche Implementierungen. Der Bereich möglicher Implementierungen könnte ebenfalls Verfahren enthalten, um sicherzustellen, dass kein einzelner Anwendungstyp oder Sitzungstyp das AVSS 100 unter Ausschluss anderer Anwendungs- oder Sitzungstypen monopolisiert. In dem vorigen veranschaulichenden Beispiel könnte dies dadurch ausgeführt werden, dass zu der obigen Liste weitere Ungleichungen hinzugefügt werden. Zum Beispiel könnte die Gesamtzahl der Übertragungssitzungen durch Addieren der Konstante nPF + nGF ≤ nF:MAX begrenzt werden, wobei n^F ^: ^MAX die maximale Anzahl gleichzeitig zulässiger Dateiübertragungen ist.
Außerdem enthalten die Vorrichtungsmanagementdienste AVSC-Überprüfungsoperationen, durch die der AVSM 160 jede AVSC 120 abfragt, um die Anzahl, den Typ und die Fähigkeiten der Speicherungs-, Codierungs-, Decodierungs- und Transcodierungsbetriebsmittel der AVSC zu ermitteln. Der AVSM 160 verwendet die Abfrageergebnisse, um die AVSS-Datenbank nach Bedarf zu aktualisieren, und protokolliert ferner irgendwelche Diskrepanzen sowie die Typen der in Reaktion darauf unternommenen Operationen.
4.7.6 Organisationsdienste
Außerdem führt der AVSM 160 Organisationsdiensten aus, die die Systemleistungs- und Systemnutzungsüberwachung, die Systemdiagnose, Ereigniserfassungsoperationen, Rechnungsstellungsoperationen, Kennwortpflegeoperationen und Anwenderpflegeoperationen enthalten, oder managt ihre Ausführung.
4.8 Softwarearchitektur und Systemschnittstelle
4.8.1 Kommunikationsklassenhierarchie
In der vorliegenden Erfindung sind die Arten, in denen AVSS-externe und AVSS-interne Clients auf AVSM-, AVSC- und A/V-Netz-Manager-Funktionalität zugreifen können, durch eine Menge von Software-Kommunikationsklassenhierarchien definiert. 15 ist ein Blockdiagramm, das eine AVSS-Kommunikationsklassenhierarchie 200 hoher Ebene für eine Ausführungsform der vorliegenden Erfindung zeigt. Wie in 15 gezeigt ist, wird die Grundklasse für diese Hierarchie als "Comm" bezeichnet, wobei sie als Grundlage für die AVSS-externe und AVSS-interne Clientkommunikation dient. Außerdem dient die Comm-Klasse als Grundlage für die externe und für die interne A/V-Netz-Manager-Client-Kommunikation, wobei sie ausführlich im US-Patent Nr. 5.617.539 beschrieben ist.
Mehrere aus der Comm-Klasse abgeleitete Unterklassen kapseln bestimmte Aspekte der AVSS-Funktionalität für den AVSS-externen und für den AVSS-internen Clientzugriff. Diese Unterklassen enthalten die Folgenden:

1) AvnmComm – die AvnmComm-Klasse stellt einen Zugriff auf Funktionalität, die durch ihre Elternklasse unterstützt wird, sowie einen Clientzugriff auf A/V-Netz-Manager-Dienste bereit.
1) AvsComm – die AvsComm-Klasse stellt einen Zugriff auf AVSS-Funktionalität bereit, die die Anmeldeberechtigung, A/V-Codierung, -Decodierung und -Transcodierung, die Dateiübertragung zwischen den AVSCs 120, den Dateiimport und -export, das Datei- und Verzeichnismanagement und die AVSC-Konfiguration und -Statusberichterstattung enthält.
2) AvscComm – die AvscComm-Klasse stellt Zugriff auf die durch ihre Elternklasse unterstützte Funktionalität bereit und stellt außerdem Client- und Serverzugriff auf zusätzliche AVSC-bezogene Dienste, wie sie im Folgenden ausführlich beschrieben werden, bereit.
3) AvscAppComm – die AvscAppComm-Klasse stellt eine Clientschnittstelle für den Zugriff auf Dateiimport- und Dateiexportdienste bereit.
4) AvsmComm – die AvsmComm-Klasse stellt Zugriff auf die durch ihre Elternklasse unterstützte Funktionalität bereit und stellt außerdem einen Client- und Serverzugriff auf die oben beschriebenen AVSM-Datei- und AVSM-Vorrichtungsmanagementdienste bereit.
5) AvsmAppComm – die AvsmAppComm-Klasse stellt Ereignisbehandlungsroutinen bereit, die den Clientanwendungsprogrammzugriff auf AVSS-Dienste unterstützen.
6) AvsmAdminComm – die AvsmAdminComm-Klasse stellt AVSS-externe und AVSS-interne Clientzugriffe auf die AVSS-Organisationsfunktionalität bereit.

4.8.2 AVSM-Klassen-Beziehung
Die Klassen der in dem AVSM-Objektarbeitsspeicher 172 residenten AVSM-Objekte haben eine hierarchische Klassenbeziehung. 16 ist ein Blockdiagramm einer AVSM-Klassen-Beziehung 250, die in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung organisiert ist. Die AVSM-Manager-Klasse umfasst eine Containerklasse zur Unterstützung der Sitzungsaufbau-, Sitzungsmanagement- und Sitzungsabschlussoperationen. Ferner enthält die AVSM-Manager-Klasse Parameter und Methoden zum Ermöglichen des AVSM-Betriebs, d. h. zur Implementierung des AVSM 160. Außerdem enthält die AVSM-Manager-Klasse Parameter, die AVSS-Betriebseigenschaften wie etwa AVSC-Sitzungsgrenzen zuzüglich Port- und Verbindungsinformationen für Standort-AVSCs 120, für den A/V-Netz-Manager 34 und für bekannte Nicht-Standort-AVSSs 100 angeben. In einer Ausführungsform enthält die AVSM-Manager-Klasse Methoden, die die Kommunikation zwischen den Klassen unterer Ebene mit der AVSM-Klassenhierarchie 250 ermöglichen.
Eine AVSMComm-Klasse stellt eine Softwareinfrastruktur zur Implementierung einer Serverschnittstelle bereit, die Client-Wechselwirkungen managt, wobei die Clients Anwenderanwendungsprogramme und/oder ein Nicht-Standort-AVSS 100 umfassen. Außerdem stellt die AVSMComm-Klasse eine Grundlage bereit, die ermöglicht, dass sich der AVSM 160 in Bezug auf Nicht-Standort-AVSSs 100 als ein Client verhält. Die AVSMComm-Klasse umfasst Methoden zum Abrufen von Anforderungen, zum Aufbauen von Objekten, die gemäß dem Anforderungstyp unterteilt sind, und zum Absenden von Anforderungen. Ferner umfasst die AVSMComm-Klasse Methoden zum Empfangen von Antworten, zum Aufbauen von Objekten, die gemäß dem Antworttyp unterteilt sind, und zum Ausgeben von Antworten. Die AVSMComm-Klasse enthält eine Bezugnahme auf eine AVSM-Anforderungslistenklasse und auf eine AVSM-Antwortlistenklasse.
Die AVSM-Anforderungslistenklasse ermöglicht die Implementierung einer Warteschlange für von AVSS-externen Clients empfangene Anforderungen sowie einer Warteschlange für zu Nicht-Standort-AVSSs 100 gerichtete Anforderungen. Die AVSMRequestList-Klasse umfasst eine Bezugnahme auf eine AVSM-Anforderungsklasse, die Anforderungsparameter sowie Methoden zum Zugreifen auf einer Anforderung zugeordnete Daten umfasst. In einer Ausführungsform ist die AVSMRequest-Klasse gemäß dem Anforderungstyp unterteilt. Somit kann eine Anforderungswarteschlange eine erste Bezugnahme auf ein AVSMOpenRequest-Objekt, das einer von einem Client empfangenen A/V-Datei-Öffnen-Anforderung entspricht, und eine zweite Bezugnahme auf ein AVSMPlayRequest-Objekt, das einer von einem Client empfangenen A/V-Datei-Wiedergabeanforderung entspricht, enthalten.
Die AVSMReplyList-Klasse ermöglicht die Implementierung einer Warteschlange für von dem AVSM 160 zu externen Clients gerichtete Antworten sowie einer Warteschlange für von Nicht-Standort-AVSSs 100 empfangene Antworten. Die AVSMReplyList-Klasse umfasst eine Bezugnahme auf eine AVSMReply-Klasse, wobei die AVSMReply-Klasse Antwortparameter umfasst, sowie eine Menge von Methoden zum Zugreifen auf einer Antwort zugeordnete Daten. Die AVSMReply-Klasse kann auf analoge Weise wie die AVSMRequest-Klasse in Übereinstimmung mit dem Antworttyp unterteilt sein.
Eine AVNMComm-Klasse stellt eine Softwareinfrastruktur zur Implementierung einer A/V-Netz-Clientschnittstelle bereit, die Parameter und Methoden zum Ausgeben von Anforderungen zu und zum Empfangen von Antworten von dem A/V-Netz-Manager 34 enthält. Die AVNMComm-Klasse enthält eine Bezugnahme auf eine AVNMRequestList-Klasse und auf eine AVNMReplyList-Klasse. Die AVNMRequestList-Klasse ermöglicht die Implementierung einer Warteschlange für zu dem A/V-Netz-Manager 34 gerichtete Anforderungen und umfasst eine Bezugnahme auf eine AVNMRequest-Klasse. Die AVNMRequest-Klasse enthält Parameter, die einer zu dem A/V-Netz-Manager 34 gerichteten Anforderung entsprechen, sowie Methoden zum Zugreifen auf die der Anforderung zugeordneten Daten. Die AVNMRequest-Klasse kann in Übereinstimmung mit dem Typ der zu dem A/V-Netz 30 gerichteten Anforderung unterteilt sein. Die AVNMReplyList-Klasse ermöglicht die Implementierung einer Warteschlange für von den A/V-Netz-Manager 34 empfangene Antworten und enthält eine Bezugnahme auf eine AVNMReply-Klasse. Die AVNMReply-Klasse umfasst den von dem A/V-Netz-Manager 34 empfangenen Antworten zugeordnete Parameter sowie Methoden zum Zugreifen auf irgendwelche ihnen zugeordnete Daten. Die AVNMReply-Klasse kann in Übereinstimmung mit den Typen der Antworten, die von dem A/V-Netz-Manager 34 empfangen werden können, unterteilt sein.
Eine AVSCComm-Klasse umfasst eine Softwareinfrastruktur zur Implementierung einer AVSC-Clientschnittstelle und umfasst Parameter und Methoden zum Ausgeben von Anforderungen zu und zum Empfangen von Antworten von AVSCs 120. Die AVSCComm-Klasse enthält eine Bezugnahme auf eine AVSC-RequestList-Klasse, die die Implementierung einer Warteschlange für zu den AVSCs 120 gerichtete Anforderungen vereinfacht. Die AVSCRequestList-Klasse enthält eine Bezugnahme auf eine AVSCRequest-Klasse, die Parameter und Methoden zum Erzeugen von zu einer AVSC 120 gerichteten Anforderungen enthält und die in Übereinstimmung mit den Typen der Anforderungen, die zu AVSCs 120 gerichtet werden können, unterteilt sein kann. Außerdem enthält die AVSC-Comm-Klasse eine Bezugnahme auf eine AVSCReplyList-Klasse, die die Implementierung einer Warteschlange für von AVSCs 120 empfangene Antworten vereinfacht. Die AVSCReplyList-Klasse enthält eine Bezugnahme auf eine AVSC-Reply-Klasse, die Parameter und Methoden umfasst, die dem Empfang von AVSC-Antworten zugeordnet sind. Die AVSCReply-Klasse kann in Übereinstimmung mit AVSC-Antworttypen unterteilt sein.
Eine CellList-Klasse dient als Grundlage für eine Liste, die jede Standort-AVSC 120 beschreibt. Die CellList enthält eine Bezugnahme auf eine Cell-Klasse, die eine Grundlage für die Beschreibung einer AVSC 120 bereitstellt. Die Cell-Klasse enthält Parameter, die eine Netzadresse, Bandbreitenfähigkeiten und eine Anzahl gleichzeitiger Anforderungen, die die AVSC 120 verarbeiten kann, angeben. Ferner enthält die Cell-Klasse Bezugnahmen auf eine ListDisks-Klasse, auf eine ListEncoders-Klasse, auf eine ListDecoders-Klasse und auf eine ListTranscoders-Klasse.
Die ListDisks-Klasse ermöglicht die Erzeugung einer Liste, die auf eine Disk-Klasse Bezug nimmt, die eine AVSC-Speichervorrichtungsbeschreibung unterstützt. Die Disk-Klasse enthält Parameter, die solche Informationen wie die Vorrichtungsübertragungsrate, die Suchzeit und den verfügbaren Speicherplatz enthalten. Außerdem enthält die Disk-Klasse Methoden zum Zugreifen auf und zum Ändern solcher Parameter.
Die ListEncoders-Klasse ermöglicht die Implementierung einer Liste, die auf eine Encoder-Klasse Bezug nimmt, die eine AVSC-Codierer-Beschreibung unterstützt. Die Encoder-Klassen-Parameter enthalten solche Informationen wie den Codierertyp, Bandbreiten- und E/A-Beschränkungen, unterstützte Medienformate und Eingangssignaleigenschaften. Außerdem enthält die Encoder-Klasse Methoden zum Zugreifen auf und zum Ändern dieser Parameter.
Die ListDecoders-Klasse ermöglicht die Implementierung einer Liste, die auf eine Decoder-Klasse Bezug nimmt, die eine AVSC-Decodierer-Beschreibung unterstützt. Die Decoder-Klassen-Parameter enthalten solche Informationen wie den Decodierertyp, Bandbreiten- und E/A-Beschränkungen, unterstützte Medienformate und Ausgangssignaleigenschaften. Außerdem enthält die Decoder-Klasse Methoden zum Zugreifen auf und zum Ändern der Decoder-Klassen-Parameter.
Die ListTranscoders-Klasse ermöglicht die Implementierung einer Liste, die auf eine Transcoder-Klasse Bezug nimmt, die eine AVSC-Transcoder-Beschreibung unterstützt. Transcoder-Klassen-Parameter enthalten solche Informationen wie den Transcodertyp, Bandbreiten- und E/A-Beschränkungen, unterstützte Medienformate und Eingangs/Ausgangs-Signaleigenschaften. Außerdem enthält die Transcoder-Klasse Methoden zum Zugreifen auf und zum Ändern der Transcoder-Klassen-Parameter.
Eine LoginList-Klasse stellt eine Implementierungsgrundlage für eine Liste bereit, die momentan angemeldete Anwender beschreibt. Die LoginList-Klasse nimmt auf eine Login-Klasse Bezug, die über Parameter, die eine Anwender-ID, eine Rechteebene, ein Anmeldedatum und einen Zeitstempel sowie eine Menge der Anwender-ID momentan zugeordneter Kanalzugriffsnummern enthält, wobei jede Kanalzugriffsnummer den AVSC-Betriebsmitteln entspricht, die wie im Folgenden ausführlicher beschrieben Anwenderverarbeitungsanforderungen zugeordnet sind, eine Anwenderbeschreibung unterstützt.
Eine SessionList-Klasse dient als Grundlage für eine Liste, die momentan aktive Sitzungen beschreibt. Die SessionList-Klasse nimmt auf eine Session-Klasse Bezug, die eine Grundlage für die Beschreibung irgendeiner bestimmten Sitzung bereitstellt. Die Session-Klasse ist gemäß dem Sitzungstyp unterteilt, wobei die Unterklassen die Klassen CopySession, PublishSession, ImportSession, ExportSession, AVSession, FileSession und ListSession enthalten.
Die CopySession-Klasse stellt ein System für die Beschreibung und Verfolgung einer Dateikopieroperation zwischen zwei AVSCs 120 bereit. Die Copy-Session-Klasse enthält Parameter wie etwa IP- oder Netzadressen für die betroffenen AVSCs 120, einen Quell- und einen Bestimmungsdateinamen und Kanalzugriffsnummern, die Betriebsmitteln entsprechen, die in den AVSCs 120 für die Ausführung der Dateikopieroperation reserviert worden sind. In einer Ausführungsform enthalten die CopySession-Klassenparameter außerdem einen Merker, der angibt, ob eine Kopieroperation oder eine Übertragungsoperation erforderlich ist, wobei die Übertragungsoperation das Dateikopieren, gefolgt vom Löschen der Datei aus der ursprünglichen AVSC 120, umfasst. Ferner enthält die CopySession-Klasse Methoden zum Zugreifen auf ihre Parameter.
Die PublishSession-Klasse umfasst Parameter und Methoden, die A/V- und/oder Multimedia-Dokumentveröffentlichungsoperationen, durch die A/V- und/oder Multimedia-Dateien zu Nicht-AVSS-Servern kopiert werden können, beschreiben und überwachen. Die PublishSession-Klassenparameter enthalten IP- oder Netzadressen zuzüglich Anmeldedaten für einen Ziel- oder Bestimmungsserver sowie einen Dateinamen. Die PublishSession-Klassenmethoden enthalten Datenkonvertierungs- und Datenübertragungsmethoden. Die Publish-Session-Klasse kann in Übereinstimmung mit bestimmten Medienformaten unterteilt sein, wobei jede Unterklasse Parameter wie etwa einen Bestimmungsserver typ und Transcodierungsanforderungen enthält. Beispielhafte Unterklassen enthalten eine NetShowPublish-Klasse und eine RealMediaPublish-Klasse.
Die ImportSession-Klasse umfasst Parameter und Methoden, die das Lesen der A/V-Datei-Daten von einer Quell-Clientanwendung (oder von einer Quell-Workstation 40 oder von einem anderen Computer, in dem die Clientanwendung ausgeführt wird) in eine Ziel-AVSC 120 beschreiben und überwachen, und enthält Parameter, die die IP- oder Netzadresse und eine AVSC-Kanalzugriffsnummer der Ziel-AVSC angeben. Die ExportSession-Klasse stellt eine Grundlage für das Schreiben von A/V-Datei-Daten von der AVSC 120 in ein Ziel-Client-Anwendungsprogramm (oder in eine Ziel-Workstation 40 oder in einen anderen Computer, in dem das Clientanwendungsprogramm läuft) bereit und enthält Parameter, die die IP- oder Netzadresse der Quell-AVSC und eine AVSC-Kanalzugriffsnummer angeben.
Die AVSession-Klasse umfasst Parameter und Methoden zum Initiieren und Managen von A/V-Operationen, die Aufzeichnungs-, Abspiel-, Hereinstream-, Herausstream-, Pause-, Fortsetzen-, Status- und Stoppoperationen enthalten können.
Die FileSession-Klasse umfasst Parameter und Methoden, die das Schreiben von Daten zu und das Lesen von Daten von einer AVSC 120 ermöglichen. Die ListSession-Klasse umfasst Parameter und Methoden, die die Erzeugung einer Liste ermöglichen, die Dateien und Dateiattribute angibt, die in einer oder in mehreren AVSCs 120 gespeichert sind.
Eine AVMFileList-Klasse stellt eine Grundlage zur Implementierung der AVSM-Parameterliste in der AVSS-Datenbank bereit. Die AVMFileList enthält eine Bezugnahme auf eine AVMFile-Klasse, die Parameter, die eine A/V-Datei beschreiben, wie etwa einen Dateinamen, einen Dateiautor oder einen Dateiersteller, einen Dateititel und eine Dateibeschreibung, eine Dateigröße, einen Codierungstyp und die Wiedergabedauer, enthält. Ferner enthält die AVMFile-Klasse eine Bezugnahme auf eine OwnerList-Klasse, die wiederum auf einer Owner-Klasse Bezug nimmt. Die Owner-Klasse stellt eine Grundlage für die Beschreibung eines A/V-Datei-Eigentümers bereit und enthält Parameter wie etwa eine Anwender-ID, wenigstens ein Zugriffsdatum und eine Zugriffszeit und ein Eigentumsablaufdatum. Die OwnerList-Klasse enthält Methoden zum Hinzufügen und Löschen von Eigentümern.
Der Fachmann auf dem Gebiet versteht, dass die AVSM-Klassenhierarchie 250 leicht geändert oder erweitert werden kann, um Zugriff auf zusätzliche Typen der AVSM-Funktionaliät bereitzustellen oder daran anzupassen.
4.8.3 AVSC-Klassen-Beziehung
Die AVSC-Objekte, die in dem AVSC-Objektarbeitsspeicher 152 liegen, hängen auf ähnliche Weise wie die AVSM-Objekte hierarchisch miteinander zusammen. 17 ist ein Blockdiagramm einer AVSC-Klassen-Beziehung 300, die in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung organisiert ist. In der AVSC-Klassen-Beziehung 300 dient eine MediaResource-Klasse als eine Containerklasse zur Implementierung einer Multithread-AVSC-Funktionalität, wobei sie Methoden für das Thread-Management enthält. Eine AVSCComm-Klasse stellt eine Softwareinfrastruktur zur Implementierung eines AVSC-Kommunikationsports bereit. Die AVSCComm-Klasse stellt eine Grundlage zur Implementierung eines Servers, der Anforderungen empfängt und Antworten ausgibt, sowie eines Clients, der Anforderungen ausgibt und Antworten empfängt, bereit. Üblicherweise wirkt eine AVSC 120 die meiste Zeit als ein Server; allerdings kann eine AVSC 120 während AVSC-AVSC-Datei-Kopieroperationen oder -Übertragungsoperationen als ein Client wirken. Die AVSCComm-Klasse umfasst Parameter und Methoden zum Abrufen von Anforderungen, zum Aufbauen von Objekten, die gemäß dem Anforderungstyp unterteilt sind, und zum Absenden von Anforderungen. In einer Ausführungsform findet das Anforderungsabsenden über die Erzeugung eines der Anforderung entsprechenden Ausführungs-Threads statt. Die AVSCComm-Klasse enthält Bezugnahmen auf eine AVSCRequestList-Klasse und auf eine AVSCReplyList-Klasse.
Die AVSCRequestList-Klasse stellt eine Grundlage zur Implementierung einer Anforderungswarteschlange bereit und nimmt auf eine AVSCRequest-Klasse Bezug. Die AVSCRequest-Klasse ermöglicht die Anforderungsbeschreibung und kann in Übereinstimmung mit dem Anforderungstyp unterteilt sein. Die AVSC- ReplyList-Klasse stellt eine Grundlage zur Implementierung einer Antwortwarteschlange bereit und nimmt auf eine AVSCReply-Klasse Bezug, die gemäß dem Antworttyp unterteilt sein kann.
Eine MessageThreadList-Klasse vereinfacht die Implementierung einer Liste von Threads, die momentan in der AVSC 120 aktiv sind, und nimmt auf eine MediaThread-Klasse Bezug. Die MediaThread-Klasse stellt ein System zur Implementierung eines Threads zur Ausführung dieser Prozesse bereit und erfüllt eine Anforderung. Die MediaThread-Klasse enthält Thread-Parameter wie etwa eine Thread-ID und Thread-Zustandsinformationen. Ferner können die Parameter einen Dateinamen, ein Kennwort und eine IP- oder Netzadresse enthalten. Die MediaThread-Klasse nimmt auf eine MediaMessage-Klasse Bezug. Die Media-Message-Klasse umfasst Parameter und Methoden, die die Thread-Ausführung anweisen, und ist gemäß dem Thread-Typ unterteilt.
Im Kontext der AVSC-Klassen-Beziehung 300 umfasst ein "Kanal" eine Gruppe von Betriebsmitteln, die zur Ausführung eines bestimmten Operationstyps wie etwa einer A/V-Datei-Wiedergabeoperation oder -Aufzeichnungsoperation zugeordnet worden sind. Eine ChannelList-Klasse ermöglicht die Implementierung einer Liste, die eine momentane Menge von Kanälen in der AVSC 120 identifiziert oder beschreibt. Die ChannelList-Klasse nimmt auf eine MediaChannel-Klasse Bezug, die eine Containerklasse zur Darstellung eines Kanals umfasst. Die MediaChannel-Klasse enthält wahlweise Bezugnahmen auf eine Encoder-Klasse, auf eine Decoder-Klasse, auf eine Transcoder-Klasse, auf eine Buffer-Klasse, auf eine DiskAccess-Klasse und auf eine NetAccess-Klasse. Die Encoder-Klasse stellt eine Grundlage für die Beschreibung und Steuerung eines Codierers innerhalb der AVSC 120 bereit und enthält Parameter, die den Codierertyp, die unterstützten Qualitätsebenen, ob der Codierer belegt oder verfügbar ist und Methoden, die mit einer Menge von Softwaretreibern, die die Codiererhardware steuern, kommunizieren, angeben. Die Decoder-Klasse dient als Grundlage zur Beschreibung und Leitung des Betriebs eines Codierers in der AVSC 120 und enthält Parameter, die den Decodierertyp, unterstützte Qualitätsebenen, die Verfügbarkeit und Methoden, die mit Softwaretreibern kommunizieren, die den Decodiererbetrieb steuern, angeben. Ähnlich dient die Transcoder-Klasse als Grundlage für die Beschreibung und Leitung des Betriebs eines Transcoders in der AVSC 120 und enthält Para meter, die den Transcodertyp, unterstützte Quell- und Zielcodierformate, die Verfügbarkeit und Methoden, die mit Softwaretreibern kommunizieren, die den Transcoderbetrieb steuern, angeben. Die Buffer-Klasse umfasst Parameter und Methoden, die die Implementierung von Arbeitsspeicher und/oder Plattenpuffern ermöglichen, wobei diese Parameter den Puffertyp, die Puffergröße und das Füllniveau enthalten können und wobei diese Methoden Programmanweisungen zum Lesen von dem und zum Schreiben in den Puffer enthalten können. Schließlich dient die NetAccess-Klasse als Grundlage für das Management des Datenaustauschs zwischen der AVSC 120 und dem AVSS-internen Netz 110. Jede der Encoder-, Decoder-, Buffer-, DiskAccess- und NetAccess-Klasse kann in Übereinstimmung mit dem besonderen Wesen der Betriebsmittel, dem sie entspricht, unterteilt sein.
Die MediaChannel-Klasse enthält außerdem eine Bezugnahme auf eine MediaFile-Klasse, die als ein Wrapper für die Bereitstellung einer Schnittstelle zu der besonderen Funktionalität und zu dem besonderen AVSC-Betriebsmittel, die dem Kanal zugeordnet sind, dient. Außerdem enthält der MediaChannel eine Bezugnahme auf eine MessageThreadList-Klasse, die die Implementierung einer Liste ermöglicht, die im Umfang des Kanals momentan aktive Threads identifiziert.
Eine EncoderList-Klasse in der AVSC-Klassen-Beziehung 300 dient als Grundlage zur Implementierung einer Liste, die die Codierer in der AVSC 120 identifiziert. Die EncoderList-Klasse enthält eine Bezugnahme auf die oben erwähnte Encoder-Klasse. Ähnlich dient eine DecoderList-Klasse als Grundlage zur Implementierung einer Liste, die die Decodierer in der AVSC 120 identifiziert. Die DecoderList-Klasse enthält eine Bezugnahme auf die Decoder-Klasse. Eine TranscoderList-Klasse ermöglicht die Implementierung einer Liste, die die Transcoder in der AVSC 120 identifiziert. Die TranscoderList-Klasse nimmt außerdem auf die Transcoder-Klasse Bezug. Eine BufferList-Klasse ermöglicht die Implementierung einer Liste, die die Pufferzuordnung in der AVSC 120 angibt und die eine Bezugnahme auf die Buffer-Klasse enthält. Eine DiskAccessList-Klasse ermöglicht die Implementierung einer Liste, die die Zuordnung von Speichervorrichtungen in der AVSC 120 angibt und die eine Bezugnahme auf die Disk-Klasse enthält. Schließlich ermöglicht eine NetAccessList-Klasse die Implementierung einer Liste zugewiesener Netzzugriffsbetriebsmittel und enthält eine Bezugnahme auf die NetAccess-Klasse.
Wie bei der AVSM-Klassen-Beziehung 250 versteht der Fachmann auf dem Gebiet, dass die AVSC-Klassen-Beziehung 300 leicht geändert oder erweitert werden kann, um den Zugriff auf zusätzliche Typen von AVSC-Funktionalität bereitzustellen oder an ihn anzupassen.
4.9 Client- und Serverkommunikation
In der vorliegenden Erfindung verlangt ein AVSS-externer oder AVSS-interner Client, der einen Dienst anfordert, auf den über eine Instanz eines Zielobjekts zugegriffen wird, den Dienst, indem er eine Anforderung ausgibt. Das Zielobjekt kann in Reaktion darauf eines oder mehrere Teile des geforderten Dienstes ausführen, als ein Client wirken und eine oder mehrere Anforderungen an andere Objekte ausgeben und/oder eine oder mehrere Nachrichten ausgeben. Bei Dienstabschluss gibt das Zielobjekt eine Antwort aus. Somit kann die Ausgabe einer Anforderung hoher Ebene aus einer hierarchischen Sicht Anlass zur Ausgabe einer oder mehrerer Anforderungen und Antworten auf niedrigerer Ebene, gefolgt von der Ausgabe einer Antwort hoher Ebene, führen. In einer Ausführungsform der vorliegenden Erfindung wird jede solche Anforderung und Antwort auf eine für den Fachmann auf dem Gebiet leicht verständliche Weise in Übereinstimmung mit einer herkömmlichen Internetprotokollfamilie (IP-Familie) ausgetauscht.
4.10 AVSM-Anforderungskategorien
Die von dem AVSM 160 verstandenen Anforderungen erstrecken sich über mehrere Kategorien, die in einer Ausführungsform die Folgenden enthalten:
4.10.1 Anforderungen eines externen Clients an das AVSS
Anforderungen, die von AVSS-externen Clients verwendet werden können, die Zugriff auf AVSS-Dienste anfordern, enthalten die Folgenden:

a) Anmeldung – initiiert eine Anmeldungssitzung mit dem AVSS 100 und stellt Anwenderinformationen und zugeordnete A/V-Netz-Dienstinformationen für den AVSM 160 bereit, wobei die Anwenderinformationen eine Anwender-ID und ein Kennwort enthalten.
b) Abmeldung – schließt die Anwenderwechselwirkung mit dem AVSS 100 ab.
c) GetFileLimits – gibt momentan organisierte und physikalische Grenzen an die Länge einer zu codierenden A/V-Datei zurück.
d) Acquire AVChannel – baut durch Reservieren bestimmter AVSC-Betriebsmittel zum Ausführen angegebener Operationstypen wie etwa Codieren, Decodieren, Transcodieren und/oder Streaming eine Sitzung auf. Gibt ein Quell-AVSC-Betriebsmittel und wenigstens ein Bestimmungs-AVSC-Betriebsmittel an, um mehrere Betriebsarten flexibel zu unterstützen, die die Folgenden enthalten:
1) Wiedergabebetriebsart – ermöglicht die Wiedergabe einer in einer AVSC-Speichervorrichtung liegenden A/V-Datei zu einer Anwender-Workstation 40, wobei diese Wiedergabe mit einer angegebenen Geschwindigkeit oder Wiedergaberate stattfinden kann. Quellbetriebsmittel = Platte, Bestimmungsbetriebsmittel = Decodierer.
2) Vorschaubetriebsart – ermöglicht Aufzeichnungseinrichtungs- und Aufzeichnungsvorschauoperationen, die eine Anwender-Workstation 40 umfassen (d. h. A/V-Signal-"Durchschleifen" ohne Speicherung von A/V-Signalen auf der Platte). Quellbetriebsmittel = Codierer, Bestimmungsbetriebsmittel = Decodierer.
3) Aufzeichnungsbetriebsart – ermöglicht die A/V-Signal-Aufzeichnung von eine Anwender-Workstation 40 zum Erzeugen einer A/V-Datei in einer AVSC-Speichervorrichtung. Quellbetriebsmittel = Codierer, Bestimmungsbetriebsmittel = Platte.
4) Betriebsart der Wiedergabe während der Aufzeichnung – ermöglicht die A/V-Signal-Aufzeichnung von einer Anwender-Workstation 40 bei gleichzeitiger A/V-Signal-Wiedergabe zu der Anwender-Workstation 40. Quellbetriebsmittel = Codierer, Zielbetriebsmittel = Platte und Decodierer.
5) Betriebsart des Sendens zum Netzknoten – ermöglicht das Senden von A/V-Signalen von einer Anwender-Workstation 40 zu einem Netz (d. h. zu dem AVSS-internen Netz 110 oder zu dem Datennetz 20). Quellbetriebsmittel = Codierer, Bestimmungsbetriebsmittel = Netz.
6) Betriebsart des Sendens und der Wiedergabe – ermöglicht das A/V-Signal-Senden von einer Anwender-Workstation 40 zu einem Netz bei gleichzeitiger A/V-Signal-Wiedergabe zu der Anwender-Workstation 40. Quellbetriebsmittel = Codierer, Bestimmungsbetriebsmittel = Netz und Decodierer.
7) Betriebsart des Sendens während des Aufzeichnens – ermöglicht das Senden an ein Netz während des Ausführens einer A/V-Signal-Aufzeichnung von einer Anwender-Workstation 40 zu einer AVSC-Speichervorrichtung. Quellbetriebsmittel = Codierer, Bestimmungsbetriebsmittel = Platte und Netz.
8) Betriebsart des Sendens mit Aufzeichnung und Wiedergabe – ermöglicht das Senden an ein Netz während des Aufzeichnens von A/V-Signalen von einer Anwender-Workstation 40 zu einer AVSC-Speichervorrichtung und das gleichzeitige Abspielen von A/V-Signalen zu der Anwender-Workstation 40. Quellbetriebsmittel = Codierer, Bestimmungsbetriebsmittel = Netz, Platte und Decodierer.
9) Betriebsart des Hereinstreamens zur Platte – ermöglicht das Empfangen eines Datenstroms von einem Netz zu einer AVSC-Speichervorrichtung. Quellbetriebsmittel = Netz, Bestimmungsbetriebsmittel = Platte.
10) Betriebsart des Hereinstreamens zur Wiedergabe – ermöglicht das Daten-Streaming von einem Netz zu einer Anwender-Workstation 40 über einen AVSC-Decodierer. Quellbetriebsmittel = Netz, Zielbetriebsmittel = Decodierer oder Transcoder.
11) Betriebsart des Hereinstreamens zur Wiedergabe mit Sichern – ermöglicht das Daten-Streaming von einem Netz zu einer Anwender-Workstation 40 und sichert die Daten, die hereingestreamt werden, in einer AVSC-Speichervorrichtung. Quellbetriebsmittel = Netz, Bestimmungsbetriebsmittel = Decodierer oder Transcoder und Platte.
12) Betriebsart des Herausstreamens zum Netz – ermöglicht das Daten-Streaming von eine AVSC-Speichervorrichtung zu einem Netz mit einer angegebenen Streaming-Rate. Quellbetriebsmittel = Platte, Bestimmungsbetriebsmittel = Netz.
13) Betriebsart des Herausstreamens zum Netz und der Wiedergabe, ermöglicht das Daten-Streaming von einer AVSC-Speichervorrichtung zu einem Netz mit einer angegebenen Streaming-Rate bei gleichzeitiger A/V-Signal-Wiedergabe zu der Anwender-Workstation 40. Quellbetriebsmittel = Platte, Bestimmungsbetriebsmittel = Netz und Decodierer.

Der Fachmann auf dem Gebiet versteht, dass für mehrere Betriebsarten, z. B. für jene, die ein Streaming umfassen, ein Pufferbetriebsmittel in einer AVSC als ein Zwischen-Bestimmungsbetriebsmittel enthalten sein kann. Außerdem versteht der Fachmann auf dem Gebiet, dass auf analoge Weise wie oben beschrieben viele weitere Betriebsarten existieren können, für die eine Sitzung aufgebaut und Betriebsmittel reserviert werden können. Wenn geeignet (d. h. je nach der angegebenen Betriebsart), gibt die AcquireAVChannel-Anforderung außerdem Parameter wie etwa einen Dateinamen und ein Kennwort, den A/V-Datei-Codierungstyp und/oder eine minimale Teilbildanzahl, die eine Menge Speicherplatz angibt, der auf einer Speichervorrichtung verfügbar sein muss, an. Nach erfolgreicher Betriebsmittelreservierung gibt eine Antwort, die dem AcquireAVChannel entspricht (d. h. eine AcquireAV- ChannelReply), eine Sitzungszugriffsnummer an einen anfordernden Client zurück.

e) AcquireDataChannel – baut eine Sitzung auf und reserviert AVSC-Betriebsmittel für bestimmte Typen von Dateiübertragungsoperationen einschließlich Kopieren-zu-, Kopieren-von-, Dateiabfrage- und Dateiauflistungsoperationen. Diese Anforderung enthält Parameter, die eine Betriebsart wie etwa Nur-Lesen oder Lesen-Schreiben angeben, sowie Parameter wie etwa Dateiname, Kennwort und eine minimale Menge Speicherplatz, der auf einer AVSC-Speichervorrichtung vorhanden sein muss. Nach der AVSC-Betriebsmittelreservierung gibt eine dem AcquireDataChannel entsprechende Antwort eine Sitzungszugriffsnummer zurück.
f) AcquireAVFilelmportChannel – baut eine Sitzung zum Importieren einer A/V-Datei in das AVSS 100 auf und gibt eine Sitzungszugriffsnummer und die Netz- oder IP-Adresse der AVSC 120 zurück, die die A/V-Datei anfangs empfangen wird.
g) AcquireAVFileExportChannel – baut eine Sitzung zum Exportieren einer A/V-Datei von dem AVSS 100 zu dem Client auf und gibt die Netz- oder IP-Adresse der AVSC 120, in der die Datei gespeichert ist, zuzüglich einer Sitzungszugriffsnummer zurück.
h) AcquirePublishChannel – baut eine Sitzung zum Veröffentlichen einer A/V-Datei von einer AVSC 120 zu einem oder zu mehreren Nicht-AVSS-Zielservern auf. Die angegebenen Parameter enthalten einen Dateinamen und ein Kennwort sowie einen Zielservertyp. Eine dieser Anforderung zugeordnete Antwort gibt eine Sitzungszugriffsnummer zurück.
i) PublishFile – veröffentlicht eine Datei zu einem Nicht-AVSS-Zielserver. Angegebene Parameter enthalten einen Dateinamen und ein Kennwort, eine Zielserver-Netz- oder Zielserver-IP-Adresse und Zielserver-Anmeldeinformationen und -Kennwortinformationen.
j) RequestPublishLocations – gibt bei gegebenem angegebenen Dateinamen und Kennwort eine bekannte Nicht-AVSS-Zielserverkennung sowie die Netz- und IP-Adresse, zu denen eine Datei zuvor, wie durch die AVSS-Datenbank angegeben wird, veröffentlicht worden ist, zurück.
k) DeletePublishLocations – löscht bei gegebenem angegebenen Dateinamen, Dateikennwort und Nicht-AVSS-Zielserver-Netzadresse oder -IP-Adresse oder Zielservertyp Veröffentlichungsbezugnahmen einer Datei für den Zielserver oder für Zielservertypen aus der AVSS-Datenbank. Wenn die Zielserveranmeldung, das Anmeldekennwort und irgendwelche Löschberechtigungsinformationen ebenfalls angegeben sind, versucht DeletePublishedFile außerdem, die veröffentlichte Datei von dem Zielserver selbst zu löschen.
l) ReleaseAVChannel – gibt das über die AcquireAVChannel-, AquireAVFilelmportChannel-, AquireAVFileExportChannel- und AcquirePublishChannel-Anforderungen erhaltene Betriebsmittel oder die darüber erhaltenen Betriebsmittel frei und löscht eine entsprechende Sitzungszugriffsnummer.
m) AVSMStatusRequest – gibt während Dateikopier-, Dateiimport-, Dateiexport- und Dateiveröffentlichungsoperationen Statusinformationen an einen Client zurück, wenn eine gültige Sitzungszugriffsnummer angegeben worden ist, wobei diese Statusinformationen eine Anzahl übertragener Bytes oder eine geschätzte bis zum Operationsabschluss verbleibende Zeitdauer enthalten können.
n) GetAVFileAttributes – gibt für eine A/V-Datei Attribute einschließlich durch ein Anwendungsprogramm definierter Attribute zurück. Hinsichtlich dessen, welche Attribute zurückgegeben werden können, können bestimmte Einschränkungen existieren. Zum Beispiel kann nur zugelassen sein, dass ein bevorzugter Anwender und der Dateiautor eine vollständige Eigentümerliste betrachten. Es kann zugelassen sein, dass ein Anwender Dateiattribute betrachtet, wenn der Anwender als ein Eigentümer für die Datei angegeben ist und irgendwelche zurückgegebenen Attribute spezifisch für diesen Anwender sind.

In einer Ausführungsform können bevorzugte Anwender und die Dateiautoren auf die folgenden Operationen zugreifen:

o) SetAVFileAttributes – stellt die variablen Attribute einer A/V-Datei einschließlich durch ein Anwendungsprogramm definierter Attribute ein.
p) AddOwner – veranlasst, dass der AVSM 160 zu der einer A/V-Datei entsprechenden Zugriffsrechteliste eine angegebene Anwender-ID hinzufügt.
q) RemoveOwner – veranlasst, dass der AVSM 160 eine angegebene Anwender-ID aus der einer A/V-Datei entsprechenden Zugriffsrechteliste entfernt.
r) RequestAVFile – fordert eine A/V-Datei von einem Nicht-Standort-Quell-AVSS 100 an. Wenn die AV-Datei in dem Bereich des AVSM 160, der diese Anforderung empfängt, vorhanden ist, ruft eine Dateiübertragungsprozedur die A/V-Datei von dem Nicht-Standort-Quell-AVSS 100 ab.

4.10.2. Anforderungen von einem Client über einen AVSM zu einer AVSC
Viele der Anforderungen, die der AVSM 160 an eine AVSC 120 ausgibt, sind Varianten jener, die durch Clientanwendungsprogramme an den AVSM 160 gesendet werden. Anforderungen, die der AVSM 160 von externen Clients empfangen und zur Bedienung an eine AVSC 120 weiterleiten oder übergeben kann, enthalten die Folgenden:

a) Open – je nach Betriebsart Spezifizierer, der angibt, ob eine A/V-Datei in Bezug auf A/V-Betriebsmittel-Prozesse (MEDIA-Betriebsart) oder Dateiübertragungsprozesse (DATA-Betriebsart) bearbeitet werden soll, öffnet oder erzeugt eine A/V-Datei und bereitet sie auf die Codierung, Decodierung und/oder Transcodierung, auf das Hereinstreamen oder auf das das Herausstreamen (MEDIA-Betriebsart) oder auf die Datenübertragung (DATA-Betriebsart) vor. Beim Abschluss dieser Anforderung wird eine Antwort ausgegeben, die eine Sitzungszugriffsnummer enthält.
b) Close – schließt eine einer angegebenen Sitzungszugriffsnummer zugeordnete Datei.
c) Read – liest für eine in der DATA-Betriebsart geöffnete Datei aus der Datei eine angegebene Anzahl von Bytes und überträgt sie an den anfordernden Client.
d) Write – überträgt für eine in der DATA-Betriebsart geöffnete Datei eine angegebene Anzahl von Bytes und schreibt sie in die Datei.
e) Seek – positioniert für eine in der DATA-Betriebsart geöffnete Datei die Datei bei einem angegebenen Byte. Positioniert für eine in der Medienbetriebsart geöffnete Datei die Datei bei einem angegebenen Teilbild.
f) Play veranlasst, dass die AVSC 120 einem Decodierer signalisiert, dass er mit der Verarbeitung einer Datei und mit dem Zuführen der Ausgabe zu dem A/V-Netz 30 beginnen soll. Parameter enthalten die Wiedergabegeschwindigkeit oder -rate sowie Richtungs- und Verarbeitungslängenindikatoren, die zulassen, dass diese Anforderung schnellen Vorlauf, Rücklauf oder ähnliche Operationen implementiert.
g) Record – veranlasst, dass die AVSC 120 einem Codierer signalisiert, dass er mit dem Sichern der A/V-Ausgabe in einer Datei beginnen soll. Es kann eine Aufzeichnungslängenbegrenzung angegeben sein.
h) StreamIn – veranlasst, dass die AVSC 120 in Übereinstimmung mit den für einen bestimmten Kanal reservierten Betriebsmitteln Daten aus dem AVSS-internen Netz 110 in einen Puffer, in einen Datenspeicher und/oder in ein Decodierungsbetriebsmittel streamt.
i) StreamOut – veranlasst, dass die AVSC 120 in Übereinstimmung mit den für einen bestimmten Kanal reservierten Betriebsmitteln mit einer angegebenen Rate Daten aus einem Puffer, aus einem Datenspeicher und/oder aus einem Codierungsbetriebsmittel in das AVSS-interne Netz 110 streamt.
j) Stop veranlasst die vorübergehende Einstellung eines momentanen Codierungs-, Decodierungs- Transcodierungs- oder Streaming-Prozesses.
k) Status – gibt in der MEDIA-Betriebsart die momentane Dateibetriebsart und Teilbildnummer oder in der DATA-Betriebsart die Byteposition zurück.

4.10.3. Anforderungen von einem AVSM zu einer AVSC
Anforderungen, die der AVSM 160 an eine Ziel-AVSC 120 in Bezug auf einen A/V-Zugriff und auf eine Dateiübertragung ausgibt, enthalten die Folgenden:

a) AcquireChannel – fordert an, dass die AVSC 120 einen Kanal erzeugt, der einen angegebenen Codierer, Decodierer und/oder Transcoder zur Verwendung durch einen AVSS-Client reserviert. Außerdem kann diese Anforderung zum Reservieren von Dateiübertragungsbandbreite für eine bevorstehende Dateiübertragung oder für bevorstehende Streaming-Operationen verwendet werden. Fordere Abschlussergebnisse in der Rückgabe einer Kanalzugriffsnummer an, die dazu verwendet werden kann, die zugeordneten Betriebsmittel in nachfolgenden Operationen zu identifizieren.
b) ReleaseChannel – gibt für die AVSC 120 an, dass die einer angegebenen Zugriffsnummer zugeordneten Betriebsmittel nicht mehr erforderlich sind und freigegeben werden sollen.
c) SetMediaSetup – stellt Konfigurationsinformationen für die Ziel-AVSC 120 ein oder aktualisiert sie. Diese Anforderung wird üblicherweise genutzt, wenn die Hardwarekonfiguration der AVSC geändert worden ist.
d) GetMediaSetup – gibt Konfigurations- und Nutzungsinformationen für die Ziel-AVSC 120 zurück.
e) GetDriveInfo – gibt Informationen über eine angegebene Speichervorrichtung zurück.
f) GetMediaStatus – gibt momentane AVSC-Nutzungs- und AVSC-Zustandsinformationen zurück.
g) Rename – benennt eine angegebene Datei um.
h) Delete – löscht eine angegebene Datei.
i) CopyTo – initiiert die Übertragung einer angegebenen Datei zu einer angegebenen Bestimmungs-AVSC 120.
j) CopyFrom – initiiert die Übertragung einer angegebenen Datei von einer Quell-AVSC 120.

4.10.4. Anforderungen von einer AVSC zu einem AVSM
Eine AVSC 120 kann Informationsanforderungen an ihren managenden AVSM 160 senden, um Dateiübertragungsoperationen, den A/V-Operations-Abschluss und/oder dem allgemeinen Hardwarestatus zugeordnete Zustandsänderungen anzugeben. Solche Informationsanforderungen enthalten die Folgenden:

a) Play End – gibt an, dass eine momentane Abspieloperation wegen des Dateiendes oder da eine Abspiellänge erreicht worden ist, abgeschlossen worden ist.
b) RecordEnd – gibt an, dass eine momentane Aufzeichnungsoperation abgeschlossen worden ist.
c) HardwareError – gibt eine Hardwarestörung an, die einem angegebenen Codierer, einem angegebenen Decodierer, einem angegebenen Transcoder oder einer angegebenen Speichervorrichtung zugeordnet ist.

4.10.5. Anforderungen von einem AVSM zu einem AVSM
Außer dem Empfangen externer Anforderungen von Clientanwendungsprogrammen kann ein Standort-AVSM 160 Anforderungen von einem Nicht-Standort-AVSM 160 empfangen. Üblicherweise entsprechen solche Anforderungen Dateiübertragungsoperationen und enthalten die Folgenden:

a) RequestAVFileSource – wird beim Empfang eines "RequestAVFile" von einem Client durch den Standort-AVSM 160 an den Nicht-Standort-AVSM 160 ausgegeben. Der Nicht-Standort-AVSM gibt i) die Netz- oder IP-Adresse einer AVSC 120, die als eine Dateiquelle dienen kann, ii) Attribute für eine angegebene A/V-Datei und iii) eine Kanalzugriffsnummer zurück.
b) NotifyAVFileSource – wird beim erfolgreichen Abschluss einer AV-Dateiübertragung zwischen einer Standort- und einer Nicht-Standort-AVSC 120 gesendet und enthält die Anwender-ID und die Quellkanal-Zugriffsnummer, sodass der Nicht-Standort-AVSM 160 Quell-AVSC-Betriebsmittel, die für die Dateiübertragung reserviert worden sind, freigeben kann.

4.10.6. AVSM-Organisationsanforderungen
Mehrere Anforderungen, von denen auf einige nur ein bevorzugter Anwender zugreifen kann, können zum Ausführen der AVSS-Konfiguration und für Organisationsoperationen verwendet werden und enthalten die Folgenden:

a) SetPrivileged – baut eine Sitzung des bevorzugten Anwenders auf, über die der bevorzugte Anwender auf viele Organisationsfunktionen zugreifen kann. Diese Anforderung erfordert ein Kennwort.
b) GetAVSMLogInfo – gibt in dem AVSM-Ereignisprotokoll gespeicherte Informationen zurück.
c) ClearAVSMLogInfo – löscht das AVSM-Ereignisprotokoll.
d) SetAVSMLogLevel – gibt zu protokollierende Anforderungs- und Ereignistypen sowie ein Detailniveau für das Protokollieren und eine maximale AVSM-Ereignisprotokollgröße an.
e) ListAVSCs – gibt eine Liste durch den AVSM 160 gemanagter AVSCs 120 zurück.
f) GetAVSCInfo – gibt Konfigurations- und Nutzungsinformationen für eine bestimmte AVSC 120 zurück.
g) GetAVSCLogInfo – gibt in dem AVSC-Ereignisprotokoll, in der Nachrichtenwarteschlange gespeicherte Informationen zurück.
h) ClearAVSCLogInfo – löscht das Ereignisprotokoll einer angegebenen AVSC.
i) SetAVSCLogLevel – gibt Anforderungstypen und zu protokollierende Ereignisse sowie ein Detailniveau und eine maximale AVSC-Ereignisprotokollgröße für eine angegebene AVSC 120 an.
j) SetAVNMInfo – aktualisiert in dem AVSM 160 unterhaltene A/V-Netz-Manager-Informationen.
k) AddAVSC – fügt zu der AVSS-Datenbank einer neu hinzugefügten Standort-AVSC 120 entsprechende Konfigurationsinformationen hinzu. Die Konfigurationsinformationen für die neue AVSC 120 werden durch Abfragen der AVSC 120 erhalten.
l) RemoveAVSC – entfernt aus der AVSS-Datenbank Informationen, die einer AVSC 120 entsprechen, die nicht mehr in der Standortgruppe ist.
m) ListAVSS – gibt für jedes Nicht-Standort-AVSS 100, von dem der AVSM 160 Kenntnis hat, eine Netz- oder IP-Adresse zurück.
n) GetAVSSInfo – gibt für ein bestimmtes dem AVSM 160 bekanntes Nicht-Standort-AVSS 100 Routing- und/oder Verbindungsaufbauinformationen zurück.
o) SetAVSSInfo – stellt für ein angegebenes Nicht-Standort-AVSS 100 Routing- und/oder Verbindungsaufbauinformationen ein. In einer Ausführungsform betreffen diese Informationen den Host-AVSM 160 für das angegebene AVSS 100.
p) AddAVSS – fügt ein angegebenes Nicht-Standort-AVSS 100 zu den dem AVSM 160 bekannten hinzu. In einer Ausführungsform werden die Routing- und Verbindungsaufbauinformationen für das neu hinzugefügte AVSS 100 über SetAVSSInfo angegeben.
q) RemoveAVSS – entfernt ein Nicht-Standort-AVSS 100 von den dem AVSM 160 bekannten.
r) SetAVFileLimits – stellt eine während Codierungsoperationen maximal zulässige A/V-Datei-Länge ein.

Der Fachmann auf dem Gebiet erkennt, dass ein AVSS in einer alternativen Ausführungsform zusätzliche oder weniger Anforderungen unterstützen könnte.
4.11 AVSC-Anforderungskategorien
Die AVSC 120 stellt eine Unterstützung für eine Vielzahl von Anforderungen einschließlich jener in den folgenden Kategorien bereit:
4.11.1. Zuordnungs- und Berechtigungsanforderungen

a) AuthorizationResource – stellt sicher, dass ein Client, der durch die AVSC 120 bereitgestellte Dienste anfordert, entweder ein AVSM 160 oder ein Client, der eine gültige Kanalzugriffsnummer liefert, ist.
b) AllocateChannel – erzeugt einen Kanal, dem angegebene Betriebsmittel zugeordnet werden, und gibt eine Kanalzugriffsnummer zurück.
c) ChangeChannel – fügt für einen durch eine Kanalzugriffsnummer identifizierten Kanal angegebene Betriebsmittel zu dem Kanal hinzu bzw. löscht sie aus ihm.
d) ReleaseChannel – gibt für einen durch eine Kanalzugriffsnummer identifizierten Kanal Kanalbetriebsmittel frei (d. h., Kanalbetriebsmittel werden an den "Nicht-Belegt"- oder "Nicht-Zugeordnet"-Status zurückgegeben), entfernt den Kanal aus der Kanalliste und gibt die Kanalzugriffsnummer frei.

4.11.2. Dateimanagementanforderungen

a) CopyFromChannel – baut eine Kopiersitzung mit einer Quell-AVSC 120 auf und führt die Dateikopieroperationen aus.
b) CopyToChannel – baut eine Kopiersitzung mit einer Ziel-AVSC 120 auf und führt Dateikopieroperationen aus.
c) RenameChannel – benennt eine angegebene Datei um.
d) DeleteChannel – löscht eine angegebene Datei.
e) FindFilesFirstChannel – führt Dateiverzeichnungsoperationen aus, gibt die ersten k Dateien zurück.
f) FindFilesNextChannel – führt Dateiverzeichnungsoperationen aus, gibt die nächsten n Dateien zurück.
g) GetFileInfoChannel – öffnet eine angegebene Datei und gibt Informationen über den Medieninhalt der Datei zurück; diese Anforderung kann z. B. zum Überprüfen von Dateiimportoperationen oder für die Konsistenzprüfung genutzt werden.
h) PublishDigitalFileChannel – führt Formatkonvertierungs-, Anmeldeoperationen und Dateikopieroperationen aus, um eine angegebene Datei in einem angegebenen Format zu einem anderen Server zu veröffentlichen.

4.11.3 Medienanforderungen

a) OpenChannel – öffnet eine angegebene A/V-Datei in einem angegebenen Kanal.
b) ReadChannel – liest aus einer A/V-Datei in einem angegebenen Kanal.
c) WriteChannel – schreibt in eine A/V-Datei in einem angegebenen Kanal.
d) PlayChannel – spielt eine A/V-Datei in einem angegebenen Kanal mit einer angegebenen Bildwiederholrate ab.
e) StreamInChannel – streamt eine A/V-Datei in einem angegebenen Kanal.
f) StreamOutChannel – streamt eine A/V-Datei aus einem angegebenen Kanal mit einer angegebenen Datenrate.
g) RecordChannel – zeichnet eine A/V-Datei in einem angegebenen Kanal auf.
h) PauseChannel – hält A/V-Datei-Operationen in einem angegebenen Kanal an.
i) StopChannel – beendet A/V-Datei-Operationen in einem angegebenen Kanal.
j) ResumeChannel – nimmt A/V-Datei-Operationen in einem angegebenen Kanal wieder auf.
k) SeekChannel – bewegt sich in einer A/V-Datei in einem angegebenen Kanal zu einer gegebenen Stelle.
l) StatusChannel – gibt Informationen über den momentanen Status der Operationen an einer angegebenen A/V-Datei einschließlich des momentanen Teilbilds oder der momentanen Stelle in der Datei in einem angegebenen Kanal zurück.
m) CloseChannel, schließt eine A/V-Datei in einem angegebenen Kanal.

4.11.4 Organisationsanforderungen

a) InitializeResource – setzt Hardware zurück, baut Listen neu auf und ordnet Objekte neu zu.
b) GetMediaSetupResource – gibt Informationen über Codierer, Decodierer, Transcoder und Speichervorrichtungen in der AVSC 120 zurück.
c) SetMediaSetupResource – stellt Informationen über Codierer, Decodierer, Transcoder und/oder Speichervorrichtungen in der AVSC 120 ein.
d) GetMediaStatusResource – gibt den momentanen Status von AVSC-Betriebsmitteln einschließlich einer Anzahl offener Kanäle, einer Anzahl von Codierern, Decodierern, Transcodern im Gebrauch, die Speichervorrichtungsnutzung und den verfügbaren Speicherplatz und die Puffernutzung und die Nutzung des internen Netzes zurück.
e) HangupResource – führt eine Störungserholungs- oder Systemverlet zungserholungsoperationen aus.
f) ShutdownResource – führt Abschaltoperationen aus, nach denen die AVSC 120 neu initialisiert werden kann.

4.12 Anforderungssequenzbeispiele
Die folgende Beschreibung beschreibt genau den Ablauf von Anforderungen und Antworten, die in Reaktion auf beispielhafte AVSS-externe Anforderungen erzeugt werden, die mehreren Betriebskategorien, die wie folgt definiert sind, entsprechen:
4.12.1 Sitzungsaufbau und Betriebsmittelreservierung
18 ist ein beispielhaftes Anforderungsfolgediagramm für die oben beschriebene AcquireAVChannel-Anforderung. In 18 gibt ein AVSS-Client (d. h. ein Clientanwendungsprogramm) an seinen Standort-AVSM 160 eine AcquireAVChannel-Anforderung aus, die eine Betriebsart und betriebsartspezifische Parameter angibt. Der AVSM 160 ermittelt eine Menge zum Erfüllen der Kanalerfassungsanforderung erforderlicher AVSC-Betriebsmittel und identifiziert eine geeignete AVSC 120. Daraufhin gibt der AVSM 160 an die AVSC 120 eine AcquireChannel-Anforderung aus, die eine Menge für einen Kanal zu reservierender Betriebsmittel angibt. Beim Reservieren der Betriebsmittel gibt die AVSC 120 an den AVSM 160 eine AcquireChannelReply aus, die eine Kanalzugriffsnummer und einen Rückkehrcode, der angibt, ob die Betriebsmittelreservierung erfolgreich war, enthält. Nachfolgend gibt der AVSM 160 an den Client eine AcquireAVChannel-Reply aus, die eine Sitzungszugriffsnummer enthält. Nachfolgend kann der Client die Sitzungszugriffsnummer verwenden, um in Übereinstimmung mit den Typen der der Kanalzugriffsnummer zugeordneten AVSC-Betriebsmittel bestimmte Operationen anzufordern. Der AVSM 160 kann für irgendeinen gegebenen Client eine oder mehrere Sitzungszugriffsnummern auf einen einzelnen Kanal und auf eine einzelne Zugriffsnummer abbilden. Während nachfolgender Operationen ist der AVSM 160 für die Abbildung von Sitzungszugriffsnummern auf die richtige Kanalzugriffsnummer verantwortlich. Der Fachmann auf dem Gebiet versteht, dass für jeden bestimmten oben beschriebenen Typ der Kanalerfassungsanforderung analoge Operationen stattfinden.
4.12.2. A/V-Datei-Management
Da der AVSM 160 für die Unterhaltung der AVSS-Datenbank verantwortlich ist, muss er in Reaktion auf Client-Anforderungen, die A/V-Dateien betreffen, eine Verarbeitung ausführen. Da die A/V-Dateien physikalisch in den AVSCs 120 gespeichert sind, übergibt der AVSM 160 Anforderungen nach dieser Verarbeitung an die richtige AVSC bzw. an die richtigen AVSCs 120 oder leitet sie an diese weiter. Im Allgemeinen untersucht der AVSM 160 für AVSS-Clients, die Zugriff auf eine A/V-Datei erfordern, die AVSS-Datenbank, um zu ermitteln, ob eine angegebene Datei existiert, und in welchen AVSCs 120 die Datei liegt. Wenn eine A/V-Datei erzeugt wird, fügt der AVSM 160 eine Dateiparameterliste zu der AVSS-Datenbank hinzu und wählt eine verfügbare AVSC 120 zur Unterstützung einer Codierungssitzung aus. Der AVSM 160 gibt an die gewählte AVSC 120 eine Record-Anforderung aus, aktualisiert seine internen Daten und gibt bei Abschluss der Aufzeichnungsoperation eine RecordReply an den Client aus.
19 ist ein beispielhaftes Anforderungsfolgediagramm für die oben beschriebene "Open"-Anforderung. In 19 gibt ein AVSS-Client (d. h. ein Clientanwendungsprogramm) an seinen Standort-AVSM 160 eine Open-Anforderung aus, die eine Sitzungszugriffsnummer, einen Dateinamen und eine Betriebsart (d. h. MEDIA, DATA-Lesen/Schreiben oder -Nur-Lesen) angibt. Nachfolgend bildet der AVSM 160 die Sitzungszugriffsnummer auf die richtige AVSC-Kanalzugriffsnummer ab und leitet die Öffnen-Anforderung an die der Kanalzugriffsnummer entsprechende AVSC 120 weiter. Nach Öffnen der A/V-Datei gibt die AVSC 120 an den AVSM 160 eine OpenReply aus, die eine Kanalzugriffsnummer und einen Rückgabecode, der angibt, ob die Öffnen-Operation erfolgreich war, enthält. Die AVSC 160 antwortet an den AVSS-Client ihrerseits mit einer Sitzungszugriffsnummer und mit einem Rückkehrcode.
20 ist ein beispielhaftes Anforderungsfolgediagramm für die oben erwähnte "Close"-Anforderung. In 20 gibt ein AVSS-Client an den AVSM 160 eine Close-Anforderung aus, die eine Sitzungszugriffsnummer und einen Dateinamen angibt. Der AVSM 160 bildet die Sitzungszugriffsnummer auf die richtige Kanalzugriffsnummer ab und gibt die Schließen-Anforderung, die die Kanalzugriffsnummer und den Dateinamen angibt, an die richtige AVSC 120 aus oder leitet sie an sie weiter. Beim Abschluss der Schließen-Operation gibt die AVSC 120 an den AVSM 160 eine Schließen-Antwort aus, die die Kanalzugriffsnummer und einen Rückkehrcode enthält. Der AVSM 160 bildet die Kanalzugriffsnummer auf die richtige Sitzungszugriffsnummer ab und leitet die Schließen-Anforderung an den AVSS-Client weiter.
21 ist ein beispielhaftes Anforderungsfolgediagramm für eine A/V-Datei-"Delete"-Anforderung. Der AVSM 160 ermittelt in Reaktion auf den Empfang einer Löschanforderung, die eine Sitzungszugriffsnummer und einen vollständig qualifizierten Dateinamen angibt, von einem AVSS-Client, in welchen AVSCs 120 Kopien der A/V-Datei liegen. Daraufhin bildet der AVSM 160 die Sitzungszugriffsnummer auf eine erste Kanalzugriffsnummer ab und leitet die Löschanforderung an eine erste AVSC 120 weiter, in der eine Kopie liegt. Wenn die A/V-Datei-Kopie gelöscht worden ist, gibt die erste AVSC 120 eine DeleteReply an den AVSM 160 aus. Daraufhin bildet der AVSM 160 die Sitzungszugriffsnummer auf eine zweite Kanalzugriffsnummer ab und leitet die Löschanforderung des AVSS-Clients an eine zweite AVSC 120, in der eine Kopie der A/V-Datei liegt, weiter. Die zweite AVSC 120 führt die geforderte Löschoperation aus und gibt eine DeleteReply an den AVSM 160 aus. Der AVSM 160 setzt diesen Prozess durch Abbilden der Sitzungszugriffsnummer auf eine nächste Kanalzugriffsnummer fort und leitet, nachdem er eine DeleteReply von einer AVSC 120 empfangen hat, die die Löschoperation gerade abgeschlossen hat, die Löschanforderung des AVSS-Clients an eine nächste AVSC 120, die eine Kopie der A/V-Datei speichert, weiter, usw., bis in den AVSCs 120 keine Kopien der A/V-Datei mehr liegen. Nachdem die relevanten AVSCs 120 die richtigen A/V-Datei-Kopien gelöscht haben, aktualisiert der AVSM 160 die AVSS-Datenbank 176, um die Löschung zu widerspiegeln, und gibt an den AVSS-Client eine DeleteReply aus.
4.12.3 Codierungs-, Decodierungs- oder Transcodierungssteuerung
22 ist ein beispielhaftes Anforderungsfolgediagramm für eine "Record"-Anforderung. Beim Empfang eine Record-Anforderung von einem AVSS-Client, die eine Sitzungszugriffsnummer und je nach Betriebsart möglicherweise einen Dateinamen angibt, bildet der AVSM 160 die Sitzungszugriffsnummer auf die richtige Kanalzugriffsnummer ab. Der AVSM 160 leitet die abgebildete Auf zeichnen-Anforderung an die AVSC 120 weiter, die Befehle an den der Kanalzugriffsnummer zugeordneten Codierer ausgibt. Wenn die Aufzeichnen-Sitzung abgeschlossen ist, gibt die AVSC 120 an den AVSM 160 eine RecordReply aus, die die Kanalzugriffsnummer und einen Rückkehrcode angibt. Daraufhin bildet der AVSM 160 die Kanalzugriffsnummer auf eine Sitzungszugriffsnummer ab und leitet die RecordReply an den AVSS-Client weiter, wobei die RecordReply die Sitzungszugriffsnummer und einen Rückkehrcode enthält.
4.12.4 Dateiübertragung
Extern erzeugte Dateiübertragungsanforderungen können je nach dem Ort der angeforderten Datei zur Erzeugung mehrerer Intra-AVSS-Anforderungen und -Antworten führen. 23 ist ein beispielhaftes Anforderungsfolgediagramm, das einer Anforderung für eine Dateiübertragung von einem Nicht-Standort-AVSS 100 entspricht. Um die Dateiübertragungsfähigkeiten des AVSS 100 zu nutzen, muss ein Client einen Quell-AVSM-Namen oder eine Quell-AVSM-Adresse sowie einen Dateinamen haben. Der Client liefert diese Parameter über eine RequestAVFile-Anforderung an sein Standort-AVSS 100.
Der Standort-AVSM 160 ermittelt, ob die angeforderte Datei lokal verfügbar ist, d. h., ob sie in einer der Standort-AVSCs 120 gespeichert ist. Wenn das nicht der Fall ist, gibt der Standort-AVSM 160 an das Nicht-Standort-AVSS 100 eine RequestAVFileSource-Anforderung aus. Der Nicht-Standort-AVSM 160 weist über eine AcquireChannel-Anforderung Betriebsmittel in einer AVSC 120 zu, die als Quelle für die Dateiübertragung dienen kann. Nachdem die Betriebsmittel der Nicht-Standort-AVSC 120 zugeordnet worden sind, antwortet sie an den Nicht-Standort-AVSM 160 mit einer AcquireChannelReply. Daraufhin antwortet der Nicht-Standort-AVSM 160 an den Standort-AVSM 160 durch Ausgabe einer RequestAVFileSourceReply, die den Ort oder die Netz- oder IP-Adresse und die Kanalzugriffsnummer der zugeordneten Nicht-Standort-AVSC 120 angibt.
Der Standort-AVSM 160 gibt eine AcquireChannel-Anforderung zum Zuordnen eines Kanals und entsprechender Betriebsmittel an eine Standort-AVSC 120 aus, um die Dateiübertragungsoperation auszuführen, und empfängt in Reaktion darauf eine AcquireChannelReply, die eine Kanalzugriffsnummer angibt. Dar aufhin gibt der Standort-AVSM 160 an die Standort-AVSC 120 eine CopyFrom-Anforderung aus, wobei die CopyFrom-Anforderung den Ort oder die Adresse und die Kanalzugriffsnummer der Quell-AVSC enthält. Die Standort-AVSC 120 initiiert durch Ausgeben einer Open-Anforderung an die Quell-AVSC 120 die Dateiübertragung, wobei die Open-Anforderung angibt, dass die Datei in der DATA-Betriebsart geöffnet werden soll. Beim Empfang einer OpenReply von der Quell-AVSC 120 gibt die Standort-AVSC 120 an die Quell-AVSC 120 eine Reihe von Read-Anforderungen aus, die zu der Dateiübertragung führen. Die Quell-AVSC 120 führt für jede solche Read-Anforderung eine Leseoperation aus und gibt an die Standort-AVSC 120 eine ReadReply aus.
Nachdem die Datei übertragen worden ist, gibt die Standort-AVSC 120 an die Quell-AVSC 120 eine Close-Anforderung aus. Die Quell-AVSC 120 schließt die Datei und gibt eine CloseReply an die Standort-AVSC 120 aus, die ihrerseits eine CopyFromReply an den Standort-AVSM 160 ausgibt. Nachfolgend gibt der Standort-AVSM 160 an die Standort-AVSC 120 eine ReleaseChannel-Anforderung aus, um der Kopieroperation zugeordnete Betriebsmittel freizugeben, wonach die AVSC 120 eine ReleaseChanneiReply ausgibt. Nachfolgend aktualisiert der Standort-AVSM 160 die AVSS-Datenbank 176, um die Anwesenheit der neuen Datei zu widerspiegeln. Nachfolgend sendet der Standort-AVSM 160 an den Nicht-Standort- oder Quell-AVSM 160 eine NotifyAVFileSource-Nachricht, um dem Nicht-Standort-AVSM 160 anzugeben, dass die Übertragung abgeschlossen ist. Der Nicht-Standort-AVSM 160 gibt eine ReleaseChannel-Anforderung an die Quell-AVSC 120 aus, die für die Kopieroperation reservierte Betriebsmittel freigibt und eine an den Nicht-Standort-AVSM 160 gerichtete ReleaseChannelReply erzeugt. Daraufhin gibt der Nicht-Standort-AVSM 160 an den Standort-AVSM 160 eine NotifyAVFileSourceReply aus. Schließlich sendet der Standort-AVSM 160 eine RequestAVFileReply an den AVSS-Client, der die Dateiübertragungsoperation angefordert hat.
4.12.5 Dateireplikation
Wenn in einer AVSC 120 eine neue A/V-Datei liegt, kann der AVSM 160 eine Reihe von Anforderungen zum Ausführen von A/V-Datei-Replikationsoperationen ausgeben. In einer Ausführungsform ist die A/V-Datei- Replikation erforderlich, wenn in der Zugriffsrechteliste der Datei mehr als ein Eigentümer angegeben ist. Somit würde die Dateireplikation z. B. nach der Verarbeitung oder als Teil der Verarbeitung einer "AddOwner"-Anforderung ausgeführt, die von einem Clientanwendungsprogramm empfangen wird. In einer weiteren Ausführungsform wird die A/V-Datei-Replikation selbst dann ausgeführt, wenn eine A/V-Datei nur einen Eigentümer hat, sodass eine gegebene A/V-Datei in wenigstens zwei Standort-AVSCs 120 liegt. Dieser Ansatz würde die Systemzuverlässigkeit oder die Fehlertoleranz verbessern. In einer solchen Ausführungsform würde die Dateireplikation z. B. nach einer wie oben anhand von 23 beschriebenen Dateiübertragungsoperation stattfinden.
24 ist ein beispielhaftes Anforderungsfolgediagramm, das Dateireplikationsoperationen entspricht. Der AVSM 160 könnte Dateireplikationsoperationen z. B. nach Ausgabe einer RequestAVFile-Antwort an einen AVSS-Client, die den Abschluss wie zuvor beschriebener Dateiübertragungsoperationen angibt, ausführen. Um Replikationsoperationen zu initiieren, gibt der AVSM 160 an die AVSC 120, in der die Datei liegt, d. h., an die Quell-AVSC 120, eine erste AcquireChannel-Anforderung aus. Nach Empfang einer AcquireChannelReply gibt der AVSM 160 an eine Bestimmungs-AVSC 120, zu der die Datei kopiert wird, eine zweite AcquireChannel-Anforderung aus. Wenn der AVSM 160 von der Bestimmungs-AVSC 120 eine AcquireChannelReply empfängt, gibt er an diese AVSC 120 eine Copy-From-Anforderung aus. Daraufhin sendet die Bestimmungs-AVSC 120 eine Open-Anforderung an die Quell-AVSC 120. Beim Empfang einer OpenReply sendet die Bestimmungs-AVSC 120 an die Quell-AVSC 120 eine Reihe von Read-Anforderungen, die zur Übertragung der Datei von der Quell- zur Bestimmungs-AVSC 120 führen. Nachdem die Quell-AVSC 120 auf eine gegebene Read-Anforderung geantwortet hat, gibt sie an die Bestimmungs-AVSC 120 eine ReadReply aus. Beim Antworten auf eine letzte Read-Anforderung und beim Ausgeben einer letzten ReadReply sendet die Bestimmungs-AVSC 120 eine Close-Anforderung an die Quell-AVSC 120, die die Datei schließt und eine CloseReply an die Bestimmungs-AVSC 120 ausgibt. Nachfolgend gibt die Bestimmungs-AVSC 120 an den AVSM 160 eine CopyFromReply aus. Daraufhin gibt der AVSM 160 an die Bestimmungs-AVSC 120 eine ReleaseChannel-Anforderung aus und empfängt seinerseits eine ReleaseChannelReply. Gemäß der bestimmten genutz ten Dateireplikationsstrategie kann der AVSM 160 die oben beschriebenen Prozeduren Auswahl der Bestimmungs-AVSC 120, AcquireChannel, CopyFrom und ReleaseChannel für eine oder für mehrere weitere Bestimmungs-AVSCs 120 wiederholen. Außerdem könnte der AVSM 160 eine AVSC 120, in der momentan eine Kopie der Datei liegt, als die Quell-AVSC 120 auswählen. Wenn die Rolle irgendeiner gegebenen AVSC als eine Dateiquelle abgeschlossen ist, gibt der AVSM 160 eine ReleaseChannel-Anforderung an diese Quell-AVSC 120 aus, die ihrerseits Betriebsmittel freigibt, die für die Ausführung der Kopieroperationen reserviert sind, und eine zu dem AVSM 160 gerichtete ReleaseChannelReply erzeugt. Der Fachmann auf dem Gebiet versteht, dass die Dateireplikationsoperationen eher über CopyTo-Anforderungen als über CopyFrom-Anforderungen ausgeführt werden könnten.
4.12.6 AVSS-Organisation
Der AVSM 160 unterhält Daten, die Betriebsmitteln der AVSC 120 und ihren Fähigkeiten entsprechen. Wenn eine neue AVSC 120 zu der Standortgruppe hinzugefügt worden ist, kann der AVSM eine AVSC 120 bei Bedarf oder als Teil einer AVSS-Datenbankaktualisierung abfragen. 25 ist ein beispielhaftes Anforderungsfolgediagramm, das den neuen AVSC-Hinzufügungs- und AVSC-Abfrageanforderungen entspricht. Der AVSM 160 gibt in Reaktion auf die Ausgabe einer AddAVSC-Anforderung eines berechtigten Clients, die eine AVSC 120 und eine Netz- oder IP-Adresse angibt, eine GetMediaSetup-Anforderung an die AVSC 120 aus. Die AVSC 120 erzeugt eine GetMediaSetupReply und liefert an den AVSM 160 Daten, die ihre Betriebsmitteltypen, -fähigkeiten und -eigenschaften beschreiben. Daraufhin gibt der AVSM 160 an den anfordernden Client eine AddAVSCReply aus. Der AVSM 160 liefert in Reaktion auf eine GetAVSCInfo-Anforderung von dem Client über eine GetAVSCInfoReply Daten an den Client, die die Betriebsmitteltypen, -fähigkeiten und -eigenschaften der AVSC beschreiben.
4.13 Anwendungsprogrammschnittstelle
Anwendungsprogramme, die in Anwender-Workstations 40 oder in anderen Computern ausgeführt werden, wirken in Bezug auf den AVSM 160 als Clients und können ferner in Bezug auf den A/V-Netz-Manager 34 als Clients wirken. 26 ist ein Blockdiagramm, das Clientanwendungsprogramme zeigt, die mit dem AVSM 160 und mit dem A/V-Netz-Manager 34 kommunizieren. In einer Ausführungsform umfasst ein typisches Anwendungsprogramm eine Anwenderschnittstelle zuzüglich einer Menge von Softwareobjekten, die auf der oben beschriebenen AVSMAppComm-Klassenhierarchie 250 beruhen oder von ihr abgeleitet worden sind. Somit dient das Anwendungsprogramm als ein Software-Wrapper, der als ein AVSM-Client wirken kann, um Zugriff auf bestimmte Typen der AVSS-Funktionalität bereitzustellen.
Ein Anwendungsprogramm gibt in Reaktion auf bestimmte Anwenderauswahlen oder -aktionen Anforderungen an den AVSM 160 aus. Das Anwendungsprogramm aktualisiert auf der Grundlage von von dem AVSM 160 empfangenen Antworten wahlweise Informationen, die dem Anwender dargestellt werden. Da ein Teil des Anwendungsprogramms der AVSMAppComm entsprechende Objekte umfasst, findet die Kommunikation zwischen dem AVSM 160 und dem Anwendungsprogramm auf analoge Weise wie die Kommunikation von einem AVSM zu einem AVSM statt. Da die AVSMAppComm leicht erweitert oder geändert werden kann, um die Entwicklung der AVSM-Funktionalität mit der Zeit zu widerspiegeln, kann sie außerdem leicht mit minimaler Anwendungsprogrammänderung an neue Funktionalitätstypen angepasst werden.
4.14 Prozess- und Datengrundelemente
Der Videospeicherserver kann mehrere Anwendungstypen unterstützen. Eine der Arten, auf die die mehreren unterstützten Anwendungen Informationen gemeinsam nutzen können sowie die zur Verkörperung der Anwendungen erforderliche Codierung eingeschränkt werden kann, ist die gemeinsame Nutzung einer Menge gemeinsamer "Grund"-Elemente zwischen den mehreren Anwendungen.
Grundelemente derselben Klasse sind kombinierbar, um ein angegebenes Ergebnis zu erzielen. Eines oder mehrere Grundelemente können kombiniert werden, um neue Grundelemente höherer Ebene zu bilden, die ihrerseits ein nochmals weiteres Grundelement noch höherer Ebene definieren können, im Wesentlichen ad infinitum. Es gibt zwei umfassende Klassen von Grundelementen: Prozessgrundelemente und Datengrundelemente.
Prozessgrundelemente werden aufgerufen, um eine Aktion auszuführen. Sie können ihrerseits weitere Aktionen einschließlich des Aufrufens weiterer Grundelemente aufrufen. Üblicherweise bauen Prozessgrundelemente AVSS-Sitzungen eines Typs auf (z. B. wenigstens eine zum Abspielen einer Datei, zum Erhalten von Dateilisten), stellen dem Anwender eine graphische Schnittstelle dar, bauen Netzverbindungen auf und führen weitere Operationen wie etwas das Rendern synchronisierter Graphiken aus. Beispiele für von den Prinzipien der vorliegenden Erfindung gelehrten Prozessgrundelemente sind Betrachter-, Browser- und Organisationsprozesse.
Prozessgrundelemente können auf eine Anzahl von Arten organisiert sein. Eine erste Art ist ein selbstständiger Prozess, der direkt durch einen Anwender gestartet wird. Alternativ können sie aus einem anderen Prozess heraus, z. B. aus einer Laufzeitbibliothek oder DLL heraus, gestartet werden. In diesem Fall existiert ihr Ausführungs-Thread mit dem Ausführungs-Thread des Startprozesses und wird ebenfalls mit ihm abgeschlossen. Als eine weitere Alternative können Prozessgrundelemente durch einen weiteren Prozess wie etwa durch einen getrennten Prozess, dessen Ausführungs-Thread nicht an den Startprozess gebunden ist, gestartet werden. In diesem letzteren Fall hat der Abschluss des Startprozesses keine Auswirkungen auf die Lebensdauer des Prozessgrundelements.
Es gibt mehrere umfassende Mechanismen für die Ausführung von Prozessgrundelementen. Eine Prozessgrundelement-Ausführungsmethodik implementiert den direkten Aufruf des Prozessgrundelements durch den Anwendungsanwender. Eine weitere Prozessgrundelement-Ausführungsmethodik wird dort genutzt, wo eine Zielanwendung einschließlich, aber nicht beschränkt auf, Drittanbieter-Softwareanwendungen zuvor gelehrt worden ist, wie ein Datengrundelement in Form eines Anhangs, MIME-Typs, Dateityps usw. anzuzeigen oder auf seinen Empfang zu reagieren ist. Der Empfang des Datengrundelements veranlasst, dass die Zielanwendung, z. B. die MIME-kompatible Softwareanwendung des Betriebssystems, ein dem Datengrundelement zugeordnetes Prozessgrundelement startet. Eine nochmals weitere Methodik für die Ausführung von Prozess grundelementen, insbesondere jenen Prozessgrundelementen, auf die direkt durch Drittanbietersoftware zugegriffen wird, ist einfach das Installieren des Prozessgrundelements als ein Plugin zu dieser Software.
Datengrundelemente nehmen im Kontext ihrer Nutzung durch Prozessgrundelemente oder andere verwandte Prozesse auf eine Anzahl spezifisch formatierter Dateitypen Bezug. Datengrundelemente enthalten, sind aber nicht notwendig beschränkt auf: Audio-Video-Dateien, reine Audiodateien, reine Videodateien, Bitmap-Dateien, Anwendungsdateien, Postskript-Dateien, Graphikdateien, Textdateien, und Synchronisationsdateien. In Synchronisationsdateien sind eine Anzahl zeitgestempelter Ereignisdateitypen enthalten einschließlich, jedoch wieder nicht beschränkt auf: Graphikereignisdateien, Shareboard-Ereignisdateien, Fensterereignisdateien, Anwendungsstartereignisdateien und Textereignisdateien. Die Zeitstempel in der Datei signalisieren, wann bestimmte definierte Maßnahmen zu ergreifen sind, was die zeitliche Synchronisation der Informationen einer Datei in Bezug auf eine andere ermöglicht.
Eine Metadatei ist eine Abstraktion, die eine Kombination eines oder mehrerer extern gespeicherter Datengrundelemente darstellt, die zusammen alle extern gespeicherten ("out-of-band") Informationen bilden, die ein bestimmtes AV- oder Multimedia-Segment (wie etwa eine Nachricht) umfassen. Der Metadatei ist eine Zeigerdatei zugeordnet, die alle Bezugnahmeninformationen für die verschiedenen Komponentendateien der Metadatei (Dateinamen, Berechtigungsschlüssel, Dateisysteme usw.) enthält. Eine oder mehrere Zeigerdateien und ihre zugeordneten Metadateien können konzeptionell gruppiert werden, um eine virtuelle Aggregatdatei zu bilden, die eine Omnidatei genannt wird. Somit muss die Omnidatei auf eine Weise erfolgreich von einer Umgebung in eine andere übertragen werden, damit berechtigte Informationen in der neuen Umgebung vollständig wiedergegeben werden. Wie dem Fachmann auf dem Gebiet klar ist, kann dies auf eine Anzahl von Arten erfolgen. Eine solche Ausführungsform ist in 27 gezeigt.
In der üblichen Praxis wird der Begriff "Multimedia-Datei" zur Bezugnahme auf ein Aggregat aller Typen von Mediendateien und von Zeigern auf externe Referenzdateien verwendet. Multimedia-Dateien sind wie Metadateien und tatsächlich wie andere Grundelemente hierarchisch: Sie sind, z. B. wie eine Multime dia-Datei in irgendeiner einer Anzahl von Standardformaten, zu weiteren Dateien kombinierbar, um eine bestimmte Aufgabe auszuführen. Metadateien, wie sie hier definiert sind, dürfen über mehrere Dateisysteme verteilt sein und enthalten keine Zeigerdateien. Im Gegensatz dazu können Multimedia-Dateien Zeigerdateien enthalten und werden alle ihre Komponenten-Mediendateien zusammen gespeichert. Omnidateien enthalten Zeigerdateien, sind aber wieder ein virtuelles Objekt, das sich potentiell über mehrere Dateisysteme erstreckt und somit ebenfalls von Multimedia-Dateien unterscheidet.
Eine Anwendung, die die Prinzipien der vorliegenden Erfindung implementiert, nimmt spezifisch einige der interessierenden Dateitypen und erzeugt einen ihnen zugeordneten MIME-Typ. Daraufhin ermöglicht sie, einige Drittanbieter-Browser einschließlich, aber nicht beschränkt auf, Netscape^® oder Microsoft Internet Explorer^® oder einige E-Mail-Pakete einschließlich Eudora^® zu lehren, wie die MIME-Typen zu behandeln sind. Dementsprechend werden viele der durch die vorliegende Erfindung unterstützten Drittanbieteranwendungstypen gelehrt, wie die Multimedia-Dateien, Omnidateien, Metadateien, Audio-Video-Dateien und Zeigerdateien der vorliegenden Erfindung zu behandeln sind. Wenn eine Drittanbieteranwendung einen dieser durch die vorliegende Erfindung gelehrten Dateitypen empfängt, weiß sie somit, wie das richtige Prozessgrundelement aufzurufen ist.
Nunmehr anhand von 28 ist ein beispielhaftes Datengrundelement 3904 gezeigt, das einen Betrachter- oder Browser-Prozess erfordert, um es anzuzeigen oder auf es einzuwirken. Die Anwendung ist wie oben beschrieben gelehrt worden, wie sie auf den Empfang des Datengrundelements reagieren soll, sie "weiß", wann und wie die Prozessgrundelemente 3912 und 3906 zu starten sind. In dem hier dargestellten Betrachter/Browser-Exemplar veranlasst der Empfang des Datengrundelements 3904 durch eine Anwendung, dass die Anwendung bei 3910 oder 3914 entweder den Browser 3912 oder den Betrachter 3906 startet. Wenn der Browser 3912 gestartet wird, kann er mehrere, nicht gezeigte, Betrachter 3906 aufrufen. Ein Betrachter 3906 ruft seinerseits wenigstens ein Datengrundelement 3908 für den Zugriff auf eine oder mehrere Dateien auf.
Nunmehr anhand von 29 ist ein Datengrundelement 3904 als ein Anhang, z. B. als ein MIME-Anhang, zu einer Nachricht 3902 verkörpert gezeigt. Als Veranschaulichung, jedoch nicht als Beschränkung, könnte die Nachricht 3902 eine E-Mail-Nachricht, ein Textverarbeitungsdokument, ein Textdokument usw. sein. Der Anhang kann je nach der Anwendung als der zuvor diskutierte MIME-Anhang oder als ein Dateityp implementiert sein. Wenn die Anwendung angewiesen wird, den Anhang zu bearbeiten, ruft sie wie zuvor diskutiert das dem Anhangstyp zugeordnete Prozessgrundelement auf.
Selbstverständlich ist die unmittelbar vorangehende Diskussion des Betrachter/Browser-Prozessgrundelements zu Veranschaulichungs- und nicht zu Beschränkungszwecken dargestellt worden. Die Prinzipien der vorliegenden Erfindung umfassen eine fast unbeschränkte Anzahl von Prozessgrundelementkonfigurationen, von denen das vorstehende Beispiel nur eines ist. Die Lehren der vorliegenden Erfindung betrachten spezifisch alle solche Konfigurationen.
4.14.1 Betrachter
Videoaufzeichnungs- und Videowiedergabefähigkeiten können durch selbstständige Mittel getrennt in jede Anwendung eingebettet sein, wobei aber vorzugsweise ein standardisiertes Videoaufzeichnungs/Wiedergabe-Hilfsmittel erwünscht ist, das über mehrere Anwendungen verwendet wird. Somit ist ein Betrachter ein guter Kandidat für ein Prozessgrundelement und wird hier als ein Beispiel der Verwendung von Prozessgrundelementen, wie sie durch die Prinzipien der vorliegenden Erfindung gelehrt wird, erläutert.
Das Betrachterprozessgrundelement richtet, wie zuvor beschrieben, die notwendigen Verbindungen und Sitzungen ein, bereitet die Dateien auf die Betrachtung vor und stellt die notwendige Betrachterschnittstelle bereit, um zu ermöglichen, dass der Anwender, sofern zugelassen, auf die Dateien zugreift und sie manipuliert. Da der Betrachter ein Standardvideoaufruf ist, kann er wie irgendein anderer Videoaufruf behandelt werden. Dies ermöglicht, dass er auf ähnliche Weise wie irgendeine andere durch die Prinzipien der vorliegenden Erfindung ermöglichte Sitzung mit anderen Videoaufrufen, -konferenzen und dergleichen zusammengeführt wird.
Die Implementierung dieses Merkmals der vorliegenden Erfindung ist in 29 offenbart. Mit Bezug auf diese Figur betrachtet die vorliegende Erfindung die Nutzung eines Shell-Dokuments 3902, das z. B. durch eine Anwendung in der MCG (nicht gezeigt) aufgerufen wird. Ein Beispiel einer solchen Anwendung wäre der Start einer Video-Mail-Sitzung, einer Videokonferenzsitzung oder im Wesentlichen irgendeiner der hier diskutierten weiteren Anwendungen. In das Shell-Dokument 3902 ist ein MIME-Anhang 3904 eingebettet. Der MIME-Anhang 3904 ruft den Betrachter 3906 auf, der ermöglicht, dass der Anwender nach Bedarf über das Netz auf das AVSS zugreift, um Videodateien 3908 aufzuzeichnen oder wiederzugeben. Die Genehmigungen zum Aufzeichnen oder Wiedergeben spezifischer Videodateien müssen für den Anwender, der auf die Anwendungen zugreift, vorhanden sein. Die gemeinsam genutzte Verbindung bei 3910 stellt den neuen Vorteil dar, der die Videoaufzeichnung oder -wiedergabe und ihre Kombination mit anderen gleichzeitig in einer getrennten Sitzung ablaufenden Anwendungen ermöglicht. In einigen Anwendungen ist ein Browser 3912 vorgesehen, der ermöglicht, dass der Anwender zwischen einer Anzahl von Anwendungen 3906 auswählt. Alternativ kann der Browser 3912 in den Betrachter 3906 eingebettet oder ein Teil von ihm sein.
4.14.2 MIME-Anhang
Da der Betrachter über alle Anwendungen gemeinsam ist und da die mehreren Anwendungen auf die Dateien, die er aufruft, zugreifen können, kann eine erste Anwendung den Betrachter zum Aufzeichnen oder Wiedergeben einer Datei verwenden und kann eine zweite Anwendung den Betrachter für Video-Mail oder im Wesentlichen für irgendeine andere Anwendung nutzen. Dementsprechend sind die Videodateien auf der Dateiebene, auf der Anhangs- oder MIME-Ebene oder auf der Verbindungsebene gemeinsam nutzbar. Die Nutzung von MIME-Anhängen (Multipurpose-Internet-Mail-Extensions-Anhängen) ermöglicht den Aufruf des Betrachters und seiner zugeordneten Netzverbindungen in einem standardisierten Anhang, der von Drittanbietern in Übereinstimmung mit Standard-MIME-Protokollen akzeptiert wird. Somit sind die mehreren in der vorliegenden Erfindung gelehrten Anwendungen mittels der gemeinsamen Dateinutzung durch das Kopieren von MIME-Anhängen oder durch die gemeinsame Verbindungsnutzung interoperabel.
4.14.3 Synchronisiertes Shareboard
Ein Beispiel einer solchen gleichzeitigen Sitzung würde die gleichzeitige Implementierung von Shareboard-Graphik und einer Videokonferenzsitzung ermöglichen.
Die Hinzufügung der Multimedia-Synchronisationsfähigkeit zu dem zuvor diskutierten Betrachter und zu der zuvor diskutierten MIME-Implementierung ermöglicht, dass die mehreren zuvor diskutierten Videoanwendungen animierte Graphikdateien enthalten, die mit dem Video synchronisiert sind. Die durch die Prinzipien der vorliegenden Erfindung gegenwärtig implementierten Mehrfachnutzungsfähigkeiten "ergreifen" ein Fenster und speichern es als eine Bitmapdatei, was ermöglicht, dass der Anwender auf die Bitmapdatei zeichnet. Dies ermöglicht, dass das durch zwei oder mehr Anwender zu verwendende Dokument, das Überlagerungsgraphik umfasst, zur späteren synchronen Wiedergabe gespeichert und synchronisiert wird.
Die Synchronisation wird wie folgt erläutert: Wenn die zwei oder mehr Anwender eine Videokonferenz durchführen, wird ein erstes Fenster geöffnet und darin eine Bitmail überlagert. Irgendwelche in das Fenster oder in die Bitmail gelesenen Dateien können zeitgestempelt sein. Irgendwelche Animationen, die der Bitmail überlagert werden, sind Zeichenlistenereignisse, die ebenfalls zeitgestempelt sein können. Gemäß den Prinzipien der vorliegenden Erfindung wird die Erfassung der mehreren während der Multimedia-Aufzeichnung aufgerufenen Zeitstempel betrachtet. Dies ermöglicht die spätere Synchronisation der mehreren Dateien während der Wiedergabe, um eine synchrone Ansicht der gesamten Sitzung darzustellen. Wenn eine Videokonferenz N Anwender enthält, kann die aufgezeichnete Version der synchronisierten Sitzung als der N + 1-te Anwender betrachtet werden. Bei der Wiedergabe wird die aufgezeichnete Version der Sitzung erneut wie irgendein weiterer Anwender behandelt.
Der zuvor diskutierte Aufzeichnungsprozess ist im Wesentlichen die sequentielle Aufzeichnung einer Folge von Ereignissen. Wenn es erwünscht ist, dass die zuvor aufgezeichneten Ereignisse umkehrfähig sind, ist es notwendig, die Graphik in der Weise zu rendern, dass sie umkehrfähig ist. Ähnlich ist es dann, wenn das System "Go-To"s ermöglicht, notwendig, die Graphik in der Weise zu rendern, dass das gerenderte Bild zum Abrufen bei angegebenen "Go-To"-Punkten fähig ist.
Nun besteht die Fähigkeit, irgendeinen Bildschirm in dem Fenster zuzuteilen und ihn mit irgendeinem Anwender oder mit irgendeiner freigegebenen Speichervorrichtung gemeinsam zu nutzen.
Gemeinsam genutzte Anwendungen (nicht selbstverständlich). Das Aufzeichnen gemeinsam genutzter Anwendungen wird mit ähnlichen Mitteln wie die Bitmaperfassung ausgeführt.
Wo auf dem Videofenster Anmerkungen auftreten, die Überlagerungen zeichnen, müssen die Workstations die Fähigkeit haben, auf dem Video eine Graphiküberlagerung auszuführen.
4.14.4 Browser
Der oben erwähnte Browser kann durch den Fachmann auf dem Gebiet auf ähnliche Weise wie bisher beschrieben ebenfalls so angepasst werden, dass er als ein Prozessgrundelement wirkt.
4.15 Anwendungsübersicht
Die vorliegende Erfindung lehrt eine Anzahl neuer Softwareanwendungen, die durch das und zur Verwendung in Verbindung mit dem zuvor diskutierten Videoserversystem oder AVSS ermöglicht werden. Da die vorliegende Erfindung die Implementierung ihrer Merkmale auf skalierbare Weise ermöglicht, schaffen die Programmelemente der vorliegenden Erfindung neben weiterem Nutzen die Fähigkeit zum Skalieren der hier dargestellten Merkmale und Vorteile über einen weiten Bereich von Hardwareimplementierungen. Eine Übersicht einer solchen Hardwareimplementierung ist in 30 gezeigt.
Die vorliegende Erfindung schafft zwei umfassende Klassen von Speicheranwendungen. Jene, die nur den grundlegenden Audio- und Videoaufzeichnungsfähigkeiten, -speicherfähigkeiten, -Browsing-Fähigkeiten und -wiedergabefähigkeiten des momentanen AVSS nutzen, werden im Folgenden als "Video"-Anwendungen bezeichnet. Dies ist üblicherweise eine preiswertere Implementierung mit verringerter Fähigkeit. Eine zweite Klasse von Anwendungen nutzt Audio und Video zusammen mit einer synchronisierten Datenmehrfachnutzungsfähigkeit, z. B. mit synchronisierten Aufzeichnungs-, Speicherungs-, Browsing- und Wiedergabemerkmalen eines Shareboard/T.120. Solche Fähigkeiten sind wesentlich für das Aufzeichnen von Konferenzen, Nachrichten oder Präsentationen, bei denen Informationen nicht zweckmäßig durch Audio und Video allein übermittelt werden können. Diese Klasse von Speicheranwendungen wird im Folgenden als "Multimedia"-Anwendungen bezeichnet. Die durch diese Anwendungsklasse bereitgestellte zusätzliche Funktionalität kann etwas höhere Implementierungskosten erfordern.
Die Prinzipien der vorliegenden Erfindung betrachten, dass das AVSS mehrere Anwendungstypen unterstützt. Eine Art, in der die mehreren Anwendungen Informationen gemeinsam nutzen können, ist die gemeinsam Nutzung gemeinsamer "Grund"-Elemente Dies hat den zusätzlichen Vorteil, die zur Verkörperung dieser Anwendungen, die Grundelemente nutzen, erforderliche Codierung einzuschränken. Dementsprechend können eine oder mehrere der von der vorliegenden Erfindung gelehrten Anwendungen gemeinsam genutzte Grundelemente nutzen, um den Austausch von Informationen zwischen Anwendungen oder Anwendungselementen zu ermöglichen. Alternativ können eine oder mehrere dieser Anwendungen als eine "selbstständige" oder "einmalige" Implementierung implementiert sein, die keine gemeinsam genutzten Grundelemente nutzt.
4.16 Videoanwendungen
Wie zuvor erwähnt wurde, kann ein AVSS mehrere Anwendungstypen unterstützen. Einige dieser Anwendungen umfassen veranschaulichend, aber nicht einschränkend, eine Video-Mail-Anwendung, die auf neue Weise Videoclips oder -dateien mit E-Mail-Nachrichten kombiniert, wobei ein Anwender eine ausführliche Audio-Video-Nachricht im E-Mail-System eines weiteren Anwenders hinterlassen kann. Video-Mail ist wie E-Mail, jedoch entweder mit einem Videoanhang oder mit einer Videodatei, der/die den normalen E-Mail-Text vollkommen ersetzt. Die Reichhaltigkeit und die Tiefe der dadurch geschaffenen Kommunikation ermöglichen einen wesentlich höheren Informationsaustausch, als er durch einfache Sprach-Mail-Mitteilungsübermittlung verfügbar ist. Das durch die vorliegende Erfindung gelehrte Videoanrufbeantwortersystem beantwortet die E-Mail eines Anwenders, wenn der Anwender fort ist oder auf andere Weise belegt ist. Diese Anwendung bietet dem Anwender die Option, Anrufer auf eine Anzahl von Arten zu begrüßen und als Antwort ihre Videonachrichten zu empfangen. Eine Alternative dieser Anwendung betrachtet ihre Implementierung unter Verwendung der zuvor diskutierten Video-Mail-Anwendung. Die Videokonferenzaufzeichnung ermöglicht, dass mehrere Anwender eine aufgebaute Videokonferenz in Echtzeit aufzeichnen. Diese Anwendung kann auf Befehl des Anwenders aufgerufen werden oder kann alternativ automatisch aufgerufen werden, wenn bestimmte Konferenzparameter erfüllt sind.
Außer diesen auf elektronische Treffen orientierten Anwendungen ermöglicht die Architektur des hier beschriebenen AVSS-Systems mit Leichtigkeit mehrere zusätzliche Fähigkeiten. Eine solche Fähigkeit ist die Nutzung der vorliegenden Erfindung als eine allgemeine Audio-Video-Speichervorrichtung. Diese Fähigkeit ermöglicht, dass Anwender Audio-Video-Dateien in einer Vielzahl von Formaten speichern und zu Anwendern im gesamten LAN oder WAN weiterleiten. Die Konnektivität solcher Netze zum Internet schafft die zusätzliche Fähigkeit des Systems als ein Intranet- oder Internet-Gateway für die Audio-, Video-, Audio-Video- oder Multimedia-Dateiübertragung. Eine weitere Anwendung ist die Videoveröffentlichung, die ermöglicht, dass irgendeiner einer Anzahl von Systemanwendern komplexe, informationsreiche Audio-Video-Dokumente erzeugt, editiert, speichert und mittels LAN, WAN an eine breite Vielzahl von Empfängern oder unter Nutzung des Internet an ein weltweites Publikum verteilt.
4.16.1 Video-Mail
Eine erste durch die Prinzipien der vorliegenden Erfindung ermöglichte Videoanwendung ist die Video-Mail. In einer ersten Ausführungsform dieser Anwendung wird durch existierende MIME-gestützte Mail-Systeme eine "Videoanhangs"-Fähigkeit bereitgestellt. Alternativ kann Video-Mail auch durch weitere Anhangsstrategien ohne Anhänge oder als eine vollentwickelte selbstständige Anwendung, die sich nicht auf irgendein zugrundeliegendes kommerzielles E-Mail-Paket stützt, implementiert werden.
In einer ersten Ausführungsform der vorliegenden Erfindung nutzt ein Videoanhang das im Folgenden beschriebene allgemeine Videospeicher- und Sitzungsaufbauverfahren. Darüber hinaus nutzt dieses Hilfsmittel die im Folgenden diskutierte allgemeine MIME-Video-Anhangs-Methodik. Im Gegensatz zu der im US-Patent Nr. 5.617.539 gelehrten Video-Mail-Methodik, die direkt auf der Workstation des Anwenders eine Betriebsartsteuerungs-GUI (oder "MCG") startet, setzt eine durch die vorliegende Erfindung dargestellte alternative Ausführungsform einen "MCG"-Merker so, dass das AVSS auf der Workstation des Anwenders eine MCG startet. Das Mail-Verfassen ruft die Anforderung für eine Sitzung mit einem Codierer/Decodierer-Paar auf, während das Mail-Lesen die Anforderung für eine Sitzung nur mit einem Decodierer aufruft.
Die Prinzipien der vorliegenden Erfindung betrachten ihre Implementierung in einer breiten Vielfalt von Hardwareimplementierungen. Im einfachsten Fall dient ein einfaches AVSS sowohl dem eine Nachricht verfassenden Anwender als auch dem Nachrichtenempfänger. In dieser Implementierung gibt es keine Dateiübertragungen, die aus dem AVSS erforderlich sind. Dateien können aus anderen Gründen aus dem AVSS übertragen werden, wobei es aber in diesem Fall keinen funktionalen Grund gibt, dass die Dateien in einem anderen AVSS liegen. Dies könnte als eine LAN-Implementierung der Prinzipien der vorliegenden Erfindung betrachtet werden.
Wenn eine gegebene Organisation ausreichend groß oder geographisch so verteilt ist, dass ein einzelnes AVSS den Verkehr für alle seine Anwender nicht behandeln kann, können mehrere AVSSs implementiert werden. Dieser Fall hat zwei Unterfälle: Der erste Unterfall ist eine WAN-Implementierung und der zweite liegt dort vor, wo die Implementierung bei einem gegebenen Standort, z. B. bei einem großen Campus, so groß ist, dass sie mehr als ein AVSS erfordert. In dem zweiten Unterfall sind die mehreren AVSS durch eine Verbindungsleitung 16 zwischen den Vermittlungen 32 und/oder dem lokalen Daten-LAN 20 miteinander verbunden. Wenn eine Datei in dem zweiten Unterfall in einem anderen AVSS als dem aufzeichnenden AVSS erforderlich ist, wird sie einfach über die lokale Zusammenschaltungsumgebung 16 und 20 übertragen. Im ersten Unterfall, der die Übertragung verhältnismäßig großer Dateien von einem AVSS zu einem anderen erfordert, kann diese Implementierung vermittelte WAN-Dienste, Frame Relay oder eine oder mehrere ihrer funktionalen Äquivalente verwenden. Da darüber hinaus für diese Übertragungen so viel Bandbreite erforderlich sein kann, kann es notwendig sein, Bandbreitenmanagementlösungen bereitzustellen. Beispiele solcher Netzbandbreitenmanagementlösungen enthalten, sind aber nicht spezifisch beschränkt auf, die Durchführung von Dateiübertragungen zu Nicht-Spitzenzeiten, die Durchführung von Dateiübertragungen auf präemptive Weise und weitere Bandbreitensparverfahren, die für den Durchschnittsfachmann auf dem Gebiet bekannt oder offensichtlich sind. Wenn Dateiübertragungen auf präemptive Weise durchgeführt werden, kann die Dateiübertragung, wenn ein Anwender eine Aktion höherer Priorität initiiert, wenn er z. B. eine Videokonferenz initiiert, unterbrochen, d. h. abgebrochen, angehalten und nach der Anwendung hoher Priorität neu gestartet werden usw.
Nunmehr anhand von 31 ist der Translationsfluss zwischen Anwendungselementen gezeigt, die eine lokale oder LAN-Implementierung der Video-Mail ermöglichen, wobei eine Mail-Nachricht, die eine Videonachricht enthält, von demselben AVSS sowohl aufgezeichnet als auch gelesen wird. Wenn der Anwender, weiter anhand von 31, bei 1401 eine neue E-Mail-Nachricht initiiert, fragt das Quell-E-Mail-System 1402 bei 1406 ab, ob der Anwender einen Videoanhang an die E-Mail anhängen möchte. Wenn der Anwender einen Videoanhang mit der E-Mail-Nachricht einreichen möchte, wird bei 1412 eine Video-Verfassen-Anforderung an die Video-Mail-Anwendung 1420 initiiert. Die Video-Mail-Anwendung 1420 erzeugt bei 1422 einen eindeutigen Videodateinamen und fordert bei 1420 eine Codierungssitzung von dem aufzeichnenden AVSS 1430 an. Daraufhin wird die Audio-Video-Datei im AVSS 1430 aufgezeichnet. Bei 1432 gibt das AVSS 1430 den Videoanhang an die Video-Mail-Anwendung 1420 zurück. Bei 1434 stellt die Video-Mail-Anwendung 1420 ihrerseits den Dateinamenzeiger für ein E-Mail-Programm 1402 ein. Wenn die E-Mail-Nachricht und der Videoanhang fertiggestellt worden sind, sendet der Anwender die E-Mail bei 1408 z. B. unter Verwendung des SMTP-Protokolls 1410 durch Initiieren der Sendeprozedur. Wenn die Sendeprozedur 1408 initiiert worden ist, initiiert das E-Mail-Programm 1402 bei 1414 eine Benachrichtigung an die Video-Mail-Anwendung 1420, an die die Nachricht gesendet worden ist. Daraufhin weist die Video-Mail-Anwendung 1420 das AVSS 1430 bei 1426 an, die Codierungssitzung freizugeben.
An diesem Punkt ist die in dieser Figur nicht gezeigte E-Mail-Nachricht selbst auf normale Weise zu dem Anwender gesendet worden, wobei die aufgezeichnete A/V-Datei in dem AVSS 1430 liegt. Wenn das E-Mail-Programm 1402 bei 1492 die E-Mail-Nachricht empfängt, sendet es bei 1460 eine Empfangsziel- und Informationsanforderung an die Video-Mail-Anwendung 1420. Bei 1472 extrahiert die Video-Mail-Anwendung 1420 in Reaktion auf die Empfangsziel- und Informationsanforderung 1460 eine Quell-AVSS-Adresse. Daraufhin stellt die Video-Mail-Anwendung 1420 eine Dateiübertragungsanforderung 1480 an das AVSS 1430.
Das AVSS 1430 bestätigt in Reaktion auf die Anforderung 1480, dass es die angeforderte A/V-Datei bereits besitzt, und bestätigt bei 1448, dass die Videodateiübertragung abgeschlossen ist. Nachdem die A/V-Datei empfangen worden ist, gibt die Video-Mail-Anwendung 1420 die Mail-Nachricht bei 1474 in Reaktion auf die Dateiübertragungsbestätigung 1448 frei. Daraufhin gibt die Video-Mail-Anwendung 1420 die Mail-Nachricht bei 1462 zu dem E-Mail-System 1402 frei.
An diesem Punkt stellt das E-Mail-System 1402 die Mail bei 1494 für den Anwender zur Verfügung. Die Schritte 1494 und 1460 stellen in funktionaler Kombination sicher, dass der Anwender erst über eine Nachricht mit einem zugeordneten Videoanhang benachrichtigt wird, wenn der Videoanhang ankommt. Wenn der Anwender den Videoanhang bei 1496 öffnet, initiiert das E-Mail-System 1402 ein Anhangöffnungsereignis und setzt bei 1464 einen Dateizeiger auf die Video-Mail-Anwendung 1420. Bei 1476 öffnet die Video-Mail-Anwendung 1420 in Reaktion auf den gesetzten Dateizeiger 1464 einen Betrachter und bereitet sich auf die Decodierung der AV-Datei vor. Bei 1482 erfordert die Video-Mail-Anwendung 1420 vom AVSS 1430 ihrerseits eine Decodierungssitzung an. Die Decodierung der A/V-Datei durch das AVSS 1430 stellt die Datei für den Anwender zur Verfügung.
Wenn der Anwender bei 1498 die Nachricht oder den Videoanhang schließt, wird bei 1466 ein Nachrichten/Anhangs-Betrachtungs- und Dateizeiger-Schließereignis initiiert. Dieses veranlasst, dass die Video-Mail-Anwendung 1420 die Betrachtung bei 1478 freigibt und die Datei freigibt. Bei 1484 gibt die Video-Mail-Anwendung 1420 in Reaktion auf das Freigabeereignis 1478 einen Decodie rungssitzungs-Freigabebefehl an das AVSS 1430 aus. Wenn der Anwender bei 1493 entweder die Nachricht oder ihren Videoanhang löscht, initiiert das E-Mail-System 1402 ein Nachrichten/Anhangs-Löschereignis 1468 zur Video-Mail-Anwendung 1420. In Reaktion auf dieses Ereignis löscht die Video-Mail-Anwendung 1420 bei 1473 einen Inhaber der Datei und gibt bei 1486 das Anwendereigentum der Datei an das AVSS 1430 frei. Alternativ kann eine Videodatei natürlich so eingestellt sein, dass sie nach einer im Voraus zugewiesenen Lebensdauer abläuft.
Es wird angemerkt, dass die Empfangsziel- und Informationsanforderung 1460, die Mail-Freigabenachricht 1462, das Nachrichten/Anhangs-Betrachtungs- und Dateizeiger-Schließereignis 1466 und das Nachrichten/Anhangs-Löschereignis 1468, wie sie durch diese Erfindung gelehrt werden, neue Konzepte sind und somit durch irgendwelche bekannten umfassend verfügbaren E-Mail-Domänenserver nicht unterstützt werden. Die Untersuchung der hier offenbarten Prinzipien macht für den Durchschnittsfachmann auf dem Gebiet offensichtlich, dass zusätzliche Dialoge und Anzeigen in der Video-Mail-Anwendung die durch die zuvor aufgeführten Nachrichten gelieferten Informationen bereitstellen können. Ferner sind natürlich eine Vielzahl alternativer Implementierungen möglich, wobei sie die Lehren der vorliegenden Erfindung für den Fachmann auf dem Gebiet klar machen. Diese Alternativen enthalten Hilfskonstruktionen für die Abwesenheit von 1460, 1462, 1466 und 1468 einzeln oder insgesamt; z. B. könnte die Nichtverfügbarkeit von 1468 durch eine Dateilebensdauer-Überwachungseinrichtung behandelt werden, die nach einer bestimmten Inaktivitätsperiode eine Maßnahme zur Löschung einer Datei ergreift.
Nunmehr anhand von 32 ist der Transaktionsfluss zwischen Anwendungselementen gezeigt, die die Weitverkehrs-Video-Mail ermöglichen, wobei eine Mail-Nachricht, die eine Videonachricht enthält, von einem Aufzeichnungs- oder Quell-AVSS 1430 zu einem Ziel-AVSS 1450 gesendet wird.
Wenn der Anwender bei 1404 eine neue E-Mail-Nachricht initiiert, fragt das Quell-E-Mail-System 1402 bei 1406 ab, ob der Anwender einen Videoanhang an die E-Mail anhängen möchte. Wenn der Anwender einen Videoanhang mit der E-Mail-Nachricht einreichen möchte, wird bei 1412 eine Video-Verfassen- Anforderung an das Video-Mail-Anwendungsprogramm 1420 initiiert. Das Video-Mail-Anwendungsprogramm 1420 erzeugt bei 1422 einen eindeutigen Videodateinamen und fordert bei 1424 von dem aufzeichnenden AVSS 1430 eine Codierungssitzung an. Daraufhin wird der Videoanhang in dem aufzeichnenden AVSS 1430 aufgezeichnet. Daraufhin gibt das AVSS 1430 den Videoanhang 1432 an die Video-Mail-Anwendung 1420 zurück. Das Video-Mail-Anwendungsprogramm 1420 setzt seinerseits bei 1434 den Videodateinamenzeiger für das Quell-E-Mail-Programm 1402. Wenn das E-Mail-Programm und der Videoanhang abgeschlossen worden sind, sendet der Anwender die E-Mail bei 1408, z. B. unter Verwendung des SMTP-Protokolls 1410, durch Initiieren der Sendeprozedur. Wenn die Sendeprozedur 1408 initiiert worden ist, initiiert das Quell-E-Mail-Paket 1402 bei 1414 eine Benachrichtigung an die Video-Mail-Anwendung 1420, dass die E-Mail-Nachricht gesendet worden ist. Daraufhin weist die Video-Mail-Anwendung 1420 das aufzeichnende AVSS 1430 bei 1426 an, die Codierungssitzung freizugeben.
An diesem Punkt ist die in dieser Figur nicht gezeigte E-Mail-Nachricht selbst unter Nutzung normaler SMTP-Methodik an ein entferntes AVSS gesendet worden, während die codierte A/V-Datei im aufzeichnenden AVSS 1430 liegt. Wenn die E-Mail-Nachricht bei 1492 empfangen wird, wird in der Ziel-E-Mail-Domäne 1490 eine Empfangsziel- und Informationsanforderung 1460 an die Ziel-Video-Mail-Anwendung 1470 gesendet. Bei 1472 extrahiert die Ziel-Video-Mail-Anwendung 1470 in Reaktion auf die Empfangsziel- und Informationsanforderung 1460 die Quell-AVSS-Adresse. Daraufhin sendet die Ziel-Video-Mail-Anwendung 1470 dem Ziel-AVSS 1450 eine Dateiübertragungsanforderung 1480. Dies initiiert seinerseits die Anforderung 1481 für die A/V-Datei zum aufzeichnenden AVSS 1430 durch das Ziel-AVSS 1450.
Bei 1436 überträgt das aufzeichnende AVSS 1430 die A/V-Datei zu dem Ziel-AVSS 1450. Bei 1448 bestätigt das Ziel-AVSS 1450 für die Ziel-Video-Mail-Anwendung 1470, dass die Videodateiübertragung abgeschlossen ist. Nachdem die A/V-Datei empfangen worden ist, gibt die Ziel-Video-Mail-Anwendung 1470 die Mail-Nachricht bei 1474 in Reaktion auf die Dateiübertragungsbestätigung 1448 frei. Daraufhin gibt die Ziel-Video-Mail-Anwendung 1470 die Mail-Nachricht bei 1462 zu der Ziel-E-Mail-Domäne 1490 frei.
An diesem Punkt macht die Ziel-E-Mail-Domäne 1490 die Mail bei 1494 für den Anwender verfügbar. Die Schritte 1494 und 1460 stellen in funktionaler Kombination sicher, dass der Anwender erst über eine Nachricht mit einem zugeordneten Videoanhang benachrichtigt wird, wenn der Videoanhang ankommt. Wenn der Anwender bei 1496 den Videoanhang öffnet, initiiert die Ziel-E-Mail-Domäne 1490 ein Anhang-Öffnen-Ereignis und setzt bei 1464 einen Dateizeiger auf die Ziel-Video-Mail-Anwendung 1470. Bei 1476 öffnet die Ziel-Video-Mail-Anwendung 1470 in Reaktion auf den gesetzten Dateizeiger 1464 eine Ansicht und bereitet sich auf die Decodierung der Datei für den Anwender vor. Bei 1482 fordert die Ziel-Video-Mail-Anwendung 1470 ihrerseits eine Decodierungssitzung von dem Ziel-AVSS 1450 an. Die Decodierung der A/V-Datei durch das Ziel-AVSS 1450 stellt die Datei für den Anwender zur Verfügung.
Wenn der Anwender bei 1498 die Nachricht oder den Videoanhang schließt, wird bei 1466 ein Nachrichten/Anhangs-Betrachtungs- und Dateizeigerschließereignis initiiert. Dieses veranlasst, dass die Ziel-Video-Mail-Anwendung 1470 bei 1478 die Ansicht freigibt und die Datei freigibt. Bei 1484 gibt die Ziel-Video-Mail-Anwendung 1470 in Reaktion auf das Freigabeereignis 1478 einen Decodierungssitzungs-Freigabebefehl an das Ziel-AVSS 1450 aus. Wenn der Anwender bei 1493 entweder die Nachricht oder ihren Videoanhang löscht, initiiert die Ziel-E-Mail-Domäne 1490 ein Nachrichten/Anhangs-Löschereignis 1468 zur Ziel-Video-Mail-Anwendung 1470. Bei 1473 löscht die Ziel-Video-Mail-Anwendung 1470 einen Inhaber der Datei und bei 1486 gibt sie das Anwendereigentum der Datei an das Ziel-AVSS 1450 frei. Natürlich können Videodateien alternativ nach einer im Voraus zugewiesenen Lebensdauer ablaufen.
Es wird angemerkt, dass die durch diese Erfindung gelehrte Empfangsziel- und Informationsanforderung 1460, die Mail-Freigabenachricht 1462, das Nachrichten/Anhangs-Betrachtungs- und Dateizeiger-Schließereignis 1466 und das Nachrichten/Anhangs-Löschereignis 1468, die durch diese Erfindung gelehrt werden, neue Konzepte sind und somit durch irgendwelche bekannten umfassend verfügten E-Mail-Domänenserver nicht unterstützt werden. Die Untersuchung der hier offenbarten Prinzipien macht für den Durchschnittsfachmann auf dem Gebiet offensichtlich, dass zusätzliche Dialoge und Anzeigen in der Video-Mail-Anwendung die durch die zuvor aufgeführten Nachrichten gelieferten Informatio nen bereitstellen können. Ferner ist natürlich eine Vielzahl alternativer Implementierungen möglich, wobei sie die Lehren der vorliegenden Erfindung für den Fachmann auf dem Gebiet klar machen. Diese Alternativen enthalten Hilfskonstruktionen für die Abwesenheit von 1460, 1462, 1466 und 1468 einzeln oder insgesamt; z. B. könnte die Nichtverfügbarkeit von 1468 durch eine Dateilebensdauer-Überwachungseinrichtung behandelt werden, die nach einer bestimmten Inaktivitätsperiode eine Maßnahme zum Löschen einer Datei ergreift.
Das oben diskutierte und in 32 veranschaulichte Beispiel stellt eine Weitverkehrsimplementierung der vorliegenden Erfindung unter Nutzung zweier Systeme, 1400 und 1440, dar. In der Figur ist eine erste Methodik gezeigt, wobei zwei oder mehr Instanzen eines herkömmlichen elektronischen Mail-Systems, zwei oder mehr AVSS und zwei oder mehr Instanzen einer einfachen Video-Mail-Softwareanwendungs-"Middleware" zum Erzeugen eines WAN-fähigen Mehr-AVSS-Video-Mail-Systems verwendet werden können. Diese verhältnismäßig einfache Netzimplementierung ist hier zur Klarheit dargestellt. Die Untersuchung der hier offenbarten Prinzipien macht für den Durchschnittsfachmann auf dem Gebiet offensichtlich, dass eine Anzahl von Zielsystemen 1440 ähnlich implementiert sein können. Durch die Prinzipien der vorliegenden Erfindung werden alle solche Implementierungen spezifisch betrachtet.
In den 33 und 34 sind die neuen Konzepte des Dateieigentums und des Videonachrichten-Lebenszyklus gezeigt. In mehreren der hier gelehrten Anwendungen einschließlich Video-Mail entwickelt sich das Dateieigentum über die verschiedenen Phasen der Lebensdauer der Nachrichten. Zum Beispiel ist beim Nachrichtenverfassen der Nachrichtenautor der Eigentümer der Datei, während bei der Nachrichtendurchsicht der Nachrichtenempfänger der Eigentümer der Datei ist. Diese Vorstellung von der Änderung des Dateieigentums ist in 34 dargestellt, die sowohl das Eigentum als auch die Lesbarkeit der einem Video-Mail-Anhang zugeordneten Videodateien über die Nachrichtenlebensdauer deutlicher zeigt. Die Wirkungen der Nachrichtenweiterleitung sind in der Figur nicht gezeigt, wobei dies aber eine zweite Autorenschaft/Empfänger-Transaktion genau wie die in der Figur gezeigte ist.
Nunmehr anhand von 33 ist der Lebenszyklus einer Beispielvideonachrichtendatei wie folgt diskutiert:
Wenn bei 1510 eine Videodatei erzeugt wird, der mittels eines Bezugnahmezeigers 1512 eine Nachricht zugeordnet wird, woraufhin sie gesendet wird, wird von dem herkömmlichen E-Mail-System 1513 eine E-Mail-Adressenliste 1514 erhalten und bei 1516 an das aufzeichnende AVSS übergeben. Das aufzeichnende AVSS 1516 ermittelt aus der E-Mail-Adressenliste 1514 die Empfängeradressen, die daraufhin mittels Verzeichnisdiensten dem Namen ihrer bedienenden AVSS zugeordnet werden. Die Verzeichnisdienste stellen einen Mechanismus bereit, durch den Namen, E-Mail-Adressen oder Anmeldeidentitäten von Anwendern nachgeschlagen werden können und ihren Videoadressen in einer LAN- oder WAN-Umgebung zugeordnet werden können. In der vorliegenden Ausführungsform könnte der AVNM-Server diese Verzeichnisdienste bereitstellen oder könnten diese Dienste durch gut bekannte Verzeichnisprotokolle wie etwa LDAP bereitgestellt werden.
Bei 1518 nehmen die Programmelemente der vorliegenden Erfindung eine Bestimmung vor, ob die der Video-Mail-Nachricht zugeordnete E-Mail-Adressenliste 1514 leer ist. Wenn bei 1520 ermittelt wird, dass die E-Mail-Adressenliste nicht leer ist, wird für jeden Empfänger in der Liste bei 1522 eine weitere Bestimmung vorgenommen, ob der momentane Empfänger der Nachricht durch das aufzeichnende AVSS bedient wird. Wenn bei 1524 die Bestimmung erfolgt, dass der momentane Empfänger durch das aufzeichnende AVSS bedient wird, wird die Datei in dem AVSS gehalten und wird bei 1526 der nächste Empfänger aus der E-Mail-Adressenliste gewählt. In Reaktion auf die Auswahl des nächsten Empfängers bei 1530 wird der Schritt 1518 erneut aufgerufen, bis die E-Mail-Adressenliste leer ist. In Reaktion auf eine Bestimmung bei 1528, dass der momentane Empfänger nicht in dem aufzeichnenden AVSS ist, wird die Datei zu einem Ziel-AVSS 1580 übertragen. Der Abschluss der Kopie bei 1529 kehrt zu Schritt 1526 zurück, um den nächsten Empfänger aus der E-Mail-Adressenliste zu wählen. Bei 1530 wird in Reaktion auf die Auswahl des nächsten Empfängers der Schritt 1518 erneut aufgerufen, bis die E-Mail-Adressenliste leer ist.
Es ist ein Hauptmerkmal der vorliegenden Erfindung, dass die der Multimedia- und Videokommunikation zugeordneten verhältnismäßig großen Videodateien verteilt werden, wo es erforderlich ist, und dort gehalten werden, jedoch nur so lange, wie es erforderlich ist. Auf diese Weise bieten die Prinzipien der vorliegenden Erfindung ein bisher unerreichtes Niveau der Systemwirtschaftlichkeit in Bezug auf Massenspeicher, Bandbreite und andere Systembegrenzer. Dementsprechend betrachten die Prinzipien der vorliegenden Erfindung spezifisch die automatische Löschung von Videodateien, wenn sich bestimmte Löschkriterien herausgestellt haben. Beispiele dieser Kriterien enthalten, sind aber nicht spezifisch beschränkt auf: das Lesen einer gegebenen Datei durch alle ihre beabsichtigten Empfänger, das Verstreichen einer bestimmten Zeitdauer, eine bestimmte Anzahl von Aufrufen der Nachricht und weitere Nachrichtenbilanzierungsparameter, die dem Durchschnittsfachmann auf dem Gebiet gut bekannt sind. Unter Berücksichtigung dieser Löschkriterien wird bei 1582 eine Bestimmung vorgenommen, ob eines oder mehrere Löschkriterien erfüllt sind. Wenn die Löschkriterien nicht erfüllt sind, schleift das System bei 1586 zurück und kehrt bei 1582 zum Warten darauf zurück, dass die Löschkriterien erfüllt sind. Bei 1588 wird die Datei in Reaktion auf eine Bestimmung bei 1584, dass die Löschkriterien bei 1588 erfüllt sind, aus dem Ziel-AVSS gelöscht.
Nunmehr zu der Schleife durch die E-Mail-Adressenliste in Schritt 1518 zurückkehrend, wird dann, wenn bei 1540 eine Bestimmung erfolgt, dass die E-Mail-Adressenliste leer ist, bei 1542 eine Abfrage vorgenommen, ob irgendwelche Dateiempfänger durch das aufzeichnende AVSS bedient werden. In Reaktion auf eine Bestimmung bei 1540, dass keine Dateiempfänger durch das aufzeichnende AVSS bedient werden, wird die Datei bei 1550 aus dem aufzeichnenden AVSS gelöscht, wobei diese Funktion der vorliegenden Erfindung bei 1552 abgeschlossen wird. In Reaktion auf eine Bestimmung durch Schritt 1542, dass Dateiempfänger durch das aufzeichnende AVSS bedient werden, bei 1544, erfolgt bei 1545 eine Bestimmung, ob die Löschkriterien erfüllt sind. Wenn bei 1546 eine Bestimmung erfolgt, dass die Dateilöschkriterien nicht erfüllt sind, wird das System zurückgeschleift und kehrt bei 1545 zum Warten darauf zurück, dass die Löschkriterien erfüllt sind. In Reaktion auf eine Bestimmung durch Schritt 1545, dass die Dateilöschkriterien erfüllt sind, bei 1560, wird die Datei in Schritt 1550 aus dem aufzeichnenden AVSS gelöscht, wobei diese Aktion diese Funktion der vorliegenden Erfindung bei 1552 abschließt.
Aus dem Vorstehenden werden mehrere neue Aspekte der vorliegenden Erfindung offenbar.
In jedem AVSS können Kopien der Datei zu einer oder zu mehreren zusätzlichen Platten in derselben AVSC oder in mehreren AVSCs verteilt werden, um die Blockierung auf den Dateizugriff zu verringern. Dies verbessert sowohl die Systemansprechempfindlichkeit als auch die Systemzuverlässigkeit. In kleineren Implementierungen der vorliegenden Erfindung nutzt diese Dateiverteilung die vollständige Replikation der Videodateien. In größeren Implementierungen wird eine "Hash-Codierungs"-Abbildung genutzt, die wie folgt erläutert wird: Wo eine Datei in hoher Nutzung sein kann, betrachten die Prinzipien der vorliegenden Erfindung eher, als sie nur in einem AVSS, z. B. in dem AVSS, in dem die Datei verfasst wurde, zu lassen und sie dadurch nur auf der einen Platte zu lassen, was zu unerwünschten Verzögerungen der Zugriffszeit führen kann, die Verteilung von Dateien hoher Nutzung zu einer oder zu mehreren Speichervorrichtungen in einer AVSC oder tatsächlich zu einer Anzahl verschiedener AVSCs in dem System. Dies kann mittels irgendeines einer Anzahl von Hash-Codierungs-Schemata ausgeführt werden, die dem Durchschnittsfachmann auf dem Gebiet bekannt sind. Natürlich verbessert dies die Verfügbarkeit der Datei und somit die Verfügbarkeit des Systems, das sich auf die Datei stützt.
Die Lebenszyklusvorteile, die eine Beispielausführungsform der vorliegenden Erfindung bietet, enthalten, sind aber nicht notwendig beschränkt auf, die folgenden:

(A) Videodateien werden nur in jenen AVSSs unterhalten, die einen angegebenen Empfänger für die Videodatei bedienen, sofern sie nicht zur Zuverlässigkeit und Datenredundanz an einem anderen Ort gespeichert werden.
(B) Videodateien werden automatisch gelöscht, wenn alle Nachrichten, die die Videodatei enthalten, gelöscht worden sind; und
(C) wo sich ein Empfänger in einem anderen AVSS als dem aufzeichnenden AVSS befindet, wird die Videodatei automatisch zu dem Ziel-AVSS übertragen. Die Übertragungsfunktion kann als "Kopieren" oder "zuverlässiges Verschieben" implementiert werden.

Diese Vorteile stellen sicher, dass verhältnismäßig große Videodateien nur bei Bedarf übertragen werden und nur in jenen AVSSs gehalten werden, die sie erfordern, und dann nur so lange, wie die Dateien erforderlich sind. Unnötige Dateien werden automatisch aus irgendeinem AVSS gelöscht, wenn sie nicht mehr von irgendeinem durch das AVSS bedienten Empfänger benötigt werden.
Nunmehr anhand von 34 ist eine gegebene Datei während des Aufzeichnungs- und Durchsichtsprozesses 1602 und 1604 durch ihren Autor sowohl lesbar als auch sein Eigentum. Wenn der Autor die Datei bei 1606 sendet, ist sie immer noch Eigentum des Autors, wobei sie aber nicht lesbar ist. Diese Bedingung setzt sich über SMTP und die Videodateiübertragung 1608 und die Empfangsphase 1610 fort. Wenn bei 1612 der Empfänger über die Ankunft der E-Mail-Nachricht und der Videodatei benachrichtigt wird, gehen sowohl die Dateilesbarkeit als auch das Dateieigentum an den Empfänger über. Diese Bedingung setzt sich über die Nachrichtenlese- und Nachrichtenlöschphase 1614 bzw. 1616 fort. Natürlich ist die Datei weder Eigentum noch lesbar, wenn die Datei gelöscht worden ist.
Der Autor könnte auswählen, ein Empfänger zu sein oder einfach ein Eigentümer zu bleiben. Somit würde die Datei während der Schritte des Sendens 1606, der Übertragung 1608, des Empfangs 1610 und der Benachrichtigung 1612 durch den Autor lesbar bleiben. Der Autor würde sich an den Phasen des Lesens 1614 und des Löschens 1616 beteiligen.
Je nachdem, ob der Konferenz-Client in einzelnen Desktops oder Räumen implementiert ist, sind bestimmte AVSS-Fähigkeiten erforderlich. Wenn das zuvor diskutierte Video-Mail-System innerhalb eines Unternehmens implementiert wird, das Desktops oder Räume enthält, die mit Workstation-Konferenz-Clients ausgestattet sind, wie sie im US-Patent Nr. 5.617.539 beschrieben sind, werden die folgenden AVSS-Merkmale angenommen:

1. Allgemeine Steuerprotokollschnittstelle/API.
2. Ein allgemeines Mehr-Plattform-Audio-Video-Aufzeichnungs/Wiedergabe-Hilfsmittel (ähnlich vfstool), das hier als die "Betriebsartsteuerungs-GUI" oder "MCG" bezeichnet wird.
3. Mehrsitzungs-Aufzeichnungs/Wiedergabe-Fähigkeit.
4. Analoge A/V-E/A.
5. Wenn ein Codierer zugeordnet wird, wird gleichzeitig ein AVSC-Decodierer zugeordnet. Dies stellt sicher, dass der Decodierer während der Aufzeichnungssitzung immer für die Durchsicht verfügbar ist.
6. Variable Kapazitätsskalierung zur Anpassung an die Notwendigkeiten unterstützter Anwendungen.
7. Dateiübertragungsfähigkeit (Zieh-Modell) zwischen AVSSs, die durch spezifische durch Anwendungen gestellte Dateiübertragungsanforderungen angesteuert werden.
8. Effektives "Zurückschleifen" von ankommendem Video zu abgehendem Video bei der AVSC während der Aufzeichnungsbetriebsart.
9. Eine Videoeditierfähigkeit. Diese Fähigkeit kann intern als Teil eines Anwendungsprogramms implementiert sein oder kann alternativ fähig sein, Drittanbieter-Video- und/oder Drittanbieter-Audio-Editoren aufzurufen.

Wo Desktops oder Räume nicht mit den im US-Patent Nr. 5.617.539 gelehrten Workstation-Konferenz-Clients ausgestattet sind, sondern eher mit Standard-MPEG- oder anderen Codierern/Decodierern ausgestattet sind, sind die folgenden zusätzlichen Fähigkeiten erforderlich:

10. Die Fähigkeit zum Akzeptieren und Wiedergeben geeigneter digitaler Dateien von Drittanbietern, wie sie durch Anwendungen gesteuert wird.
11. Die Fähigkeit zum Übertragen geeigneter digitaler Dateien an Drittanbieter, wie sie durch Anwendungen gesteuert wird.

Natürlich bedeutet das Senden einer Video-E-Mail die Erzeugung einer Videodatei. Die Prinzipien der vorliegenden Erfindung betrachten zahlreichen Videodatei-Erzeugungsszenarien. Videodateien können unter Verwendung des AVSS als ein Videodatei-Speicherdatenlexikon im Voraus aufgezeichnet, editiert und gespeichert werden. Sie können zur gleichen Zeit erzeugt werden, zu der der Anwender die Video-E-Mail sendet. Videodateien können von anderen Videoquellen, wie sie hier an anderer Stelle beschrieben sind, importiert und an Video-Mail-Nachrichten angehängt werden. Schließlich kann ein Video-Mail-Anhang die Notwendigkeit für Text mit der Nachricht vollständig beseitigen. In dieser letzteren Ausführungsform der vorliegenden Erfindung wird der Videoanhang zu der Nachricht, während Text ausgeschlossen wird: Dementsprechend ist klar, dass im Wesentlichen irgendeine zum Erzeugen einer Videodatei verwendete Methodik implementiert werden kann, um Videoanhänge für Video-Mail zu erzeugen, wobei sie alle von den Lehren der vorliegenden Erfindung eingeschlossen sind.
Wenn ein Anwender einen neuen Audio-Video-Anhang an eine Video-Mail-Nachricht senden möchte, wird dies durch Erzeugen einer neuen Audio-Video-Datei durch Auswählen von DATEI:NEU aus dem Betrachterhauptmenü und daraufhin durch Aufzeichnen des Videos ausgeführt. In einer oder in mehreren Ausführungsformen kann die Videoaufzeichnung mehrere Ebenen der Editierfähigkeit umfassen. Die rudimentärste von diesen ermöglicht, dass ein Anwender eine Datei löscht und sie daraufhin neu aufzeichnet. Nur wenig anspruchsvoller ist eine Ausführungsform, die ermöglicht, dass ein Anwender seine Aufzeichnung zunächst durchsieht und daraufhin bei Bedarf löscht.
Eine weitere Verbesserung ist ein Editierschema, das ermöglicht, dass der Anwender Material in eine Datei einfügt/aus ihr löscht/in sie importiert. Schließlich wird die Videodatei als eine Audio-Video-Datei in dem lokalen Dateisystem gesichert. Die vorliegende Erfindung betrachtet jede dieser Editierstrategien in jeder der hier gelehrten Anwendungen.
Obgleich die vorliegende Erfindung die Integration der oben beschriebenen Editiermerkmale darin betrachtet, betrachtet sie ebenfalls die Nutzung eines Drittanbieter-Videoeditors für das gesamte Videoeditieren. Der Drittanbietereditor kann von der vorliegenden Erfindung mittels eines Grundelements, eines Plugins, einer Aufrufschaltfläche, von Skripten oder anderen Aufrufmethodiken aufgerufen werden, die dem Durchschnittsfachmann auf dem Gebiet gut bekannt sind.
Wo es gewünscht ist, verwendet der Anwender daraufhin sein normales E-Mail-Paket zum Erzeugen einer E-Mail-Textnachricht. Daraufhin hängt er die AV-Datei-Zeiger an die E-Mail an und überträgt oder sendet die E-Mail daraufhin. Eine alternative Ausführungsform betrachtet ein enger integriertes Mail-Paket, das in dem Mail-Paket-Zusammensetzungs-Dialog einen Menüpunkt "Video anhängen" enthält. Um den zuvor diskutierten Prozess etwas zu vereinfachen, könnte der Menüpunkt "Video anhängen" den Betrachter mit dem Schalter -n starten, um anzugeben, dass der Betrachter automatisch eine neue Videodatei erzeugen und eine Codierungssitzung öffnen sollte.
Wenn ein Anwender eine E-Mail mit einem Audio-Video-Anhang empfängt, öffnet er den Anhang unter Verwendung seines E-Mail-Lesers. Dies startet den Betrachter zum Öffnen des Audio-Videos-Anhangs. Wenn das Video kennwortgeschützt ist, wird der Anwender aufgefordert, das Kennwort zu liefern. Wenn das Kennwort falsch ist, wird die Datei nicht geöffnet. Alternativ startet der Betrachter seinerseits bei Bedarf die Konferenzbetriebsart. Wenn die Datei in dem AVSS gespeichert ist, mit dem der Betrachter verbunden ist, werden in dem Betrachter die VCR-Steuerungen für die Wiedergabe freigegeben, wenn sich die Konferenz erfolgreich mit dem AVSS verbindet. Der Anwender spielt das Video unter Nutzung der Abspielen-, Suchen- und Rücklaufschaltfläche dieser Steuerungen ab und sieht und hört die Ausgabe auf der Workstation.
Wenn die Datei nicht lokal gespeichert ist, initiiert das AVSS eine Dateiübertragung, um das MPEG-Video von dem entfernten AVSS zu empfangen. Der Anwender wird benachrichtigt, dass die Übertragung stattfindet. Wenn die Dateiübertragung abgeschlossen ist, werden im Betrachter die Steuerungen vom VCR-Typ für die Wiedergabe freigegeben. Alternativ könnte sich der Anwender dafür entscheiden, sich mit dem entfernten AVSS auf ähnliche Weise wie mit dem lokalen AVSS zu verbinden.
Die vorstehende Diskussion hat sich auf eine erste Ausführungsform der vorliegenden Erfindung konzentriert. Alternative Ausführungsformen, die durch die hier offenbarten Lehren betrachtet werden, enthalten: Den Anhang von A/V-Dateien mittels Zeigens auf Dateiorte im Gegensatz zur direkten Verwendung von MIME-Systemen, den Aufruf einer oder mehrerer der zuvor diskutierten Prozesse beim Öffnen oder Schließen eines Anhangs oder beim Öffnen oder Schließen einer Nachricht, A/V-Netz- und Server-Socket-Managementschemata, Videobetrachter- und Orts- und Schließmanagementmethodiken und Bildschirmsäuberungs- und Verbindungsmanagementmethodiken.
4.16.2 Videobeantwortersystem
Die Videobeantworteranwendung nutzt das AVSS zum Aufzeichnen einer Audio- und Videonachricht von einem ankommenden Anrufer, dessen Anrufversuch durch den Empfänger entweder nicht beantwortet oder zurückgewiesen wird. Außerdem betrachtet die vorliegende Erfindung, dass der ankommende Anrufer einfach eine Nachricht hinterlassen möchte, ohne sich mit dem Empfänger zu verbinden. Eine Implementierung dieses Merkmals der vorliegenden Erfindung unterstützt den Fall, dass zu der Zeit, zu der ein Anruf bei einem Anwender platziert wird, keine A/V-Codec-Verbindungsleitungen verfügbar sind. Das Videobeantwortersystem enthält mehrere Hauptkomponenten: ein Beantwortermodul, ein Browser-Modul, ein Wiedergabemodul und ein Modul, in dem Dateiübertragungen potentiell zwischen AVSS behandelt werden.
Die Prinzipien der vorliegenden Erfindung betrachten mehrere Methodiken, durch die die Videobeantworteranwendung aufgerufen wird. Ein Weg, den Videobeantworter aufzurufen, ist das Bereitstellen einer Option für einen Anrufer zu irgendeiner Zeit während des "Läute-Zyklus" zum Hinterlassen einer Nachricht für den Empfänger. Außerdem kann einem Anrufer die Option dargestellt werden, in irgendeinem der folgenden Fälle eine Nachricht zu hinterlassen: nach einer angegebenen Dauer eines Läutezyklus, d. h. nach einem Läute-Zeitablauf, wenn ein Anruf abgewiesen wird und wenn der Anrufer wegen einer übermäßigen Anzahl wartender Anrufe ein Belegt-Signal empfängt.
Wenn diese Anwendung aufgerufen wird, kann der Anrufer in einer Anzahl von Arten die Option zum Hinterlassen einer Nachricht erhalten. Diese Benachrichtigungsmethodiken enthalten, sind aber nicht spezifisch beschränkt auf: einfa che Textbenachrichtigung, einfachen Audioton, eine reine Audio-Begrüßung, eine reine Video-Begrüßung, eine Audio-Video-Begrüßung und eine Multimedia-Begrüßung. Die Entscheidung, irgendeine dieser Benachrichtigungsmethodiken zu implementieren, hängt von mehreren Faktoren einschließlich der verfügbaren Speicherkapazität, der Bandbreite, der gewünschten Systemantwortparameter, dem/den gewünschten "Erscheinungsbild und Bedienungsmerkmalen" des Systems sowie weiteren Systemeinschränkungen, die dem Durchschnittsfachmann auf dem Gebiet gut bekannt sind, ab.
Mehrere für WAN-Installationen betrachtete Implementierungen enthalten Alternativen für die Platzierung der Anwenderbegrüßungen, wobei die Alternativen Anwenderbegrüßungen, die sich in dem AVSS des Anwenders befinden oder die alternativ zu jedem AVSS in dem WAN verteilt werden, um dort lokal gespeichert zu werden, enthalten. Diese Alternativen hängen von vielen Systeminstallationsfaktoren einschließlich der Anzahl der Anwender, der Systemnutzung, der Bandbreite usw. ab. In Bezug auf das Nachrichten-Verfassen kann die Nachricht lokal aufgezeichnet und wie in der zuvor diskutierten Videomail zu einem entfernten Standort gesendet werden. Alternativ kann das System so konfiguriert werden, dass es eine direkte Verbindung zu dem empfangenden AVSS aufbaut und die Nachricht auf der Empfangsseite aufgezeichnet wird. Diese spätere Implementierung führt zu einer sichereren prompten Lieferung der Nachricht, erfordert aber mehr sofortige Bandbreite.
Der Anrufer kann sich entweder mittels einer spezifischen Antwort auf ein Dialogfeld oder einfach durch Aktivieren der Aufhängen-Schaltfläche an dem Anrufbetrachter explizit dafür entscheiden, keine Nachricht zu hinterlassen.
Eine Implementierung dieses Merkmals der vorliegenden Erfindung stellt für einen Anrufer die Gelegenheit bereit, entweder als Teil eines vorhandenen Anrufstatus, z. B. eines Anwender-Belegt-Popups, mit dem automatischen Abspielen einer im Voraus aufgezeichneten Videobegrüßung, oder mit anderen automatischen Nachrichtensystem-Aufrufmethodiken automatisch eine Nachricht zu hinterlassen. Wenn der Anwender die Option zum Hinterlassen der Nachricht annimmt, wird eine Sitzungsaufzeichnungsanforderung an das AVSS übergeben. Wenn die Anforderung gewährt wird, wird eine MCG bereitgestellt und eine AVNM-Verbindung aufgebaut. Wenn der Empfänger den Anruf zu beantworten versucht, wenn der Anrufer die Nachricht aufzeichnet, wird ein nicht zerstörender Austritt bereitgestellt, der ermöglicht, dass der Anrufer die Nachricht fertigstellt und den Anruf danach mit dem angerufenen Teilnehmer verbindet. Ein ähnlicher nicht zerstörender Austritt wird genutzt, wenn der angerufene Teilnehmer zurückzurufen versucht, wenn die Nachrichtenaufzeichnung im Gang ist. Ferner betrachten die Prinzipien der vorliegenden Erfindung einen zerstörenden Austritt, wenn der Anrufer die Nachricht während der Aufzeichnungssitzung verlassen möchte. Schließlich bietet eine Rückfallbetriebsart dem Anwender die Option, eine Nicht-Video-Nachricht zu hinterlassen, wenn das AVSS ungenügende Betriebsmittel zum Gewähren der Aufzeichnungsanforderung besitzt. Eine solche Nicht-Video-Nachricht wird durch die "Wort-Hinterlassen"-Funktion des enthaltenen Literaturhinweises bereitgestellt.
In einer Ausführungsform der vorliegenden Erfindung werden Empfänger benachrichtigt, wenn in ihren jeweiligen Warteschlangen Nachrichten vorhanden sind. Da zu irgendeiner gegebenen Zeit mehr als eine Nachricht in der Warteschlange sein könnte, stellt das Videobeantwortersystem einen Browser bereit, um zu ermöglichen, dass der Empfänger die in seiner Warteschlange wartenden Nachrichten durchsieht. Der Browser kann Informationen über die Videonachrichten anzeigen, einschließlich, aber nicht beschränkt auf: Name des Anrufers, Zeit und Datum des Anrufs, Videodateiname, Wiedergabedauer, Beschreibung, Textanmerkung vom Anrufer und Erzeugungszeit des Videos. Schließlich wird eine Wiedergabebetriebsart bereitgestellt, um zu ermöglichen, dass der Empfänger die zum Betrachten gewählten Nachrichten abspielt.
Das Dateieigentum in der Videobeantworteranwendung ist wie folgt: Wenn eine Nachricht verfasst wird, ist die Datei Eigentum des Nachrichtenautors. Wenn die Nachricht durchgesehen wird, geht das Dateieigentum, wie durch den AVNM identifiziert wird, an den Empfänger über.
Nunmehr anhand von 35 wird eine Übersicht einer Ausführungsform des Videobeantwortersystems der vorliegenden Erfindung diskutiert. Wenn ein Anrufer, z. B. bei der Workstation 1802, einen Empfänger, z. B. den Anwender bei der Workstation 1804, anruft und das Videobeantwortersystem wie zuvor diskutiert aufgerufen wird, wird eine Anforderung von der Workstation 1802 an den AVNM 1702 gesendet. Daraufhin leitet der AVNM 1702 bei 1710 eine Anforderung zum Videobeantwortermodul 1704 weiter, das seinerseits bei 1714 eine Sitzungsanforderung an das AVSS 1708 einreicht. Das AVSS 1708 liefert in Reaktion auf die Sitzungsanforderung 1714 eine Antwort 1716 an das Videobeantwortermodul.
In Reaktion auf die Wiedergabe 1716 baut das Videobeantwortermodul 1704 bei 1712 eine Verbindungssteuerung mit dem AVNM 1702 auf und benachrichtigt das Videowiedergabemodul 1706 bei 1718 über den Aufbau einer Videobeantwortersitzung. Das Videobeantwortermodul 1706 reicht in Reaktion auf diese Benachrichtigung bei 1720 seine eigene Sitzungsanforderung an das AVSS 1708 ein. Bei 1722 baut das AVSS 1708 in Reaktion auf diese Sitzungsanforderung bei 1722 eine zweite Verbindungssteuerung mit dem AVNM 1702 auf.
In 36 ist ein Datenablaufplan gegeben, der den Betrieb einer Ausführungsform der vorliegenden Erfindung genau beschreibt. Anhand dieser Figur initiiert ein Anrufer bei 3502 eine Videoanrufanforderung. Wenn die Videoanrufanforderung bei 3504 nicht angenommen wird, wird bei 3506 die Begrüßung des Empfängers aufgerufen. Wie zuvor diskutiert wurde, kann die Videoanrufanforderung aus einer Anzahl von Gründen nicht angenommen werden, einschließlich, aber spezifisch nicht beschränkt auf: Der Anrufer nimmt zu irgendeiner Zeit während des "Läute"-Zyklus seine Option zum Hinterlassen einer Nachricht für den Empfänger wahr, nach einer angegebenen Dauer eines Läutezyklus, d. h. nach einem Läute-Zeitablauf, wenn ein Anruf abgewiesen wird und wenn der Anrufer wegen einer übermäßigen Anzahl wartender Anrufe ein Belegt-Signal empfängt.
Wenn die Videonachricht nicht angenommen wird, wird bei 3506 die Begrüßung des Empfängers abgespielt und wird dem Anrufer bei 3508 die Option geboten, eine Nachricht für den Empfänger zu hinterlassen. Diese Option kann wieder auf eine Anzahl von Arten dargestellt werden, die beispielhaft, aber ohne Beschränkung, enthalten: eine einfache Textbenachrichtigung, einen einfachen Audio-Ton, eine reine Audio-Begrüßung, eine reine Video-Begrüßung, eine Audio-Video-Begrüßung und eine Multimedia-Begrüßung. Wenn der Anwender bei 3510 seine Option wahrnimmt, keine Videonachricht zu hinterlassen, wird die Videoanrufbeantwortersitzung bei 3512 abgeschlossen. Wenn der Anwender alternativ bei 3514 seine Option zum Hinterlassen einer Videonachricht wahrnimmt, kann er bei 3516 die Nachricht auf irgendeine der zuvor diskutierten Arten für die Erzeugung von Videonachrichten erzeugen.
Bei 3518 wird die Nachricht in Reaktion auf die Erzeugung der Videonachricht in Schritt 3516 durch den Anrufer an das richtige AVSS gesendet. Zu einem späteren Zeitpunkt wird die Nachricht bei 3520 an den Empfänger geliefert. Nachdem der Empfänger einen Browser, einen Leser oder eine andere Dateiuntersuchungsmethodik zum Lesen der Nachricht aufgerufen hat, die in dieser Ansicht nicht gezeigt ist, wird dem Anwender bei 3522 die Option zum Löschen der Nachricht geboten.
Wenn der Empfänger bei 3524 die Nachricht zu löschen auswählt, wird sie bei 3526 aus dem AVSS gelöscht. Wenn der Empfänger alternativ bei 3528 die Nachricht nicht zu löschen auswählt, wird sie bei 3530 in dem AVSS behalten.
Die Prinzipien der vorliegenden Erfindung betrachten zwei umfassende Strategien zur Implementierung des hier gelehrten Videobeantwortersystems. Eine erste umfassende Strategie implementiert eine "geschichtete" Methodik, die eine Anzahl von Anwendungen, von denen einige vorher existieren können, zu dem Videobeantwortersystem der vorliegenden Erfindung integriert. Eine solche geschichtete Implementierung betrachtet die Verwendung der zuvor diskutierten Video-Mail-Anwendung als ein Nachrichtenbehandlungsmittel. Diese Ausführungsform definiert inhärent viele der Hauptdateieigentumsfragen. Ferner werden die zuvor diskutierten Verfassungs-, Browsing, Wiedergabe- und Benachrichtigungsfunktionen alle durch die Video-Mail-Anwendung selbst bereitgestellt. Eine weitere Version einer geschichteten Implementierung betrachtet die Nutzung einer dedizierten Instanz eines herkömmlichen E-Mail-Systemprogramms zur Schaffung einer dedizierten Videobeantwortersystem-Nachrichtenbenachrichtigung und eines dedizierten Videobeantwortersystem-Nachrichten-Browsing.
Eine zweite umfassende Strategie betrachtet die Erzeugung einer einzigen "selbstständigen" Anwendung zum Ausführen der zuvor definierten Funktionen. Diese Strategie, die keine Video-Mail oder ein anderes Programm als eine Nachrichtenbehandlungsroutine nutzt, erfordert die Implementierung von Anwender schnittstellen, um dem Anwender die Option zum Hinterlassen einer Nachricht zu bieten. Darüber hinaus erfordert eine solche Implementierung Nicht-Mail-Software und neue Anwenderschnittstellen zum Ausführen der Aufgaben der Nachrichtenbenachrichtigung, des Nachrichten-Browsing und der Nachrichtenwiedergabe.
4.16.2.1 Geschichtete Implementierung des Videobeantwortersystems
Diese Implementierung betrachtet die Verwendung der zuvor diskutierten Video-Mail-Anwendung oder einer anderen diskreten Anwendung als eine Nachrichtenbehandlungsroutine oder als ein anderes Systemelement für das Videobeantwortersystem. Nachdem in Reaktion auf einen nicht angenommenen Videoanruf eine Videoverbindung aufgebaut worden ist, kann gemäß dieser Strategie entweder auf der Sendeseite, d. h. der des AVSS des Anrufers, oder auf der Empfangsseite, d. h. der des AVSS des Empfängers, eine Video-Mail verfasst werden. Welche Implementierung die Ausführungsform bildet, ist eine wirtschaftliche Entscheidung, die auf einer Anzahl systemspezifischer Faktoren beruht.
Die in Reaktion auf das Videobeantwortersystem erzeugte Video-Mail kann offline, d. h. in einer Nicht-Echtzeit-Betriebsart, an den Empfänger gesendet werden. In den meisten Ausführungsformen hätte diese Implementierung wahrscheinlich eine minimale Auswirkung auf die Systembandbreite. Eine Option für diese Implementierung ist das Verfassen auf der Sendeseite und die Nutzung einer Prioritätswarteschlange, um die Nachricht während einer Periode niedriger Bandbreitennutzung zu dem AVSS des Empfängers zu senden. Dies verlegt die Nachricht aus der Echtzeit und sendet sie mit einer niedrigeren Bitrate als das Verfassen auf der Empfangsseite, das eine Konnektivität in voller Bandbreite erforderlich machen würde. Die Alternative zu dieser letzteren Ausführungsform ist natürlich das Verfassen von Video-Mail-Nachrichten in Reaktion auf den Aufruf des Videobeantwortersystems auf der Empfangsseite oder das Senden der Nachricht mit derselben Baudrate wie in Videokonferenzen. Jede Ausführungsform ist eine Systemadministratorfrage: Die Einsparung der Bandbreite gegenüber einem Grad an Zeitverzögerung in den Nachrichtenantworten. Wo Nachrichten fast sofort benötigt werden, können die Kosten der Bandbreite erforderlich sein.
Wo das Videonachrichtensystem in Reaktion auf die Tatsache aufgerufen wird, dass zwischen Standorten keine Kommunikationsverbindungsleitungen verfügbar sind, kann es weiter erwünscht sein, auf jeden Fall eine Nachricht zur späteren Sendung, wenn die Kommunikation verfügbar wird, zu hinterlassen. Diese Funktionalität kann durch ein durch den Systemadministrator bereitgestelltes Skript oder durch eine andere dem Durchschnittsfachmann auf dem Gebiet bekannte automatische Aufrufmethodik ermöglicht werden.
Wo das Unternehmen nicht zu groß ist, könnten alle Begrüßungsdateien von allen Anwendern bei allen Standorten gespeichert sein. Begrüßungsdateien von allen Anwendern an allen Standorten ermöglichen eine reiche Umgebung für die Videoanrufbeantwortung, wo ein Anrufer selbst dann mit einer audiovisuellen Begrüßung von einem Empfänger begrüßt wird, wenn keine Kommunikationsverbindungsleitungen verfügbar sind. Dies ist wieder eine Frage der Fähigkeit gegenüber der Speicherkapazität. Dementsprechend kann in Übereinstimmung mit den Prinzipien der vorliegenden Erfindung der Systemadministrator ermitteln, wo Begrüßungen gespeichert werden.
Wo ein Unternehmen allgemein niedrige Kommunikationsvolumina erfährt, können Nachrichten mit guter Wirkung auf der Empfangsseite aufgezeichnet werden. Diese Ausführungsform minimiert Zeitverzögerungen beim Erhalten von Mail-Nachrichten zu den Empfängern. Selbst in dieser Ausführungsform kann die Nachricht, wo Verbindungsleistungen nicht verfügbar werden oder Perioden hoher Verwendung feststellen, unter der Steuerung eines Skripts auf der Anruferseite aufgezeichnet und daraufhin als eine Mail-Nachricht gesendet werden, wenn Bandbreite verfügbar ist.
Weitere Änderungen dieser Ausführungsform enthalten, dass dem Anwender in der GUI die Option gegeben wird, seine Nachricht zu priorisieren. Wenn eine Datei, z. B. eine MPEG-Datei, gesendet wird, ermöglicht die Verwendung von Video-Mail, dass ein Anrufer die Datei als eine Antwort an eine Anrufbeantworterantwort sendet.
Es gibt Video-Mail-Systeme, die vollständig von Videokonferenzsystemen getrennt sind. Wenn ein Anrufer eine Video-Mail-Nachricht aufzeichnet, kann er sie z. B. im MPEG-1-Videoformat aufzeichnen. Wenn ein Anrufer in Echtzeit mit einem Empfänger spricht, kann er Video z. B. im H.320-Format senden. Die Prinzipien der vorliegenden Erfindung betrachten die Implementierung des Videoanrufbeantworters durch Aufrufen von Video-Mail in der Weise, dass sie H.320 nicht verwendet. Wo H.320 aufgezeichnet wird, betrachten die Prinzipien der vorliegenden Erfindung spezifisch die Verwendung dieses selben "Live"-Formats sowohl für aufgezeichnete als auch für Echtzeit-Videoanwendungen. Ferner betrachtet diese Implementierung die Nutzung von Bandbreitenmanagementtechniken, Aufzeichnungsschemata und Videokompressionsalgorithmen zum Minimieren der Bandbreitenauswirkung der verhältnismäßig großen Videonachrichten, die durch die Verwendung von Video im H.320-Format sowie einiger anderer Videoformate erzeugt werden.
Die Verwendung von Video-Mail als die Nachrichtenbehandlungsroutine für die Videoanrufbeantworteranwendung bietet eine zusätzliche Komplikation dadurch, dass sie auf der Seite des Anrufers oder auf der Seite des Empfängers aufzeichnen kann. Diese letztere Option knüpft die Anwendung enger an den Akt des Anrufens des Empfängers und stellt dadurch eine prompte Lieferung sicher. In einer Ausführungsform der vorliegenden Erfindung ist ein Rückrufmerkmal, das automatisch einen Rückruf zu dem Sender initiiert, um mit ihm in Echtzeit zu sprechen, oder ein Rückantwortmerkmal, das automatisch Video-Mail aufruft, um zu ermöglichen, dass der Empfänger einer Videonachricht mit einer eigenen Videonachricht antwortet, implementiert.
Wo Video-Mail genutzt wird, kann in der Nachricht eines Anrufers an den Empfänger ein Anhang, z. B. ein wie hier nachstehend diskutiert konstruierter MIME-Anhang, enthalten sein, dessen Aktivierung ermöglicht, dass der Empfänger den Anruf des ursprünglichen Anrufers zurückgibt. Ein solcher MIME-Anhang könnte ein Dialogfeld oder eine Dialogschaltfläche initiieren, die, wenn sie aktiviert wird, einen Antwortanruf und/oder eine Nachrichtenantwort startet. Dies schafft einen Ersatz für die im US-Patent Nr. 5.617.539 gelehrte "Wort-Hinterlassen"-Funktion. Alternativ betrachten die Prinzipien der vorliegenden Erfindung, dass die "Wort-Hinterlassen"-Funktion implementiert ist und dazu verwendet wird, um den Empfänger über den Empfang einer Nachricht und wo sie zu finden ist, z. B. die Mail-Warteschlange des Empfängers, zu benachrichtigen. Alternativ könnte die "Wort-Hinterlassen"-Funktion das Abfragen der Nachricht aus der Mail-Warteschlange ermöglichen oder könnte sie ein vollständig getrenntes Konto nur für Video-Mail besitzen.
4.16.2.2 Einzelimplementierung des Videobeantwortersystems
Im Gegensatz zu der zuvor diskutierten geschichteten Implementierung dieser Anwendung ist eine alternative Ausführungsform der vorliegenden Erfindung dadurch charakterisiert, dass sie eine Einzelimplementierung des Videobeantwortersystems der vorliegenden Erfindung ist. Diese Ausführungsform nutzt keine weiteren Programme wie etwa Video-Mail, um die erforderliche Nachrichtenbehandlung oder andere Merkmale des Videobeantwortersystems bereitzustellen. Viele der zuvor diskutierten Entwurfswahlen einschließlich, nicht beschränkt auf, der verwendeten Begrüßungen, dem Ort gespeicherter Begrüßungen, wie die Begrüßungen gesendet werden und ob Nachrichten entfernt oder lokal aufgezeichnet werden, betreffen diese Ausführungsform. Da diese Ausführungsform nicht die Funktionalität weiterer Programme nutzt, hängen diese Systementwurfswahlen nicht von dem Nachrichtenbehandlungssystem einer solchen Anwendung zum Implementieren der Anrufbeantworterfunktion ab.
Außerdem kann die GUI besser auf ihre Funktion als ein Anrufbeantworter zugeschnitten werden, wenn eine selbstständige Version implementiert wird. Die selbstständige Strategie beseitigt die Notwendigkeit, dass der Empfänger zu dem Mail-System geht, um seine Mail-Datei oder irgendeine andere Datei, die für Anrufbeantworternachrichten angegeben ist, zu prüfen. Dies weist auf eine Unzweckmäßigkeit in jenen Versionen des Videoanrufbeantworters hin, die Video-Mail als eine Nachrichtenbehandlungsroutine implementieren: Diese Implementierungen wirken mehr wie Mail-Systeme und weniger wie Anrufbeantworter. Die selbstständige Version besitzt ein erhöhtes Potential, mit weniger Zwischenschritten, die der Anwender ausführen muss, um seine Videoanrufbeantwortersystem-Nachrichten zu verarbeiten, besser auf den Anwender zu reagieren, um auf Videoanrufbeantworter-System-Nachrichten zuzugreifen, sie durchzusehen und zu verarbeiten. Ein Video-Mail-gestütztes System ist als eine selbstständige Nachrichtenübermittlungsumgebung eingerichtet, wobei ein Anrufbeantworter leichter auf die Tatsache abgestimmt werden könnte, dass der Empfänger angerufen wurde und dass ihm eine Nachricht hinterlassen worden ist. Dies macht die Anrufbeantworterfunktion in den meisten Implementierungen viel leichter zu verwenden und besitzt in den meisten Implementierungen wenigstens eine Schicht weniger als Mail-System-gestützte Implementierungen. Darüber hinaus kann die Verwendung Video-Mail-gestützter Systeme Beschränkungen an Begrüßungen, an die Datei und an Aufzeichnungsorte usw. stellen.
Eine weitere Betrachtung ist, dass Mail- und Anrufbeantworterfunktionen in einigen Organisationen sehr verschiedene Dringlichkeiten haben können. Dementsprechend kann eine Anrufnachricht gegenüber Video-Mail-Nachrichten eine Unternehmenspriorität haben. Wo dies der Fall ist, sollten Anrufbeantwortersystemnachrichten in diesen Organisationen leichter zu erhalten, leichter durchzusehen und leichter zu beantworten sein als Mail-Nachrichten. Im Gegensatz dazu sind Mail-Nachrichten eher wie Notizen: Sie sind allgemein wohlüberlegt produzierte Dokumente. Darüber hinaus sind Mail-Nachrichten nicht nur Mail-Browsern zugeordnet, sondern besitzen üblicherweise ebenfalls eines oder mehrere Textfelder. Dementsprechend würde die Verwendung von Video-Mail als eine Nachrichtenbehandlungsroutine dem Empfänger wahrscheinlich eines oder mehrere leere Textfelder darstellen, wenn eine Anrufbeantworternachricht angezeigt wird.
Da die Verwendung eines selbstständigen Anrufbeantwortersystem die in der zuvor diskutierten Video-Mail-gestützten Anwendung inhärenten Zusatzschichten entfernt, kann der Empfänger wie in der Wort-Hinterlassen-Funktion des enthaltenen Literaturhinweises eine Auflistung jener Personen sehen, die angerufen haben. Dies bietet dem Anwender die Option, einfach dadurch auf die Nachricht zu antworten, dass er den Anruf zurückgibt oder auf den Eintrag klickt, um zu sehen, was in den Anrufbeantworternachrichten hinterlassen worden ist: Video, Audio, oder eine Kombination davon. Auf jeden Fall kann die Antwort durch Nachricht oder durch Aufruf erfolgen. Dementsprechend betrachtet diese Ausführungsform die Aufnahme einer umfassenden Gruppierung von Video-, Audio-, Text- und Multimedia-Anhängen darin in die in Reaktion auf den Videoanrufbeantworter gesendete Nachricht.
4.16.3 Videokonferenzaufzeichnung
Die Videokonferenzaufzeichnungsanwendung ermöglicht, dass Anwender den Audio-Video-Abschnitt von Audio-Video-Konferenzen aufzeichnen.
Bei der Konferenzaufzeichnung für einen Anruf oder für eine Konferenz von N Teilnehmern gibt es potentiell N + 1 mögliche Standpunkte, von denen aufgezeichnet werden kann: Die Konferenz, wie sie von jeder Person gesehen wird, und die Konferenz, wie sie als eine Art zusammengesetzte "globale Ansicht" gesehen wird, die die kombinierten Ansichten, Audio, Video und Multimedia aller Konferenzteilnehmer umfasst. Die umfassendste Form einer "globalen Ansicht" würde durch die getrennte Aufzeichnung von Video und Audio jedes Teilnehmers in mehreren gleichzeitigen Aufzeichnungssitzungen für die spätere Kombination und Wiedergabe geliefert.
Obgleich diese äußerst umfassende Ausführungsform ermöglichen würde, dass ein Durchsehender jederzeit in umfassender Einzelheit frei auf jeden Teilnehmer zurückblickt, wäre dieser Ansatz sehr betriebsmittel- und plattenplatzaufwändig, da er eine getrennte Aufzeichnung für jeden Teilnehmer erfordert. Obgleich die Prinzipien der vorliegenden Erfindung eine solche Ausführungsform spezifisch umfassen, ist für alle bis auf die am massivsten implementierten Hardwarefamilien klar, dass die Kombination der Ansichten der mehreren Teilnehmer zu einer einzelnen globalen Ansicht allgemein bevorzugt ist, da sie weit weniger betriebsmittelaufwändig ist. Dementsprechend ist klar, dass es eine starke Organisationsaufwand-Kostengrundlage für die Aufzeichnung nur eines Video- und Audiosignals der "globalen Ansicht" gibt.
Nunmehr anhand von 37 wird eine Übersicht der Videokonferenz-Aufzeichnungsanwendung der vorliegenden Erfindung diskutiert. Wenn der Anwender, z. B. 1802, das hier gelehrte Videokonferenz-Aufzeichnungsmerkmal aufrufen möchte, wird eine Anforderung an den AVNM 1810 gesendet. Der AVNM 1810 leitet dann bei 1812 eine Anforderung an die Videokonferenz-Aufzeichnungsanwendung 1830 weiter, um eine Konferenzaufzeichnungssitzung zu initiieren. Daraufhin übergibt die Videokonferenz-Aufzeichnungsanwendung 1830 eine Sitzungsanforderung 1814 an das AVSS 1816. Bei 1818 baut das AVSS 1816 eine Verbindungssteuerung mit dem AVNM 1810 auf. Außerdem ordnet die Videokonferenz-Aufzeichnungsanwendung 1830 dem AVNM 1810 bei 1820 eine Konferenzbrücke zu.
Bei 1806 ruft ein Anwender einen Browser 1821 auf, der seinerseits eine Videowiedergabeanwendung 1822 aufruft. Bei 1824 initiiert der Aufruf der Videowiedergabeanwendung 1822 eine Sitzungsanforderung an das AVSS 1816. Bei 1820 baut das AVSS 1816 in Reaktion auf die Sitzungsanforderung eine Verbindungssteuerung mit dem AVNM 1810 auf.
Nunmehr anhand von 38 wird eine Übersicht mehrerer zur Implementierung der Videokonferenzaufzeichnung erforderlicher der Komponenten der vorliegenden Erfindung diskutiert. Anhand dieser Figur kann eine erste Workstation 1802 irgendeine einer Anzahl zuvor diskutierter Workstationimplementierungen umfassen, die eine Kamera 2302, ein Mikrophon 2304, einen Monitor/eine Videokarte 2306 und einen Lautsprecher 2308 umfassen. Diese Komponenten können optional mittels einer Verkabelung oder anderen dem Durchschnittsfachmann auf dem Gebiet bekannten Verbindungsmitteln mit einer zusätzlichen Hardwareelement-Zusatzbox 2310 verbunden sein, die ihrerseits mit der MLAN-Vermittlung 2206 verbunden ist. Obgleich die vorliegende Erfindung die Integration einer Anzahl von Workstations in die MLAN-Vermittlung 2206 betrachtet, ist in dieser Figur aus Veranschaulichungsgründen nur eine zweite Workstation 1804 gezeigt. Der Durchschnittsfachmann auf dem Gebiet erkennt, dass in dieser Weise eine Anzahl von Workstations verbunden sein können.
Bei 2332 ist die MLAN-Vermittlung 2206 mit dem AVNM 1810, in dieser Ansicht nicht gezeigt, verbunden. Eine Konferenzbrücke 2208 und ein AVSS 1816 sind einzeln mit der MLAN-Vermittlung 2206 verbunden. Die Konferenzbrücke 2208 umfasst ferner ein Sender-Empfänger-Gerät 2336 in funktionaler Kombination mit der MLAN-Vermittlung 2206. Mit dem Sender-Empfänger-Gerät 2336 sind eine Videovermittlung 2340 und ein Audiomischer 2342 verbunden. Ferner ist mit der Videovermittlung 2340 ein Videomosaikgenerator 2346 verbunden.
Das AVSS 1816 enthält einen weiteren Sender-Empfänger 2352, einen Codierer 2354 und einen Decodierer 2356. Mit dem Codierer 2354 und mit dem Decodierer 2356 ist eine Speichervorrichtung 2408 gekoppelt.
Wenn eine Punkt-zu-Punkt- oder Zweiteilnehmervideokonferenz aufgebaut wird, wird, wie in 39 gezeigt ist, zwischen den Workstations 1802 und 1804 über die MLAN-Vermittlung 2206 eine Punkt-zu-Punkt-Konnektivität aufgebaut. Von der Kamera 2302 der Workstation 1802 wird ein Videosignal 2902 zum Monitor 2320 der Workstation 1804 gesendet. Darüber hinaus wird vom Mikrophon 2304 ein Audiosignal 2904 zum Lautsprecher 2322 der Workstation 1804 gesendet. Ähnlich sendet die Kamera 2316 der Workstation 1804 ihr Videosignal 2906 zum Monitor 2306 der Workstation 1802, während das Mikrophon 2318 sein Audiosignal 2908 zum Lautsprecher 2308 sendet. Weiter anhand dieser Figur ruft die einfache Implementierung einer Konferenz zwischen zwei Anwendern weder die Konferenzbrücke 2208 noch das AVSS 1816 auf.
Wie in 40 gezeigt ist, ruft die Aufnahme eines Drittanbieters oder die Implementierung der Videokonferenz-Aufzeichnungsanforderung eine Konferenzbrücke 2208 auf. Obgleich diese Figur zur Veranschaulichung der Prinzipien eines Mehrteilnehmer-Konferenzanrufs verwendet werden kann, sind hier aus Klarheitsgründen nur zwei Workstations veranschaulicht. Weiter anhand der Figur ist der Aufruf der Konferenzbrücke 2208 gezeigt. In diesem Fall werden Audiosignale 3002 und 3004 mittels der MLAN-Vermittlung 2206 über den Sender-Empfänger 2336 zum Audiomischer 2342 und somit zu ihren jeweiligen Empfängern gesendet. Auf ähnliche Weise werden Videosignale 2508 und 2502 über die MLAN-Vermittlung 2206 über das Sender-Empfänger-Gerät 2336 und über die Videovermittlung 2340 zum Videomosaikgenerator 2346 gesendet. Der Mosaikgenerator 2346 sendet an die Videovermittlung 2340 ein Signal, das ein Mosaikvideo 2510 enthält, das alle Anwender zeigt. Daraufhin teilt die Videovermittlung 2340 dieses Videosignal in die Signale 2506 und 2506'.
Wenn ein Anwender eine Videokonferenz-Aufzeichnungsanforderung initiiert, ist die Signalverarbeitung mit den in 41 veranschaulichten Hinzufügungen im Wesentlichen ähnlich der in 40 gezeigten. Anhand der letzteren Figur wird ein drittes Videosignal 3104, das wieder das Videomosaik 2510 umfasst, in der Videovermittlung 2340 geteilt und über die MLAN-Vermittlung 2206 an das AVSS 1816 gesendet. Ähnlich werden die Audiosignale 3002 und 3004 durch den Audiomischer 2342 kombiniert, der ein Summenaudiosignal 3102 erzeugt. Das Summenaudiosignal 3102 wird über die MLAN-Vermittlung 2206 an das AVSS 1816 gesendet. Das Videomosaik 2510 und das Summenaudiosignal werden beim Sender-Empfänger 2352 empfangen, beim Codierer 2354 codiert und in der Speichervorrichtung 2408 gespeichert. Eine nachfolgende Anforderung von einem Anwender für in der Speichervorrichtung 2408 gespeicherte Informationen wird mittels des Decodierers 2356 über die MLAN-Vermittlung 2206 und somit zu der Workstation des anfordernden Anwenders gesendet.
Die vorliegende Erfindung betrachtet, dass ein Anwender zwischen irgendwelchen einer Anzahl von durch den Mosaikgenerator 2346 zur Verfügung gestellten Videodarstellungen auswählen kann. In den 42, 43 und 44 sind veranschaulichend, aber nicht einschränkend, drei solche Alternativen gezeigt. Das zuvor diskutierte Szenarium ist in 42 gezeigt, wobei der Anwender 1, der Anwender 2 und das AVSS alle ein Mosaik beider Anwender sehen. Nunmehr anhand von 43 ist die jedem Anwender bei seiner Auswahl dargestellte Ansicht die einer Nahaufnahme des anderen Anwenders. Trotz dieser Auswahl empfängt das AVSS weiter ein Mosaik aller Anwender. Nunmehr anhand von 44 sieht der Anwender 1 in dieser Ansicht ein Mosaik von sich selbst und des Anwenders 2 und sieht der Anwender 2 eine Nahaufnahme des Anwenders 1. Wie zuvor empfängt das AVSS weiter ein Mosaik aller Anwender, die aufgezeichnet werden.
Die zur Implementierung der zuvor diskutierten Videokonferenz-Aufzeichnungsanwendung erforderliche Logik ist in dem Datenablaufplan von 45 dargestellt. Diese Logik kann als Software, als Hardware, als Firmware oder als irgendeine Kombination der Vorstehenden implementiert sein. Anhand dieser Figur wird bei 3402 eine Videokonferenz-Aufzeichnungsanforderung initiiert. Die Prinzipien der vorliegenden Erfindung betrachten spezifisch eine Anzahl von Methodiken zum Initiieren dieser Anforderung. Eine solche Methodik ist zuvor diskutiert worden, wobei ein gegebener Anwender eine Anforderung für die Videokonferenzaufzeichnung initiiert. Eine solche Anforderung macht die aufgezeichnete Videokonferenz für irgendeinen Anwender mit Berechtigung dafür nutzbar. Eine Alternative zu dieser Ausführungsform betrachtet die Situation, in der es aus juristischen oder Aufzeichnungszwecken erwünscht ist, dass alle Videokonferenzen aufgezeichnet werden. In dieser Alternative kann der Administrator mit administrativer Verantwortlichkeit für das hier gelehrte und offenbarte System nach seiner Wahl beauftragen, dass die Videokonferenzaufzeichnung für alle durchgeführten Videokonferenzen oder für bestimmte angegebene Videokonferenzen, z. B. zwischen einer angegebenen Menge von Anwendern, implementiert wird.
Wenn die Videokonferenz-Aufzeichnungsanforderung 3402 initiiert wird, wird bei 3404 die in dieser Ansicht nicht gezeigte Videokonferenz-Aufzeichnungsanwendung 1830 initiiert. Wenn zuvor keine Konferenzbrücke zugeordnet war, wird nun bei 3406 eine solche Konferenzbrücke zugeordnet. Die Initiierung der Konferenzaufzeichnungsanwendung initiiert bei 3408 eine AVSS-Sitzungsanforderung – die ihrerseits bei 3410 eine Verbindungssteuerung mit dem AVNM 1810 aufbaut. Dies baut wiederum bei 3412 eine AVNM-Konnektivität mit den Anwendern auf.
Die Konferenzbrückenzuweisung 3406 ermöglicht ferner bei 3414 den Aufbau einer Netz-A/V-Verbindung von einer in dieser Figur nicht gezeigten MLAN-Vermittlung 2206. Die Videosignale werden bei 3416 zur Videovermittlung 2340 gesendet, die die Signale bei 3420 ihrerseits zum Mosaikgenerator 2346 sendet. Der Mosaikgenerator 2346 sendet das Mosaikvideo seinerseits bei 3416 zur Videovermittlung 2342 zurück, von wo das Mosaikvideo 2510 bei 3418 zum Anwender und zum AVSS 1816 gesendet wird.
Wiederum anhand des Schritts 3414 werden bei 3422 Audiosignale zum Audiomischer 2342 gesendet. Der Audiomischer 2342 sendet bei 3426 die Summenaudiosignale zum AVSS 1816. Wie in Schritt 3424 gezeigt ist, sendet der Audiomischer 2342 ferner zu jedem Anwender eine Kopie des Summenaudiosignals abzüglich des eigenen Audiosignals dieses Anwenders.
An diesem Punkt werden in Schritt 3430 das Mosaikvideo und das Summenaudio in der Speichervorrichtung 2408 gespeichert. Wenn ein Anwender mit Berechtigungen auf aufgezeichnete Videokonferenzinformationen zugreifen möchte, kann er dies mittels eines durch die MCG aufgerufenen Browsers 1821, in dieser Ansicht nicht gezeigt, oder mittels einer anderen Anwenderschnittstelle bei 3450 tun. Daraufhin greift der Browser 1821 bei 3452 auf die Videowiedergabeanwendung 1822 zu. Der Schritt 3452 initiiert wiederum bei 3408 eine weitere AVSS-Sitzungsanforderung, was mehrere gleichzeitige Aufzeichnungs- und Wiedergabesitzungen durch berechtigte Anwender ermöglicht.
Nunmehr anhand von 46 wird die Wiedergabe aufgezeichneter Videokonferenzanrufe erläutert. In der Speichervorrichtung 2408 des AVSS 1816 ist ein zuvor aufgezeichneter Konferenzanruf gespeichert. Wenn die Wiedergabe des Konferenzanrufs aufgerufen wird, wird er bei 4170 über den Decodierer 2356 gesendet, der den aufgezeichneten Konferenzanruf in seine Mischsignal-Video- und Audiosignalkomponente, 4180 bzw. 4182, trennt. In dem in 46 dargestellten Beispiel sind zur Veranschaulichungsklarheit nur zwei Konferenzteilnehmer, bei den Workstations 1802 und 1804, gezeigt. Natürlich betrachten die Prinzipien dieser Ausführungsform der vorliegenden Erfindung eine größere Mehrzahl von Anwender-Workstations.
Das Videosignal 4180 wird über die MLAN-Vermittlung 2206 zum Sender-Empfänger 2336 und somit über die Videovermittlung 2340 zum Mosaikgenerator 2346 gesendet. Es wird angemerkt, dass der Mosaikgenerator Eingänge für jeweils N Konferenzteilnehmer zuzüglich einem für das Videosignal 4180 besitzt. Auf diese Weise werden zuvor aufgezeichnete Videokonferenzen während der Wiedergabe als zusätzliche Konferenzteilnehmer behandelt. Die Ausgabe vom Mosaikgenerator 2346 ist ein Mosaik 4190 mit N + 1 Teilbildern: einem für jeden Teilnehmer zuzüglich einem für die aufgezeichnete Konferenz, die wiedergegeben wird. Die Ausgabe vom Mosaikgenerator 2346 wird zur Videovermittlung 2340 gesendet, wo sie in zwei Videosignale, 4188 und 4188', geteilt und wie gezeigt an die Workstations 1802 und 1804 gesendet wird.
Gleichzeitig wird ein entsprechendes Audiosignal 4182 über die MLAN-Vermittlung 2206 und über das Sender-Empfänger-Gerät 2336 zum Audiomischer 2342 gesendet. Der Audiomischer 2342 summiert die Audioeingaben 3004 und 3002 von den Anwendern bei den Workstations 1802 bzw. 1804 mit dem Audiosignal 4182 auf folgende Weise: Ein erstes Summenaudiosignal 4184 wird zu einem ersten Anwender bei der Workstation 1802 gesendet und ist aus der Summe der Audiosignale von einem zweiten Anwender bei der Workstation 1804 und von dem aufgezeichneten Videosignal 4182 zusammengesetzt. Ein zweites Summensignal 4186 wird zu einem zweiten Anwender bei der Workstation 1804 ge sendet und ist aus der Summe der Audiosignale von dem ersten Anwender bei der Workstation 1802 und aus dem aufgezeichneten Videosignal 4182 zusammengesetzt. Es wird angemerkt, dass das eigene Signal der Workstation in dieser Ausführungsform zur Verbesserung der Audioklarheit in jedem Fall nicht zu dieser Workstation zurückgesendet wird, sondern das Summensignal nur Audio von anderen "Teilnehmern" enthält, das das Signal von der aufgezeichneten Konferenz enthält. Außerdem kann das System ein Summenaudiosignal für alle Teilnehmer enthalten.
Aus dem Vorstehenden werden die folgenden Merkmale und Vorteile einer ersten Ausführungsform der vorliegenden Erfindung gezeigt:

1. Die "globale Ansicht" der Summe der Audiosignale aller Anwender wird von der Videokonferenzanwendung verwendet, um alle Teile des Gesprächs zu erfassen.
2. Für Mehrpunktkonferenzen wird die "globale Ansicht" sowohl für Audio als auch für Video leicht auf folgende Weise von der Konferenzbrückenhardware erhalten:
A. Das Video der globalen Ansicht wird natürlich durch die Videomosaikbox erzeugt.
B. Das Audio der globalen Ansicht wird durch eine spezielle Mischung in dem Audiomatrixmischer bereitgestellt. Diese "globale" Mischung ist genau die bei der Mehrfachanordnung verteilter Konferenzbrücken verwendete. Mit anderen Worten, die "globale" Mischung ist das aufgezeichnete Audiosignal. Eine Teilmenge der globalen Mischung wird an jeden der Konferenzanwender gesendet. Diese Teilmenge enthält die globale Mischung abzüglich des eigenen Audiosignals des Anwenders. Dies ist notwendig, um ein "Echo" und andere nachteilige Audiodefekte auszuschließen.

3. Für Punkt-zu-Punkt-Anrufe (d. h. für eine Zwei-Anwender-Konferenz) ist aus der Hardwareschicht heraus inhärent kein Signal verfügbar, das die globale Ansicht erfasst, wobei es wie beschrieben synthetisch erzeugt wird.

In Mehrteilnehmerkonferenzen wird eine Konferenzbrücke automatisch zugeordnet. Wo ein einzelner globaler Standpunkt aufgezeichnet werden soll, beauftragen zwei Anwenderanrufe, dass durch die Videokonferenzanwendung eine Konferenzbrücke zugewiesen wird. Diese Konferenzbrücke wird am effizientesten verwendet, wenn sie aus dem gleichen Pool kommt, der für Echtzeit-Mehrteilnehmerkonferenzen verwendet wird.
Im Fall verlängerter Konferenzaufzeichnungen kann es erwünscht sein, Zeitpunkte, zu denen bestimmte Diskussionsereignisse aufgetreten sind, zu "kennzeichnen". Eine Ausführungsform der vorliegenden Erfindung betrachtet die Verwendung solcher Identifizierungskennzeichen. Vorzugsweise erhalten die Identifizierungskennzeichen eine eindeutige Kennung, z. B. ein suchbares Textetikett oder einen Buchstaben, wodurch ein spezifisches Diskussionsereignis eindeutig identifiziert wird.
Es wird eine Anwenderschnittstelle bereitgestellt, um eine Konferenzaufzeichnung aufzurufen und zu benennen und um dort, wo sie implementiert ist, die Identifizierungskennzeichen-Schnittstelle aufzurufen und zu betreiben. In der MCG sind zusätzliche Anwenderschnittstellen für die Nachrichtenbenachrichtigung, für das Nachrichten-Browsing und für den Aufruf der Nachrichtenwiedergabe implementiert.
Ferner wird angemerkt, dass die Konferenzbrücke nicht empfindlich in Bezug auf das Wesen der Eingangsquelle ist. Dementsprechend kann die Eingabe veranschaulichend, aber nicht beschränkend, mittels Sicherheitskamera, VCR oder im Wesentlichen irgendeiner anderen Video- oder Audioquelle usw. erfolgen. Darüber hinaus kann ein Konferenzanruf spezifisch eine zuvor aufgezeichnete Videodatei enthalten. Alle diese Eingaben können aufgezeichnet werden, während sie diskutiert werden. Daraus, und wie zuvor diskutiert wurde, folgt, dass das System mehrere gleichzeitige Quellsitzungen ermöglicht, z. B.: eine oder mehrere Aufzeichnungssitzungen und eine oder mehrere Wiedergabesitzungen, wobei sie alle vollständig unabhängig sind. Jede ist mit der Konferenzbrücke verbunden, wobei die Anwenderschnittstellen während des Videotreffens für einen oder für mehrere Anwender verfügbar sind.
Die zuvor diskutierte Videokonferenz-Aufzeichnungsanwendung nutzt und implementiert die folgenden Fähigkeiten:

1. Allgemeine Steuerprotokollschnittstelle/API.
2. Allgemeines Mehrplattform-Audio-Video-Aufzeichnungs/Wiedergabe-Hilfsmittel, das hier als die "Betriebsartsteuerungs-GUI" oder als die "MCG" bezeichnet wird.
3. Mehrsitzungs-Aufzeichnungs/Wiedergabe-Fähigkeit.
4. Analoge Audio-Video-Eingabe und -Ausgabe.
5. Wenn ein Codierer zugewiesen wird, wird gleichzeitig ein Decodierer zugewiesen. Dies stellt sicher, dass der Decodierer während der Aufzeichnungssitzung immer für die Durchsicht verfügbar ist.
6. Variable Kapazitätsskalierung zur Anpassung an die Notwendigkeiten unterstützter Anwendungen und Hardwarekonfigurationen.

Je nachdem, wie Weitverkehrsanrufe behandelt werden oder wo es in Bezug auf die Architektur zweckmäßig ist, können darüber hinaus die folgenden Fähigkeiten erforderlich oder vorteilhaft sein.

7. Dateiübertragungsfähigkeit (Zieh-Modell) zwischen AVSSs, die durch spezifische durch Anwendungen gestellte Dateiübertragungsanforderungen angesteuert wird.
8. Effektives "Zurückschleifen" von ankommendem Video zu abgehendem Video bei der AVSC während der Aufzeichnungsbetriebsart.
9. Videoeditierfähigkeiten. Diese Fähigkeit kann intern als Teil eines Anwendungsprogramms implementiert sein oder kann alternativ fähig sein, Drittanbieter-Videoeditionen und/oder -Audioeditoren aufzurufen.

4.16.4 Videodokumente
Die Videodokumenteanwendung ermöglicht, dass gespeicherte Videodateien in einem elektronischen Onlinedokument wie etwa Word^TM oder Framemaker^TM enthalten sind. Dies kann für viele unternehmensweite Anwendungen verwendet werden, einschließlich, aber nicht notwendig beschränkt auf: Schulung, Firmenspeicher, Prozeduren, Bezugnahmen, Vertrieb usw. Wie im Folgenden diskutiert wird, gibt es außerdem viele potentielle Überschneidungen mit dem Intranet und mit dem Internet.
In 19 ist eine Ausführungsform dieses Merkmals der vorliegenden Erfindung gezeigt. Anhand dieser Figur ist im Wesentlichen irgendein Archivvideo mit Text oder Dokumenten kombinierbar. Darüber hinaus umfassen die Prinzipien der vorliegenden Erfindung Videoüberlagerungsgraphiken, die dem Video überlagert werden, sowie ein Kompendium mehrerer Videodateien, die ferner zusätzlichen Text oder zusätzliche Graphik, selbstständige Videos und MIME-Anhangs-Videodateien enthalten. Dementsprechend kann das Videodokument zusammen mit dem Dokument ein Videofenster hervorbringen, wie es vom Anwender gesehen wird, oder sich dem Dokument überlagern, was ermöglicht, dass der Anwender das Video abspielt, während er das Dokument betrachtet. Das Video kann aus irgendeiner zuvor diskutierten Quelle kommen. Videos in einem Videodokument sind während eines Konferenzanrufs oder durch Video-Mail oder -mitteilungsübermittlung gemeinsam nutzbar.
Eine Ausführungsform der vorliegenden Erfindung betrachtet das Anhängen des Betrachters als einen MIME- oder anderen funktionalen Anhang an eine Nachricht. Ein gegebener Anruf kann erweitert werden, um weitere Teilnehmer und andere Mechanismen zu enthalten, um das Dokument mit einer laufenden Konferenz, mit anderen Worten, durch den Aufbau einer weiteren gleichzeitigen Sitzung, zusammenzuführen. Dies ist mehr als einfaches Video, da es ermöglicht, dass sich synchronisierte Graphik entweder dem Video überlagert oder das Video begleitet.
Natürlich wirft irgendeine solche Implementierung, die die Schnittstelle mit Drittanbietersoftware erfordert, einige Interoperabilitätsfragen auf. Einige dieser Fragen enthalten:
In einigen Implementierung die Notwendigkeit, unter Verwendung von MIME-Erweiterungen einen zusätzlichen Dokumenttyp für das unterstützte Paket zur Verfügung zu stellen.
Das Workstation-Konferenz-Client-Videofenster und die MCG können für die Videolieferung verwendet werden. Allerdings kann es in einigen Anwendungen der Prinzipien der vorliegenden Erfindung ästhetisch sinnvoller sein, das Videofenster und einige zugeordnete Steuerungen, z. B. die Wiedergabesteuerung, in das Dokument selbst aufzunehmen. Ein Mittel zur Implementierung dieses Merkmals wäre ein Graphiktyp mit einem verankerten Teilbild.
Die Notwendigkeit, in einigen Implementierungen sowohl "Videotyp"-Löschereignisse als auch "Gesamtes-Dokument"-Löschereignisse zu erfassen, um das Dateisystem nicht mit ungenutzten Videodateien zu füllen.
Die Notwendigkeit, wieder in einigen Implementierungen, eines automatischen Dateiübertragungs- oder Anwenderwarnungsmechanismus, um sicherzustellen, dass Videodateien übertragen werden, wenn das Dokument zu einer Domäne übertragen wird, die nicht durch das verfassende AVSS bedient wird.
Natürlich ist jede dieser Fragen stark anwendungsspezifisch. Die Implementierung spezifischer Lösungen hierzu liegt im Licht der hier aufgezählten Lehren im Rahmen des Durchschnittsfachmanns auf dem Gebiet.
Das System kann Videodokumentanwendungen entweder unter Verwendung herkömmlicher Drittanbieter-Dokumentsysteme oder von Dokumentsystemen, die verbessert worden sind, um die Fähigkeit zum Erhalten und/oder zum Ablegen/Kopieren von Ereignissen aus dem Dokumentsystem zu bieten, unterstützen.
Die vorliegende Erfindung kann Textverarbeitungs-GUIs und die MCG verwenden. Dementsprechend sind keine zusätzlichen Anwenderschnittstellen erforderlich.
Die Videodokumentanwendung erfordert die folgenden Fähigkeiten:

1. Allgemeine Steuerprotokollschnittstelle/API.
2. Ein allgemeines Mehrplattform-Audio-Video-Aufzeichnungs/Wiedergabe-Hilfsmittel (ähnlich vfstool), das hier als die "Betriebsartsteuerungs-GUI" oder "MCG" bezeichnet wird.
3. Mehrsitzungs-Aufzeichnungs/Wiedergabe-Fähigkeit.
4. Analoge A/V-E/A.
5. Wenn ein Codierer zugewiesen wird, wird gleichzeitig ein AVSC-Decodierer zugewiesen. Dies stellt sicher, dass der Decodierer während der Aufzeichnungssitzung immer für die Durchsicht verfügbar ist.
6. Variable Kapazitätsskalierung zur Anpassung an die Notwendigkeiten unterstützter Anwendungen.
7. Dateiübertragungsfähigkeit (Zieh-Modell) zwischen AVSS, die durch spezifische durch Anwendungen gestellte Dateiübertragungsanforderungen angesteuert wird.
8. Effektives "Zurückschleifen" von ankommendem Video zu abgehenden Video bei der AVSC während der Aufzeichnung.

Außerdem ist das folgende Merkmal erforderlich, um weitere Videodateiquellen aufzunehmen:

9. Die Fähigkeit zum Annehmen und Wiedergeben geeigneter digitaler Dateien von Drittanbietern, wie sie durch Anwendungen gesteuert wird.

Schließlich ist in einer ersten Ausführungsform der vorliegenden Erfindung zur Unterstützung des Internet-Zugriffs das folgende Merkmal erforderlich:

10. Die Fähigkeit zum Übertragen geeigneter digitaler Dateien an Drittanbieter, wie sie durch Anwendungen gesteuert wird.
12. Videoeditierfähigkeit. Diese Fähigkeit kann intern als Teil eines Anwen dungsprogramms implementiert sein oder kann alternativ fähig sein, Drittanbieter-Videoeditoren und/oder -Audioeditoren aufzurufen.

4.16.5 Universalvideospeicher
In vielen Fällen bestehen Notwendigkeiten für weniger anspruchsvolle "Roh"-Video-Speicherfähigkeiten, die von Workstations über das Videoverteilungsnetz erreichbar sind. Diese "Roh"-Notwendigkeiten tragen zur Funktionalität eines VCR oder einer beschreibbaren Laserplatte, auf die über das Netz zugegriffen werden kann, zu, wobei seine/ihre Informationen gemäß den Dateisystemkonventionen organisiert sind. Quellen für den gespeicherten Videoinhalt können z. B. Clips von gesendeten Nachrichtenprogrammen, Kopien von Camcorder-Filmlängen, erfasste Segmente von Videomagnetbändern, von den CDs, von der DVD oder vom Internet übertragene Videodateien sein. Obgleich Anwender-Workstations wahrscheinlich an der Annahme, Erfassung oder Übertragung solcher Videoinformationen (über Hilfs-Audio/Video-Eingangsbuchsen an der Desktop-Workstation, Dateiübertragungsaktionen usw.) beteiligt sind, steht die Entwicklung dieser Videoklasse im Allgemeinen im Gegensatz zu Video, das von Videoanrufen, Videokonferenzen, dem Nachrichtenverfassen oder dem Videodokumentverfassen erfasst wird. Ferner würde die Speicherung dieser Klasse von "Roh"-Videoinformationen nicht die Ergänzung des Videos mit irgendwelchen Anmerkungen, Text, gemeinsam genutzter Graphik usw. unterstützen.
Gegenwärtige Trends bei Computern führen Anwender dazu, solche "Roh"-Videoclips in ihrer vernetzten Computerumgebung wie irgendeine andere Datei zu behandeln, einzelne Kopien großer Videodateien frei zu kopieren und sie auf einer lokalen Platte oder in Standard-Datennetz-Dateiservern zu speichern. Ein solcher Ansatz hat mehrere Nachteile:

• Ein solches Video ist nur verfügbar bei Workstations mit Decodierungsfähigkeiten für das benötigte Videoprotokoll und Dateiformat.
• Datennetze und Standarddateisysteme werden selbst bei einem mäßigen Videonutzungsbetrag stark belastet.
• Große Anzahlen privater Kopien großer Videodateien belasten lokale Platten und Dateiserver durch riesige Vielfache noch weiter.

Für den Fachmann auf dem Gebiet ist offensichtlich, dass die vorliegende Erfindung diese Nachteile leicht behandelt, indem sie Folgendes bietet:

• zentralisierte, gemeinsam genutzte Codierung, Decodierung und Transcodierung,
• Verschieben von Video eher über geeignete hochentwickelte Videonetze als über Datennetze
• gemeinsame Nutzung einer kleinen Anzahl (einer bis weniger) dieser großen Dateien über die gesamte Gemeinschaft von Anwendern, die auf die Datei zugreifen müssen
• weitere Zulässigkeit von Dateiübertragung und digitalem Streaming, wo sie erforderlich oder erwünscht sind.

Um dies zu tun, müssen die verwendeten Videodateiformate an die durch das AVSS unterstützten angepasst sein.
Durch geeignete Konstruktion der Behandlung dieser Klasse von Videoinformationen der Erfindung können die Videoinformationen mit anderen Anwendungstypen frei ausgetauscht werden. Zum Beispiel können Videoinformationen in Abhängigkeit von den Dateiberechtigungen zwischen "Roh"-Videoclips der Universalvideospeicheranwendung und anderen AVSS-Anwendungen ausgetauscht werden:

• Ein "Roh"-Videoclip kann in eine Video-Mail-Nachricht, in ein Videodokument, in Videoveröffentlichungsanwendungen, in Videowebseiten usw. eingebaut werden.
• Ein "Roh"-Videoclip kann in einem Videoanruf oder in einer Videokonferenz betrachtet werden.
• Irgendein in einem aufgezeichneten Videoanruf, in einer aufgezeichneten Videokonferenz, in einer Videonachricht oder in einer anderen vernetzten Videoanwendung erfasstes Video könnte als ein "Roh"-Videoclip erfasst werden.

In einigen Situationen würde dieser Austausch von Videoinformationen zwischen Anwendungen eine vollständig ungeänderte Videodatei erfordern. Die tatsächlichen Verfahren für den Austausch können für diesen Fall wenigstens auf eine von zwei Arten ausgeführt werden:

• Erzeugen eines neuen Anwendungseigentümers der existierenden Datei
• Wiedergeben der Datei als gerendertes Video, das daraufhin, möglicherweise während der Betrachtung, durch eine weitere vernetzte Videoanwendung neu aufgezeichnet wird.

Weitere Methoden sind für den Fachmann auf dem Gebiet ebenfalls möglich.
In weiteren Situationen müssen nur Segmente einer Originalvideodatei zwischen Anwendungen übertragen werden oder können weitere Bearbeitungen der Originalvideodatei erforderlich sein. Für diese Fälle könnten die tatsächlichen Verfahren für den Austausch wenigstens eine der zwei folgenden Arten enthalten:

• Verwenden eines Videodateieditors an der existierenden Datei zum Erzeugen einer neuen (editierten) Datei und Zuweisen des richtigen Anwendungseigentümers zu dieser neuen Datei
• Wiedergeben der Datei als gerendertes Video und während des Betrachtens Neuaufzeichnen gewählter Segmente mittels einer weiteren vernetzten Videoanwendung.

Weitere Verfahren sind für den Fachmann auf dem Gebiet ebenfalls möglich.
In den meisten Implementierungen erfordert die Universalvideospeicheranwendung die folgenden Fähigkeiten:

1. Allgemeine Steuerprotokollschnittstelle/API.
2. Ein allgemeines Mehrplattform-Audio-Video-Aufzeichnungs/Wiedergabe-Hilfsmittel (ähnlich vfstool), das hier als die "Betriebsartsteuerungs-GUI" oder "MCG" bezeichnet wird.
3. Mehrsitzungs-Aufzeichnungs/Wiedergabe-Fähigkeit.
4. Analoge A/V-E/A.
5. Wenn ein Codierer zugewiesen wird, wird gleichzeitig ein AVSC-Decodierer zugewiesen. Dies stellt sicher, dass der Decodierer während der Aufzeichnungssitzung immer für die Durchsicht verfügbar ist.
6. Variable Kapazitätsskalierung zur Anpassung an die Notwendigkeiten unterstützter Anwendungen.
7. Dateiübertragungsfähigkeit (Zieh-Modell) zwischen AVSS, die durch spezifische durch Anwendungen gestellte Dateiübertragungsanforderungen angesteuert wird.
8. Effektives "Zurückschleifen" von ankommendem Video zu abgehendem Video bei der AVSC während der Aufzeichnung.
9. Die Fähigkeit zum Annehmen und Wiedergeben geeigneter digitaler Dateien von Drittanbietern, wie sie durch Anwendungen gesteuert wird.
10. Die Fähigkeit zum Übertragen geeigneter digitaler Dateien an Drittanbieter, wie sie durch Anwendungen gesteuert wird.
12. Videoeditierfähigkeiten. Diese Fähigkeit kann intern als Teil eines Anwendungsprogramms implementiert sein oder kann alternativ fähig sein, Drittanbieter-Videoeditoren und/oder -Audioeditoren aufzurufen.

In einigen Fällen begrenzter Domänen können nur die Merkmale 1-8 erforderlich sein.
4.16.6 Intranet-Videospeicherhilfsmittel
Intranet bezieht sich auf die Verwendung von Internet-Hilfsmitteln wie etwa Webseiten, Web-Browsern und Web-Sites als Mittel zur Verteilung unternehmens interner Informationen. Darin akzeptieren Webseiten-Verfassungshilfsmittel üblicherweise MIME-Anhänge, wobei in einem mit der Erfindung ausgestatteten Unternehmen in einer Webseite selbstverständlich das AVSS-Video-MIME-Anhangs-Dienstgrundelement verwendet werden kann. Wie in den 3 und 4 gezeigt ist, kann das AVSS leicht mit dem Internet verbunden werden, um die Verwendung seiner Fähigkeiten mit Webseiten und weiteren Internet-Hilfsmitteln zu ermöglichen.
Die Verwendung des AVSS-Video-MIME-Anhangs ermöglicht nicht nur das Anbringen von Videoclips in beliebigen Intranet-Webseiten, sondern ebenfalls irgendwelche weiteren Merkmale wie etwa synchronisierter Shareboard-Sitzungen (später diskutiert), die in den MIME-Anhängen enthalten sein könnten. Da irgendeine AVSS-Videodatei oder irgendein AVSS-MIME-Anhang in Abhängigkeit von Genehmigungen leicht von AVSS-Anwendung zu AVSS-Anwendung übertragen werden kann, kann das Intranet ferner als ein weiteres nützliches unternehmensinternes Videoveröffentlichungsverfahren verwendet werden.
Es wird angemerkt, dass durch den Fachmann auf dem Gebiet weitere Typen AVSS-gestützter Videoanwendungen geschrieben werden könnten, um als Webseiten-Bausteine zu dienen. Somit können die oben beschriebenen AVSS-Vorteile vom Fachmann auf dem Gebiet über andere Mittel als den AVSS-MIME-Anhang erhalten werden.
Die Intranet-Videospeicheranwendung ermöglicht, dass innerhalb des Unternehmens Roh-Audio-Video-Dateien sowie Videodokumente in Übereinstimmung mit Intranet-Browser-Schnittstellen und weiteren Konventionen gespeichert werden, durchsucht werden und auf sie zugegriffen wird.
Die Universalvideospeicheranwendung erfordert in den meisten Implementierungen davon die folgenden Fähigkeiten:

1. Allgemeine Steuerprotokollschnittstelle/API.
2. Ein allgemeines Mehrplattform-Audio-Video-Aufzeichnungs/Wiedergabe-Hilfsmittel (ähnlich vfstool), das hier als die "Betriebsartsteuerungs-GUI" oder "MCG" bezeichnet wird.
3. Mehrsitzungs-Aufzeichnungs/Wiedergabe-Fähigkeit.
4. Analoge A/V-E/A.
5. Wenn ein Codierer zugewiesen wird, wird gleichzeitig ein AVSC-Decodierer zugewiesen. Dies stellt sicher, dass der Decodierer während der Aufzeichnungssitzung immer für die Durchsicht verfügbar ist.
6. Variable Kapazitätsskalierung zur Anpassung an die Notwendigkeiten unterstützter Anwendungen.
7. Dateiübertragungsfähigkeit (Zieh-Modell) zwischen AVSS, die durch spezifische durch Anwendungen gestellte Dateiübertragungsanforderungen angesteuert wird.
8. Effektives "Zurückschleifen" von ankommendem Video zu abgehendem Video bei der AVSC während der Aufzeichnung.
9. Die Fähigkeit zum Annehmen und Wiedergeben geeigneter digitaler Dateien von Drittanbietern, wie sie durch Anwendungen gesteuert wird.
12. Videoeditierfähigkeiten. Diese Fähigkeit kann intern als Teil eines Anwendungsprogramms implementiert sein oder kann alternativ fähig sein, Drittanbieter-Videoeditoren und/oder -Audioeditoren aufzurufen.

In einigen Fällen beschränkter Domänen können nur die Merkmale 1-8 erforderlich sein.
4.16.7 Internet-Gateway
Gegenwärtige Trends in der Desktop-Computertechnologie, Vernetzung und Internet-Nutzung haben gerade das Auftreten von Videodateien und des Streaming über das Internet eingeleitet. Diese wenigen frühen Videoaustausche haben im Wesentlichen alle niedrige Auflösung und üblicherweise niedrige Bildwiederholrate, sodass die sich daraus ergebende Auswirkung auf die beschränkte Internet-Bandbreite, auf die beschränkte Unternehmensnetzbandbreite und auf den beschränkten Unternehmensdateisystemplatz merklich, aber beherrschbar ist. Da die Bedeutung von Video für das Geschäft schnell zunimmt, werden die be schränkte Internet-Bandbreite, die beschränkte Unternehmungsnetzbandbreite und der beschränkte Unternehmensdateisystemplatz sofort beansprucht. Außerdem wird angemerkt, dass die zunehmende Geschäftsverwendung von Video zunehmende Auflösung und Bildwiederholrate fordert, was die Bandbreiten- und Dateigrößenanforderung für jede Sekunde Videoinformationen aufbläht. Schließlich regen gegenwärtige Trends eine Fülle von Videostandards und Protokollen weiter an; sie alle und ihre jeweiligen Entwicklungen in jeder Desktop-Workstation weiter zu unterstützen, erfordert kostspielige Computerleistung, Anwendungssoftware, dedizierte Hardware und Organisation; in vielen Unternehmen ist dies überhaupt nicht handhabbar.
Wie in den 3 und 4 gezeigt ist, kann das AVSS leicht mit dem Internet verbunden sein. Mit dieser Konnektivität kann das AVSS als ein Gateway für ankommende Internet-Videoströme (die es einlesen und somit in eine Datei umwandeln kann) sowie als ein Proxy-Server für ankommende Videodateiübertragungen aus dem Internet verwendet werden. Wenn diese resultierenden Videodateien in dem AVSS sind, wobei sie anfangs möglicherweise (wie früher beschrieben wurde) als "Roh"-Video erfasst werden, können sie daraufhin in Anwender-Workstations betrachtet oder in anderen AVSS-Anwendungen verwendet werden. Das AVSS kann irgendwelche Transcodierungsoperationen bereitstellen, die benötigt werden können. Dieser Ansatz lässt ohne merkliche zusätzliche Kosten ein mit der Erfindung ausgestattetes Unternehmen große Mengen von Videoinformationen aus dem Internet einlaufen, sie wirtschaftlich speichern und für irgendeinen Anwender mit einer Workstation, der mit der preiswerten Audio-Video-Vernetzungs-Hardware und -Software der Erfindung ausgestattet ist, zur Verfügung stellen.
Außerdem kann das AVSS als ein Datenlexikon für Videodateien verwendet werden, auf die über das Internet von außerhalb des Unternehmens zugegriffen wird. Die einfachste Implementierung dieses Wesens wäre, einfach "Roh"-Videodateien im Netz zur Verfügung zu stellen. Dies könnte erweitert werden, um Anmerkungsanimationen aufzunehmen, die z. B. durch Shareboard- oder eine ähnliche Datenmehrfachnutzungsanwendung erzeugt werden; solche Anmerkungsanimationen könnten tatsächlich selbstständig oder zeitlich synchronisiert mit Audio-, Video- oder Audio-Video-Material verfügbar sein. Software-Betrachter und -Spieler (z. B. mit reiner Softwarevideodecodierung) könnten als Anwendungssoftware zur Verwendung mit Internet-Browsern oder zur Integration in sie erzeugt werden. Diese Software-Betrachter und -Spieler können in verschiedenen Arten in einer für den Fachmann auf dem Gebiet leicht verständlichen Weise implementiert und eingesetzt werden, z. B.:

• ein Applet, das von dem Server über das Internet heruntergeladen wird
• eine volle Anwendung, die von dem Server über das Internet heruntergeladen wird, wobei die Anwendung derart ist, dass sie auf dem Personal Computer des Internet-Anwenders installiert werden kann
• ein selbstständiges Anwendungsprodukt, das auf dem Markt gekauft und verkauft wird.

Es wird angemerkt, dass der Umfang der gesamten obigen Funktionalität weiter erweitert werden könnte, um die Fähigkeit der Behandlung voller AVSS-MIME-Anhänge aufzunehmen.
Die Internet-Gateway-Anwendung implementiert wenigstens eine der folgenden Funktionen: den Empfang ankommender Audio-Video-Informationen von dem Internet und das digitale Verfügbarmachen interner Audio-Video-Informationen für Drittanbieter im Internet.
Die Implementierung einer ersten Ausführungsform dieses Teils der vorliegenden Erfindung erfordert die folgenden AVSS-Merkmale:

8. Effektives "Zurückschleifen" von ankommendem Video zu abgehendem Video bei der AVSC während der Aufzeichnung.
9. Die Fähigkeit zum Annehmen und Wiedergeben geeigneter digitaler Dateien von Drittanbietern, wie sie durch Anwendungen gesteuert wird.
12. Videoeditierfähigkeiten. Diese Fähigkeit kann als Teil eines Anwendungsprogramms intern implementiert sein oder kann alternativ fähig sein, Drittanbieter-Videoeditoren und/oder -Audioeditoren aufzurufen.

Wo ein entfernter Anwender außerhalb des Unternehmens ist, betrachten die Prinzipien der vorliegenden Erfindung die Nutzung von Drittanbieter-Browsern einschließlich, aber spezifisch nicht beschränkt auf, Netscape, Microsoft Internet Explorer und/oder FTP.
Ausführungsformen der Internet-Gateway-Anwendung würden üblicherweise die folgenden Fähigkeiten erfordern:

1. Allgemeine Steuerprotokollschnittstelle/API.
2. Ein allgemeines Mehrplattform-Audio-Video-Aufzeichnungs/Wiedergabe-Hilfsmittel (ähnlich vfstool), das hier als die "Betriebsartsteuerungs-GUI" oder "MCG" bezeichnet wird.
3. Mehrsitzungs-Aufzeichnungs/Wiedergabe-Fähigkeit.
4. Analoge A/V-E/A.
5. Wenn ein Codierer zugewiesen wird, wird gleichzeitig ein AVSC-Decodierer zugewiesen. Dies stellt sicher, dass der Decodierer während der Aufzeichnungssitzung immer für die Durchsicht verfügbar ist.
6. Variable Kapazitätsskalierung zur Anpassung an die Notwendigkeiten unterstützter Anwendungen.
7. Dateiübertragungsfähigkeit (Zieh-Modell) zwischen AVSS, die durch spezifische durch Anwendungen gestellte Dateiübertragungsanforderungen angesteuert wird.
8. Effektives "Zurückschleifen" AVSC von ankommendem Video zu abgehendem Video bei der AVSC während der Aufzeichnung.
9. Die Fähigkeit zum Annehmen und Wiedergeben geeigneter digitaler Dateien von Drittanbietern, wie sie durch Anwendungen gesteuert wird.
10. Die Fähigkeit zum Übertragen geeigneter digitaler Dateien an Drittanbieter, wie sie durch Anwendungen gesteuert wird.
12. Videoeditierfähigkeiten. Diese Fähigkeit kann intern als Teil eines An wendungsprogramms implementiert sein oder kann alternativ fähig sein, Drittanbieter-Videoeditoren und/oder -Audioeditoren aufzurufen.

4.16.8 Videoveröffentlichung
Die Videoveröffentlichung wird durch einen Anwender ausgeführt, der Video in dem AVSS zur Betrachtung innerhalb des Desktop-Zusammenarbeitssystems oder über das datengestützte Standard-Internet/Intranet versendet.
Desktops (analog oder digital) können entweder über das LAN, über das WAN oder über das Internet auf gespeicherte Videodokumente zugreifen. Sie können ebenfalls für CMW-Anwender sowie außenstehende Workstations, die verringerte Graphikfähigkeit haben, zur Verfügung gestellt werden. Die Videoveröffentlichung ermöglicht das Veröffentlichen der Dokumente an die Außenwelt sowie das Importieren von zusätzlichem Material, das wieder Text-, Graphik-, Audio-, Video- oder Multimedia-Dateien enthält, von der Außenwelt. Dieses letztere Merkmal umfasst den Import und Export einer Anzahl verschiedener Video- und weiterer Formate einschließlich, aber nicht spezifisch beschränkt auf, MPEG1-7, Motion-JPEG, Video for Windows, Quicktime, DVI, aufgezeichnetes H.320, Wavelets und Wavelet-komprimierte Fraktale.
Die Implementierung der Videoveröffentlichung in dem AVSS umfasst eine als Hardware, Software oder Firmware verkörperte Transcodierungsmethodik zum Ermöglichen der Transcodierung zwischen den mehreren erforderlichen Formaten, wodurch die Videodateien für den Empfänger davon im Wesentlichen format-transparent gemacht werden. Dementsprechend kann irgendein Anwender mit einer Workstation und mit Berechtigungen von dem Systemadministrator Dokumente zu irgendeinem Anwender im Netz oder zu irgendeiner anderen Person außerhalb des Netzes, die Zugriff auf die Dateien hat, veröffentlichen. Dies ermöglicht eine hochwertige Videoveröffentlichung von analoger Ausrüstung ohne die Kosten der Implementierung digitaler Ausrüstung.
An einem gewissen Punkt wird es von den Kosten her unerschwinglich, alle jemals durch ein Unternehmen erzeugten Videodateien im schnellen Online-Speicher wie etwa auf magnetischen oder magnetooptischen Festplatten zu hal ten. An einem gewissen Punkt muss für veraltete Videodateien oder für Videodateien, auf die selten zugegriffen wird, ein Langzeit- oder Massenspeicher implementiert werden. Die vorliegende Erfindung betrachtet die Aufnahme einer automatischen Routine darin, die die relative Zeitwichtigkeit von Dateien ermittelt und sie entweder zu und von einem oder mehreren Typen von Langzeitspeichervorrichtungen einschließlich Massenspeicher, Magnetband oder einer anderen dem Durchschnittsfachmann auf dem Gebiet gut bekannten Langzeitspeichertechnologie verschiebt oder die die Dateien aus dem System löscht. Dieser Algorithmus bietet dem Anwender entweder die Option, seine Videodateien zu archivieren, oder tut dies automatisch. Dies kann durch ein Anwender-Skript von dem Systemadministrator oder durch eine andere Archivierungsspeichertechnologie, die dem Durchschnittsfachmann auf dem Gebiet gut bekannt ist, erfolgen.
4.17 Multimedia-Anwendungen
Die vorliegende Erfindung ermöglicht den Aufbau von Echtzeit-Datenmehrfachnutzungssitzungen zwischen zwei Workstations unter Verwendung von Shareboard-Technologien oder anderen Technologien zur gemeinsamen Nutzung synchronisierter Daten. Die Implementierung eines Shareboards ermöglicht, dass eine gegebene Anwendung in jeder an der Videokonferenz, an der Video-Mail oder an einer anderen hier gelehrten Anwendung beteiligten Workstation aufrufbar ist. Irgendein Anwender mit Berechtigung für den Zugriff auf die Datei kann dann eine Kopie der Anwendung auf diesem Bildschirm als ein weiteres Fenster auf seinen Bildschirm importieren. Es wird das unabhängige Scrollen jedes Bildschirms ermöglicht. Auf diese Anwendung in dem Fenster können dann Anwender mittels Graphiküberlagerungsdateien unabhängig zeigen, zeichnen, Text eingeben und weitere Graphikfunktionen ausführen. Ferner kann der Anwender weitere Dateiprogramme usw. ergreifen und sie in das Konferenzfenster ziehen. Ferner können die Anwender auf die Elemente in einer oder in mehreren dieser Anwendungen unabhängig mittels Telepoint zeigen. In dem enthaltenen Literaturhinweis ist jedes dieser Shareboard-Merkmale weiter erläutert.
Die vorliegende Erfindung ermöglicht, dass die zuvor diskutierten Shareboard-Merkmale auf die Verwendung gespeicherter Anwendungen erweitert werden. Dies ermöglicht, dass ein Anwender gleichzeitig erzählt und mittels Telepoint zeigt, z. B. auf den interessierenden Gegenstand zeigt, und Sprache wie "dieses hier und jenes da drüben" verwendet. Dementsprechend ist klar, dass es wenigstens erforderlich ist, dass die Sprache des Anwenders mit den Aktionen des Zeigers synchronisiert wird. Die vorliegende Erfindung ermöglicht nicht nur dieses Merkmal in Echtzeit, sondern ermöglicht ferner, dass diese synchronisierte Sprach- und Graphikfähigkeit speicherbar und abrufbar ist, sodass die Daten-, Sprach- und Graphiksynchronisation genau bleibt, wenn die gespeicherte Datei aufgerufen wird. Dies ermöglicht, dass die Datei als Video-Mail, als eine Eingabe in Reaktion auf eine Anrufbeantwortersystembegrüßung, als ein Dokument oder im Wesentlichen in irgendeinem anderen durch die Lehren der vorliegenden Erfindung gelehrten oder offensichtlich gemachten weiteren Dateiformat aufgezeichnet, gespeichert und zu einem anderen Anwender gesendet wird. Es wird angemerkt, dass diese Speicherung zugrundeliegende Bitmaps irgendeiner auf diese Weise aufgerufenen Anwendung enthält.
In einer ersten Ausführungsform der vorliegenden Erfindung wird der in dem enthaltenen Literaturhinweis umfassend diskutierte Shareboard-Literaturhinweis verwendet. Dies schafft eine einheitliche Anwenderschnittstelle. Da das Shareboard ein inneres Merkmal der hier gelehrten Videokonferenzmethodiken ist, ermöglicht die Erweiterung seiner Merkmale auf die weiteren hier gelehrten Anwendungen die gleiche Funktionalität ohne die Implementierung zusätzlicher Aufzeichnungshilfsmittel oder Anwenderschnittstellen. Die Nutzung des Shareboards bedeutet in einem sehr realen Sinn nicht nur, dass ein Anwender nur eine Schnittstelle erlernen muss, die in Echtzeit oder auf andere Weise nutzbar ist, sondern hilft außerdem den Vorstellungen der Anwender, dass sie durch die Prinzipien der vorliegenden Erfindung in die Lage versetzt werden, Daten über mehrere Anwendungen, die hier die Anwendungsfamilie bilden, gemeinsam zu nutzen. Die Kombination der zuvor diskutierten Multimedia-Synchronisation in Kombination mit der Shareboard-Funktionalität löst eine Anzahl von Kompatibilitäts-, Datenwiederverwendungs- und Anwenderschnittstellenproblemen. Darüber hinaus ermöglicht das Anwender-Shareboard in funktionaler Kombination mit der zuvor diskutierten Multimedia-Synchronisation die Implementierung der Prinzipien der vorliegenden Erfindung unter Nutzung sehr spezifischer Datenspeicherformate sowie der gemeinsamen Nutzung von Bitmaps.
Ein etwas allgemeinerer Fall bei der Verwendung des Shareboards ist die gemeinsame Anwendungsnutzung. Wenn eine Anwendung aufgerufen wird und mehrere Konferenzanwender sie gleichzeitig nutzen können, wobei z. B. jeder Daten in ein einziges, gemeinsam genutztes Tabellenkalkulationsprogramm eingibt, arbeitet die vorliegende Erfindung nicht mehr mit nur einem Schnappschuss eines Bitmap-Bilds, sondern eher tatsächlich in dem Prozess der Anwendung, wobei die mehreren Anwender gleichzeitig zusammen Dateien ändern.
4.17.1 Multimedia-Mail
Die Multimedia-Mail-Anwendung fügt zu der im vorigen Abschnitt beschriebenen Video-Mail-Anwendung eine synchronisierte Datenmehrfachnutzung, z. B. synchronisierte Aufzeichnungs-, Speicherungs-, Browsing- und Wiedergabefähigkeiten eines Shareboards/T.120, hinzu.
Die Aufnahme dieses Merkmals schafft wesentlichen Wert dadurch, dass Mail-Nachrichten jetzt die gleichen Medienoptionen wie Echtzeit-Desktop-Videokonferenzen enthalten können. Somit kann ein Anwender mittels Telepoint auf eine Zahl in einer Tabellenkalkulation zeigen und daraufhin eine andere Zahl in der Tabellenkalkulation umkreisen, während er zunächst lächelt und daraufhin sagt: "Wie auf aller Welt kann diese Zahl die Hälfte jener Zahl sein?", wobei die gesamte medienübergreifende Nachricht einschließlich aller subtiler Kommunikation, die durch Gesten, Sprachton, Körpersprache usw. enthalten ist, so eingefangen und übermittelt wird, wie es in einer Life-Desktop-Videokonferenz der Fall gewesen wäre.
Der volle Inhalt weiterer Multimedia-Speicheranwendungen mit synchronisierten Daten teilen synchronisierte Aufzeichnungs- und Wiedergabefähigkeiten z.B. eines Shareboard-T.120. Somit kann ein Anwender eine Multimedia-Anrufbeantworter-Anwendungsnachricht, Multimedia-Konferenz-Aufzeichnung usw. mit anderen Autoren weiterleiten oder Treffpunkte in Multimedia-Mail oder in einer anderen hier gelehrten Multimedia-Anwendung verfassen. Diese Anwendung erfordert ein neues AVSS-Merkmal:

11. Synchronisierte Datenmehrfachnutzung, z. B. synchronisierte Aufzeichnung, Speicherung, Browsing und Wiedergabe eines Shareboard/T.120. Die se Ereignislisteninformationen werden am besten in einer von der MPEG-A/V-Datei getrennten Datei gespeichert; das Paar aus dieser Ereignisliste und der MPEG-A/V-Datei könnte eine "Multimedia-Metadatei" genannt werden.

4.7.12 Multimedia-Anrufbeantwortersystem.
Die Multimedia-Anrufbeantworteranwendung fügt zu der im vorigen Abschnitt beschriebenen Videoanrufbeantworteranwendung die synchronisierte Datenmehrfachnutzung, z. B. synchronisierte Aufzeichnungs-, Speicherungs-, Browsing- und Wiedergabefähigkeiten eines Shareboard/T.120, hinzu.
Die Nutzung dieses Merkmals schafft wesentlichen Wert dadurch, dass ein Anwender eine vollständigere Nachricht in verhältnismäßig wenig Zeit hinterlassen kann, wenn zu der Zeit, zu der ein Anrufversuch unternommen wird, ein Anrufempfänger selbst oder die notwendige Konnektivität nicht verfügbar sind. Dies liegt daran, dass die gesamte Graphiküberlagerung entweder in die Begrüßung des Empfängers oder in die Nachricht des Anrufers aufgenommen werden kann.
Diese Anwendung nutzt wie alle weiteren hier diskutierten Multimedia-Anwendungen wieder das zuvor diskutierte Merkmal 11.
4.17.3 Multimedia-Konferenzaufzeichnung
Die Multimedia-Konferenzaufzeichnungsanwendung fügt zu der im vorigen Abschnitt beschriebenen Videokonferenz-Aufzeichnungsanwendung eine synchronisierte Datenmehrfachnutzung, z. B. das synchronisierte Aufzeichnungs-, Speicherungs-, Browsing- und Wiedergabefähigkeitsmerkmal 11 eines Shareboard/T.120, hinzu. Dies stellt sicher, dass alle Transaktionen, die das volle Spektrum der in Desktop-Telekonferenzen von zwei oder mehr Teilnehmern verwendeten Medien überspannen, zur späteren Durchsicht erfasst werden können.
4.17.4 Multimedia-Dokumente
Die Multimedia-Dokumenteanwendung fügt zu den im vorigen Abschnitt beschriebenen Videodokumenten die synchronisierte Datenmehrfachnutzung, z. B. die synchronisierten Aufzeichnungs-, Speicherungs-, Browsing- und Wieder gabefähigkeiten eines Shareboard-T.120, des Merkmals 11 hinzu. Dies stellt sicher, dass prozedurale Beschreibungen, die Video wirksam einsetzen, ebenfalls synchronisiertes Telepoint-Zeigen und Anmerkung enthalten können. Dies ist außerordentlich wertvoll bei Online-Schulungs- und Referenzmaterialanwendungen.
4.17.5 Universal-Multimedia-Speicher
Die Universal-Multimedia-Speicheranwendung fügt zu der im vorigen Abschnitt beschriebenen Universalvideospeicheranwendung die synchronisierte Datenmehrfachnutzung, z. B. das synchronisierte Aufzeichnungs-, Speicherungs-, Browsing- und Wiedergabefähigkeitsmerkmal 11 eines Shareboard/T.120, hinzu. Die durch eine solche Implementierung gebotenen Vorteile widerspiegeln die oben in dem Abschnitt mit dem Titel "Multimedia-Dokumente" diskutierten.
4.17.6 Intranet-Multimedia-Speicherhilfsmittel
Die Intranet-Multimedia-Speicheranwendung fügt zu der in dem vorigen Abschnitt beschriebenen Intranet-Videospeicheranwendung die synchronisierte Datenmehrfachnutzung, z. B. die synchronisierten Aufzeichnungs-, Speicherungs-, Browsing- und Wiedergabefähigkeiten des Merkmals 1 eines Shareboard/T.120, hinzu. Die dadurch gebotenen Vorteile sind wieder ähnlich den oben in dem Abschnitt mit dem Titel "Multimedia-Dokumente" diskutierten.
Die Prinzipien der vorliegenden Erfindung sind hier anhand bestimmter Ausführungsformen davon diskutiert worden. Die Untersuchung der hier offenbarten Prinzipien macht für den Durchschnittsfachmann auf dem Gebiet bestimmte Änderungen daran offensichtlich. Die Prinzipien der vorliegenden Erfindung betrachten spezifisch alle solche Änderungen. Die vorliegende Erfindung kann ohne irgendein hier offenbartes Element verwirklicht werden.

Claims

Vernetztes Multimedia-System, das Folgendes umfasst: mehrere Workstations, die jeweils Video- und Audio-Wiedergabe- sowie Video- und Audioerfassungsfähigkeiten haben; wenigstens einen Speicherserver, wobei der Speicherserver wenigstens eine Speicherzelle mit wenigstens einer Speicherplatte, einer Speicherplattensteuerung in Verbindung mit jeder Platte und wenigstens einen Konverter hat; und einen Speicherzellenmanager AVSM, der zum Speichern von durch den/die Konverter konvertierte Audio/Video-Signale zum späteren Abrufen konfiguriert ist; und wenigstens einen Signalweg, der die Workstations und den Speicherserver verbindet; wobei das vernetzte Multimedia-System so konfiguriert ist, dass es die konvertierten Audio/Video-Signale speichert, durch: a) Auswählen eines Mitglieds der Gruppe bestehend aus Platten, Plattensteuerungen, Konvertern, Speicherzellen und Speicherzellenmanagern AVSM gemäß dem folgenden Ansatz; i) wenn ein erster Konverter einer ersten Zelle seine Kapazitäts- oder Bandbreitengrenze erreicht hat, dann wird ein zweiter Konverter der ersten Zelle gewählt; ii) wenn eine erste Plattensteuerung der ersten Zelle ihre Kapazitäts- oder Bandbreitengrenze erreicht hat, dann wird eine zweite Plattensteuerung der ersten Zelle gewählt; iii) wenn eine erste Platte in Verbindung mit einer ersten der Plattensteuerungen ihre Kapazitäts- oder Bandbreitengrenze erreicht hat, dann wird eine zweite Platte in Verbindung mit der ersten Plattensteuerung gewählt; iv) wenn die erste Speicherzelle in Verbindung mit dem ersten Speicherzellenmanager AVSM ihre Kapazitäts- oder Bandbreitengrenze erreicht hat, dann wird eine zweite Speicherzelle in Verbindung mit dem ersten Speicherzellenmanager AVSM gewählt; und v) wenn der erste Speicherzellenmanager AVSM seine Kapazitätsgrenze erreicht hat, dann wird ein zweiter Speicherserver gewählt; und b) Speichern der konvertierten Signale mit jedem aus den ausgewählten Mitgliedern der Gruppe.
Vernetztes Multimedia-System nach Anspruch 1, wobei das System so konfiguriert ist, dass es die Übertragung von zuvor durch eine erste Speicherzelle gespeicherten konvertierten Audio/Video-Signalen auf eine andere Speicherzelle erleichtert.
Vernetztes Multimedia-System nach Anspruch 1 oder 2, wobei der Konverter ein Transcoder, ein Codierer und/oder eine Codierer/Transcoder-Kombination ist.
Vernetztes Multimedia-System nach einem der Ansprüche 1 bis 3, wobei abgerufene Signale zu einer Audio/Video-Wiedergabe in einer oder mehreren der Workstations führen können.
Vernetztes Multimedia-System nach einem der Ansprüche 1 bis 4, wobei die konvertierten Signale in wenigstens einer Datei gespeichert werden, auf die mehr als eine Workstation gleichzeitig und/oder mehr als ein Anwendungstyp zugreifen kann/können.
Vernetztes Multimedia-System nach Anspruch 5, wobei mehrere Kopien einer solchen Datei existieren können.
Vernetztes Multimedia-System nach Anspruch 6, das ferner einen Speicherserver umfasst, der wenigstens durch Folgendes definiert wird: i) wenigstens eine der Speicherzellen, ii) wenigstens einen der Konverter, und iii) wenigstens eine Steuerung, die so konfiguriert ist, dass sie wenigstens eine Aktivität aus der folgenden Gruppe ausführt: a) Ermitteln, ob eine Signalkonvertierung stattfinden soll; b) Ermitteln, wenn das System mehr als einen Konverter umfasst, welcher der mehreren Konverter die Konvertierung ausführen wird; c) Ermitteln, wenn das System mehr als eine Speicherzelle umfasst, welche der Speicherzellen die konvertierten Signale speichert; d) Steuern des nachfolgenden Abrufens der gespeicherten Signale; und e) Ermitteln, auf welche Kopie der Datei zum Abrufen zugegriffen wird.
Vernetztes Multimedia-System nach Anspruch 7, wobei der Speicherserver physikalisch über das System verteilt oder dezentralisiert ist.
Verfahren zum Anwenden eines vernetzten Multimedia-Systems, das die folgenden Schritte beinhaltet: Erfassen von Audio und Video an einer oder mehreren Workstations, die jeweils Video- und Audio-Wiedergabe- sowie Video- und Audioerfassungsfähigkeiten haben; Konvertieren des erfassten Audio und Video in eine zum Speichern geeignete Form; Speichern der konvertierten Audio/Video-Signale zum späteren Abrufen unter Verwendung von wenigstens einer Speicherzelle mit wenigstens einer Speicherplatte, einer Speicherplattensteuerung in Verbindung mit jeder Platte; wenigstens einem Konverter; und einem Speicherzellenmanager AVSM, und Speichern der konvertierten Audio/Video-Signale; a) durch Auswählen eines Mitglieds der Gruppe bestehend aus Platten, Plattensteuerungen, Konvertern, Speicherzellen und Speicherzellenmanagern AVSM gemäß dem folgenden Ansatz: i) wenn ein erster Konverter einer ersten Zelle seine Kapazitäts- oder Bandbreitengrenze erreicht hat, dann wird ein zweiter Konverter der ersten Zelle gewählt; ii) wenn eine erste Plattensteuerung der ersten Zelle ihre Kapazitäts- oder Bandbreitengrenze erreicht hat, dann wird eine zweite Plattensteuerung der ersten Zelle gewählt; iii) wenn eine erste Platte in Verbindung mit einer ersten der Plattensteuerungen ihre Kapazitäts- oder Bandbreitengrenze erreicht hat, dann wird eine zweite Platte in Verbindung mit der ersten Plattensteuerung gewählt; iv) wenn die erste Speicherzelle in Verbindung mit dem ersten Speicherzellenmanager AVSM ihre Kapazitäts- oder Bandbreitengrenze erreicht hat, dann wird eine zweite Speicherzelle in Verbindung mit dem ersten Speicherzellenmanager AVSM gewählt; und v) wenn der erste Speicherzellenmanager AVSM seine Kapazitätsgrenze erreicht hat, dann wird ein zweiter Speicherserver gewählt; und b) Speichern der konvertierten Signale mit jedem aus den ausgewählten Mitgliedern der Gruppe.
Verfahren nach Anspruch 9, das ferner den Schritt des Wiedergebens von Audio und/oder Video an einer oder mehreren der Workstations auf der Basis der abgerufenen Signale beinhaltet.
Verfahren nach Anspruch 9 oder 10, wobei konvertierte Signale in wenigstens einer Datei gespeichert werden, auf die durch mehr als eine Workstation gleichzeitig und/oder mehr als einen Anwendungstyp zugegriffen wird.
Verfahren nach Anspruch 11, wobei mehrere Kopien jeder solchen Datei existieren können.
Verfahren nach Anspruch 9, das ferner die folgenden Schritte beinhaltet: Erzeugen einer Folge von Graphik-Rendering-Events in Verbindung mit computererzeugten Bildern und/oder Graphiküberlagerungen an einer Workstation; und Speichern der erzeugten Sequenz.