DE112010005457T5

DE112010005457T5 - Übergang zwischen leitungsvermittelnden Gesprächen und Videogesprächen

Info

Publication number: DE112010005457T5
Application number: DE112010005457T
Authority: DE
Inventors: David McLeod; Justin Santamaria; Jeremy Brown
Original assignee: Apple Inc
Current assignee: Apple Inc
Priority date: 2010-04-07
Filing date: 2010-09-23
Publication date: 2013-01-17
Anticipated expiration: 2030-09-24
Also published as: JP2013525879A; CN102859962B; MX2012011622A; KR20130020786A; GB2495814A; US20110249079A1; US8704863B2; US20150180822A1; EP2556640B1; US9577976B2; KR101435309B1; JP5833098B2; JP5596849B2; BR112012025382A2; CN102893572B; US8725880B2; EP2540052A1; BR112012025358A2; GB2495814B; BR112012025379A2

Abstract

Übergang zwischen einem reinen audioleitungsvermittelnden Gespräch und einem Videogespräch. Ein Clientgerät, welches aktuell mit einem oder mehreren Clientgeräten durch ein aufgebautes rein audioleitungsvermitteltes Gespräch verbunden ist, empfängt Eingaben von einem Nutzer, um von dem reinen audiovermittelten Gespräch zu einem Videogespräch überzugehen. Eine Videogesprächseinladungsnachricht wird an die anderen Clientgeräte übermittelt. Das Clientgerät empfängt eine Videogesprächsannahmenachricht von den anderen Clientgeräten und beginnt Video, aufgenommen durch seine Frontkamera, an die anderen Clientgeräte zu übermitteln. Als Antwort auf das Empfangen von mindestens einem Videoframe von jedem ein oder mehreren anderen Clientgeräte, geht das Clientgerät von dem reinen audioleitungsvermittelten Gespräch zu einem Videogespräch über. Nach dem Übergang zu dem Videogespräch wird das leitungsvermittelte Gespräch fallengelassen.

Description

VERWEIS AUF VERWANDTE ANMELDUNGEN
Diese Anmeldung beansprucht die Priorität der US Patentanmeldung Nummer 12/886,490, eingereicht am 20. September 2010, und beansprucht ebenso die Vorteile der vorläufigen US Anmeldung Nummer 61/382,479, eingereicht am 13. September 2010, vorläufige US Anmeldung Nummern 61/378,924 und 61/378,926, die jeweils am 31. August 2010 eingereicht wurden, vorläufige US Anmeldung Nummer 61/351,814, eingereicht am 04. Juni 2010 und vorläufige US Anmeldung Nummern 61/321,865 und 61/321,866, jeweils einegereicht am 07. April 2010, die hiermit durch Bezugnahme integriert werden.
Diese Anmeldung kann einen ähnlichen oder gleichen Gegenstand wie die parallel anhängige, parallel zugewiesene vorläufige US Anmeldung Nummer 61/321,832, eingereicht am 07. April 2010 aufweisen, und wird genannt: Vorrichtung und Verfahren zum Einladen von Benutzern zu Onlinesitzungen, welche hier durch Bezug integriert wird.
Die Erfindung, die in dieser Anmeldung offenbart und beansprucht werden soll, wurde frühzeitig und ohne Apples Erlaubnis der Öffentlichkeit gegenüber offenbart, als ein Prototyp des Apple iPhone 4 offensichtlich von einem Apple-Ingenieur am 25. März 2010 gestohlen wurde. Die US Prioritätsanmeldung, auf der diese Anmeldung beruht, wurde nicht vor dem offensichtlichen Diebstahl erreicht.
HINTERGRUND
Bereich
Ausführungsformen der Erfindung betreffen den Bereich von Computer-Vernetzung; und insbesondere den Übergang zwischen leitungsvermittelnden Gesprächen und Videogesprächen.
Hintergrund
Viele Implementierungen zur Bereitstellung von Online-Kommunikationssitzungen (zum Beispiel Instant Messaging, Videokonferenzen, etc.) erfordern, dass die Benutzer der Computergeräte Software installieren und/oder sich bei den Diensten registrieren. Somit muss als Voraussetzung dafür, dass ein Benutzer eine Online-Kommunikationssitzung mit einem anderen Benutzer aufbauen kann, beide Benutzer registriert sein und/oder die gleiche Software installiert haben. Viele Implementierungen unterhalten Präsenz (zum Beispiel eine Freundschaftsliste), die es Nutzern ermöglicht, den Status anderer Nutzer zu bestimmen (zum Beispiel Online, Offline, Abwesend, etc.).
Große öffentliche Netzwerke, wie beispielsweise das Internet, haben regelmäßig Verbindungen zu kleineren privaten Netzwerken, wie beispielsweise jene, die von Unternehmen gehalten werden, Internetserviceprovider, oder sogar einzelne Haushalte. Aufgrund ihrer Beschaffenheit müssen öffentliche Netzwerke eine gemeinsam vereinbarte Zuordnung von Netzwerkadressen haben, das heißt öffentliche Adressen. Aus verschiedenen Gründen entscheiden sich Maintainer von privaten Netzwerken oftmals dazu, private Netzwerkadressen für private Netzwerke zu benutzen, die nicht als Teil der gemeinsam vereinbarten Zuordnung gelten. Daher wird dafür, dass Netzwerkverkehr von dem privaten Netzwerk das öffentliche Netzwerk durchqueren kann, irgendeine Form von privater/öffentlicher Netzwerkadressübersetzung („NAT”) benötigt.
Ein Gerät, das NAT ausführt, ändert die Datenpakete, die aus dem privaten Netzwerk gesendet werden, so dass sie dem Adressierschema des öffentlichen Netzwerks entsprechen. Insbesondere ersetzt der Netzwerkadressübersetzer die ursprüngliche private Adresse, Portnummer eines Pakets durch seine eigene öffentliche Adresse und eine zugewiesene Portnummer. Ein Netzwerkadressübersetzer ändert auch die Datenpakete, die für Computer auf dem privaten Netzwerk empfangen werden, um die öffentliche Zieladresse und Portnummer durch die korrekte private Adressen und Portnummern des vorgesehenen Empfängers übersetzen. Wie hier benutzt, sollte der Begriff Adresse, falls im Zusammenhang angemessen, so ausgelegt werden, dass es sowohl eine Adresse als auch eine Portnummer umfasst, wie es von einem Fachmann verstanden werden würde.
NAT kommt zunehmend häufiger in modernen Netzwerkcomputern zum Einsatz. Ein Vorteil von NAT ist, dass es die Erschöpfung von öffentlichen Netzwerkadressraum verlangsamt. Zum Beispiel umfasst die TCP/IP Adressierung, die im Internet benutzt wird, vier Ketten von jeweils drei Zahlen, und stellt somit einen endlichen Adressraum zur Verfügung. Außerdem sind bestimmte Teile dieses Adressraums für bestimmte Verwendungen oder Nutzer reserviert, wodurch die tatsächliche Anzahl von verfügbaren Adressen abgebaut wird. Falls jedoch NAT benutzt wird, kann ein privates Netzwerk oder ein Subnetz eine willkürliche Anzahl von Adressen benutzen und dennoch der Außenwelt eine einzelne standardisierte öffentliche Adresse zeigen. Dies ermöglicht praktisch eine unbegrenzte Anzahl von verfügbaren Adressen, weil jedes private Netzwerk theoretisch exakt die gleiche private Adresse nutzen könnte.
Ein Vorteil, der durch NAT geboten wird, ist die erhöhte Sicherheit, die sich daraus ergibt, dass diejenigen auf dem öffentlichen Netzwerk die tatsächliche (das heißt private) Netzwerkadresse eines Computers auf einem privaten Netzwerk nicht bestimmen könnten. Das liegt daran, dass nur die öffentliche Adresse auf dem öffentlichen Netzwerk von dem Netzwerkadressübersetzer zur Verfügung gestellt wird. Zusätzlich kann diese öffentliche Adresse jeder Anzahl in computerprivaten Netzwerken entsprechen.
Verschiedene NAT-Typen verwenden verschiedene Sicherheitslevel. Zum Beispiel kann mit einem „Vollkegel NAT”, sobald eine interne Adresse (iAddr:iPort) auf eine externe Adresse (eAddr:ePort) abgebildet wird, jeder externe Host Pakete an iAddr:iPort senden, indem er Pakete an eAddr:ePort sendet. Mit einem „beschränkten Kegel NAT” kann ein externer Host eine Adresse hAddr-Pakete an iAddr:iPort senden, indem er nur dann Pakete an eAddr:ePort sendet, falls iAddr:iPort vorher ein Paket an hAddr gesendet hat. Das Port extern Host ist irrelevant. Mit einem „portbeschränkten Kegel NAT” kann ein externer Host, der eine Adresse/Port hAddr:hPort hat Pakete an iAddr:iPort senden, indem er nur dann Pakete an eAddr:ePort sendet, falls iAddr:iPort vorher ein Paket an hAddr:hPort gesendet hat. Schließlich wird mit einem Symmetric NAT jede Anfrage von dem gleichen iAddr:iPort an eine spezifische Ziel-IP-Adresse und Port auf eine einzige eAddr:ePort abbildet. Im Fall der gleiche interne Host ein Paket an verschiedene Ziele schickt, wird eine andere externe Adresse und Portabbildung genutzt. Nur ein externer Host, der ein Paket von einem internen Host empfängt, kann ein Paket an den internen Host zurücksenden.
Peer-to-peer („P2P”) bezieht sich auf verteilte Netzwerk-Architektur, die von Rechnerknoten gebildet wird, die einen Teil ihrer Ressourcen direkt anderen Netzwerkteilnehmern zur Verfügung stellt. Peers in einem P2P-Netzwerk bauen miteinander direkte Kommunikationskanäle auf und agieren zugleich als Client und Server, im Gegensatz zu traditionellen Client-Servermodellen, in denen Server Ressourcen bereitstellen und Clients Ressourcen konsumieren.
Die oben beschriebenen NAT-Abläufe weisen zahlreiche Probleme für P2P-Verbindungen auf. Zum Beispiel wird das Aufbauen einer direkten Verbindung zwischen zwei Peers zunehmend schwieriger, falls einer oder beide Peers hinter einem oder mehreren der NAT-Typen, die oben beschrieben sind, angeordnet sind. Dieses Problem verschlimmert sich dadurch, dass Clientgeräte, wie beispielsweise das Apple iPod Touch^®, Apple iPhone^®, Apple iPad^® und verschiedene andere Geräte (zum Beispiel RIM Blackberry^® Geräte, Palm Pre^® Geräte, etc), regelmäßig zwischen Netzwerk mit verschiedenen NAT-Implementierungen bewegt werden. Zum Beispiel kann das Apple iPhone^TM über Wi-Fi-Netzwerke kommunizieren (zum Beispiel 802.11b, g, n Netzwerke); 3G-Netzwerke (zum Beispiel Universal Mobile Telecommunications System („UMTS”) Netzwerke, High-Speed Uplink Packet Access („HSUPA”) Netzwerke, etc.); und Bluetooth-Netzwerke (bekannt als personal area networks („PANs”)). Zukünftige Clientgeräte werden über zusätzliche Kommunikationskanäle kommunizieren können, beispielsweise WiMAX, International Mobile Telecommunication („IMT”) Advanced und Long Term Evolution („LTE”) Advanced, um nur einige zu nennen.
Freisprecheinheiten (zum Beispiel Headsets, Autokits) werden typischerweise benutzt, um mit einem Computergerät für Freisprechdienste auszutauschen. Zum Beispiel ist es für ein Computergerät, das Mobiltelefonfunktionalitäten aufweist, üblich, die Fähigkeit aufzuweisen, mit einer Freisprecheinheit, die als ein auditives Relay zwischen Freisprecheinheit und dem Computergerät agiert, auszutauschen.
ZUSAMMENFASSUNG
Ein Verfahren und eine Vorrichtung für den Übergang zwischen einem reinen audioleitungsvermittelten Gespräch und einem Videogespräch wird beschrieben. Ein Clientgerät, das gerade mit einem oder mehreren Clientgeräten über ein aufgebautes reines audioleitungsvermittelten Gespräch verbunden wird, empfängt Eingaben von einem Nutzer für einen Übergang von einem reinen audioleitungsvermittelten Gespräch zu einem Videogespräch. Die Videogesprächseinladungsnachricht wird den anderen Clientgeräten übermittelt. Nutzer bei den Clientgeräten, die die Videogesprächseinladungsnachricht empfangen, können auswählen, ob sie die Nachricht quittieren oder ablehnen möchten. Falls die Videogesprächseinladung genommen wird, wird eine Videogesprächsannahmenachricht an das ursprüngliche Clientgerät übermittelt. Nachdem die Videogesprächseinladung angenommen wurde, bauen die Clientgeräte, die an den leitungsvermittelten Gespräch teilnehmen, eine Peer-to-peer („P2P”) Verbindung auf. Nachdem die P2P-Verbindung aufgebaut wurde, beginnen die Clientgeräte, Video über die P2P-Verbindung zu übermitteln und zu empfangen. Nachdem jeder der Endgeräte mindestens ein Frame empfangen hat, gehen die Clientgeräte von dem reinen audioleitungsvermittelten Gespräch zu dem Videogespräch über, einschließlich dem Anzeigen des Video, das empfangen wird, und wechseln die Audioroute von dem audioleitungsvermittelten Gespräch zu dem Videogespräch. Nach dem Übergang zu dem Videogespräch wird das reine audioleitungsvermittelten Gespräch fallen gelassen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die Erfindung kann am besten verstanden werden unter Bezugnahme auf die folgende Beschreibung und den dazugehörigen Zeichnungen, die verwendet werden, um die Ausführungsbeispiele der Erfindung darzustellen. In den Zeichnungen:
1 ist ein Datenflussdiagramm, das die Registrierung eines Clientgeräts für eine Online-Kommunikationssitzung gemäß einer Ausführungsform darstellt;
2 ist ein Blockdiagramm, dass das Clientgerät von 1 genauer gemäß einer Ausführungsform darstellt;
3 ist ein Blockdiagramm, das den Registrierungsserver von 4 genauer gemäß einer Ausführungsform darstellt;
4 ist ein Flussdiagramm, das beispielhaft abläuft zur Registrierung eines Clientgeräts für Online-Kommunikationssitzungen gemäß einer Ausführungsform darstellt;
5 stellt einen beispielhaften Registrierungsdatenspeicher gemäß einer Ausführungsform dar;
6 stellt eine allgemeine Netzwerktopologie einer Ausführungsform dar;
7 ist ein Datenflussdiagramm, das den Online-Kommunikationsaufbau zwischen Clientgeräten gemäß einer Ausführungsform dar;
8 ist ein Blockdiagramm, das einen beispielhaften Relaydienst gemäß einer Ausführungsform darstellt;
9 stellt eine Ausführungsform einer API-Architektur gemäß einer Ausführungsform dar;
10 stellt einen beispielhaften Registrierungsdatenspeicher gemäß einer Ausführungsform dar;
11 stellt eine beispielhafte NAT-Kompatibilitätstabelle gemäß einer Ausführungsform dar;
12 stellt ein beispielhaftes Clientgerät und eine graphische Benutzerschnittstelle dar, die für den Übergang zwischen leitungsvermittelndem Gesprächen und Videogesprächen gemäß einiger Ausführungsbeispiele darstellt;
13 stellt das Clientgerät von 12 dar, das eine Videovorschau mit einer Ausführungsform anzeigt;
14 stellt ein beispielhaftes Clientgerät und eine graphische Benutzerschnittstelle dar, die benutzt wird, um Videogesprächseinladungen gemäß einer Ausführungsform anzunehmen oder zu verweigern;
15 und 16 stellen Clientgeräte nach dem Übergang zu einem Videogespräch gemäß einer Ausführungsform dar;
17 und 18 sind Flussdiagramme, die beispielhafte Abläufe für den Übergang zwischen einem reinen audioleitungsvermittelten Telefongespräch zu einem Videogespräch gemäß einer Ausführungsform darstellen;
19 ist ein Flussdiagramm, das beispielhafte Abläufe, die auf einem Clientgerät durchgeführt werden, das ein Videogesprächsablehnungsnachricht gemäß einer Ausführungsform empfangen hat;
20 ist ein Flussdiagramm, das beispielhafte Abläufe, die auf einem Clientgerät für den Übergang von einem Videogespräch zu einem leitungsvermittelten Gespräch gemäß einer Ausführungsform durchgeführt werden;
21 stellt eine allgemeine Netzwerktopologie dar, die benutzt wird, um ein Clientgerät für Online-Kommunikationssitzungen zu registrieren unter der Verwendung einer E-Mailadresse als einen Online-Kommunikationssitzungsendpunktidentifizierer gemäß einer Ausführungsform;
22a–b sind Flussdiagramme, die beispielhafte Abläufe zur Registrierung einer E-Mailadresse als einen Online-Kommunikationssitzungsendpunktidentifizierer gemäß einer Ausführungsform darstellen;
23 ist ein Flussdiagramm, das beispielhafte Abläufe für einen Benutzer, der Initialisierungsinformationen zur Registrierung einer E-Mailadresse als ein Online-Kommunikationssitzungsendpunktidentifizierer gemäß einer Ausführungsform bereitstellt, darstellt;
24 stellt beispielhafte Abläufe zur Validierung einer E-Mailadresse gemäß einer Ausführungsform dar;
25 ist ein Flussdiagramm, das beispielhafte Abläufe, die auf einem Registrierungsdienst durchgeführt werden, wenn eine E-Mailadresse validiert worden ist gemäß einer Ausführungsform, darstellt;
26 ist ein Datenflussdiagramm, das beispielhafte Abläufe zum Verwalten von Einladungen darstellt, wenn ein Benutzer mehrere Clientgeräte hat, die mit der gleichen Online-Kommunikationssitzungendpunktidentifizierer assoziiert sind, gemäß einer Ausführungsform;
27 ist ein Datenflussdiagramm, das beispielhafte Abläufe, die durchgeführt werden, wenn eine direkte P2P-Vebrindung möglich ist, gemäß einer Ausführungsform darstellt;
28 ist ein Datenflussdiagramm, das beispielhafte Abläufe darstellt, die durchgeführt werden, wenn eine direkte P2P-Verbindung gemäß einer Ausführungsform möglich ist;
29 ist ein Datenflussdiagramm, das beispielhafte Abläufe darstellt, die durchgeführt werden wenn eine Online-Kommunikationssitzung endet gemäß einer Ausführunsgform;
30 ist ein Flussdiagramm, das beispielhafte Abläufe darstellt, die durchgeführt werden, um eine Online-Kommunikationssitzung von einem Clientgerät zu einem anderen Clientgerät gemäß einer Ausführungsform zu transferieren;
31 ist ein Flussdiagramm, das beispielhafte Abläufe darstellt zur Initiierung und zum Aufbau einer Online-Kommunikationssitzung mit mehreren Nutzern gemäß einer Ausführungsform;
32 ist ein Blockdiagramm, das ein Clientcomputergerät darstellt, das eine Schnittstelle mit einer Freisprecheinheit gemäß einer Ausführungsform bildet;
33 stellt ein Clientcomputergerät dar, das eine Einladung für ein Videogespräch empfängt, verursachend, dass ein Freisprechgerät klingelt, empfangene Antwortanzeige von dem Freisprechgerät, aufbauendes Videogesprächs, und Routen des Audios an das Freisprechgerät gemäß einer Ausführungsform;
34 stellt ein Clientcomputergerät dar, das ein Videogespräch initiiert und das Audio für aufgebaute Videogespräche über ein Freisprechgerät routet gemäß einer Ausführungsform;
35 stellt ein Clientcomputergerät dar, das ein Videogespräch in Antwort auf eine Gesprächsanfrage von einem Freisprechgerät initiiert gemäß einer Ausführungsform;
36 stellt ein Clientcomputergerät dar, das Audio von einem aufgebauten Videogespräch an ein Freisprechgerät routet gemäß einer Ausführungsform;
37 stellt ein Clientcomputergerät dar, das ein Videogespräch in Antwort auf eine Gesprächsbeendigungsanfrage von einem Freisprechgerät beendet gemäß einer Ausführungsform;
38 ist ein Blockdiagramm, das ein beispielhaftes Computersystem darstellt, das in manchen Ausführungsformen benutzt werden kann; und
39 ist ein Blockdiagramm, das ein beispielhaftes Datenverarbeitungssystem darstellt, das in manchen Ausführungsformen verwendet werden kann.
DETAILLIERTE BESCHREIBUNG
In der folgenden Beschreibung werden zahlreiche spezifische Details aufgeführt. Jedenfalls versteht sich, dass Ausführungsformen der Erfindung ohne diese spezifischen Details ausgeführt werden können. In anderen Fällen wurden bekannte Schaltkreise, Strukturen und Techniken nicht detailliert dargestellt, um das Verständnis dieser Beschreibung nicht zu erschweren. Der Fachmann wird mit den umfassten Beschreibungen in der Lage sein, eine entsprechende Funktionalität mit vertretbaren experimentieren zu implementieren.
Verweisungen in der Patentschrift auf „eine Ausführungsform”, „eine Ausführungsform”, „ein Beispiel für eine Ausführungsform” etc., deuten an, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, Struktur, oder Charakteristik aufweisen kann, aber jedes Ausführungsbeispiel muss nicht notwendigerweise das bestimmte Merkmal, Struktur oder Charakteristik aufweisen. Vielmehr müssen solche Formulierungen nicht unbedingt auf die gleiche Ausführungsform verweisen. Ferner wird wenn ein bestimmtes Merkmal, Struktur oder Charakteristik im Zusammenhang mit einer Ausführungsform beschrieben wird, geltend gemacht, dass es zum Wissen eines Fachmanns gehört, solch ein Merkmal, Struktur oder Charakteristik im Zusammenhang mit anderen Ausführungsformen zu erbringen, unabhängig davon, ob es ausdrücklich beschrieben ist.
In der folgenden Beschreibung und Ansprüchen können die Begriffe „verknüpft” und „verbunden” zusammen zu deren Derivaten genutzt werden. Es versteht sich, dass diese Begriffe nicht als Synonyme für einander benutzt werden sollen. „Verknüpft” wird verwendet, um anzudeuten, dass zwei oder mehrere Elemente, die in direktem physischen oder elektrischen Kontakt zueinander stehen können oder auch nicht, miteinander zusammenwirken oder interagieren. „Verbunden” wird verwendet, um den Aufbau einer Kommunikation zwischen zwei oder mehreren Elementen, die miteinander verknüpft sind, anzudeuten.
Automaische Registrierung für Online-Kommunikationssitzungen
Ein Verfahren und eine Vorrichtung für eine automatische Registrierung eines Clientcomputergeräts („Clientgerät”) (zum Beispiel Workstation, ein Laptop, ein Palmtop, ein Mobiltelefon, ein Smartphone, ein Multimediatelefon, ein Tablet, ein tragbarer Mediaplayer, eine GPS-Einheit, ein Spielesystem, etc.) für Online-Kommunikationssitzungen (zum Beispiel P2P Videokonferenz, P2P Instant Messaging, etc.) werden beschrieben. In einer Ausführungsform beginnt bei einem Ereignis am Computergerät (beispielsweise das Computergerät wird angeschaltet) das Computergerät automatisch einen Registrierungsprozess für Online-Kommunikationssitzungen. Der automatische Registrierungsprozess umfasst, dass das Clientgerät eine SMS (short message service) Nachricht mit einem Erkennungstoken (zum Beispiel sein Pushtoken) und eine Clientgerätkennung an ein SMS-Transitgerät (zum Beispiel SMS Gateway oder ein SMS Aggregator) übermittelt. Der Erkennungstoken identifiziert eindeutig ein Clientgerät für Online-Kommunikationssitzungsnachrichten (zum Beispiel Einladungsanfragen und Einladungsannahmenachrichten), und in einer Ausführungsform, ist ein Pushtoken, das Information enthalten kann, die es einem PushBenachrichtigungsdienst ermöglicht, das Clientgerät zu lokalisieren. Der Erkennungstoken in dem Pushbenachrichtigungsdienstausführungsbeispiel wird auch als eine Möglichkeit verwendet, um Vertrauen aufzubauen, dass eine bestimmte Benachrichtigung legitim ist. In anderen Ausführungsbeispielen kann jede Registrierung oder Abbildung von Clientgeräten auf eindeutige Token verwendet werden, um die Kennungstoken mit Clientgeräten zu assoziieren und ein vertrautes Verfahren zur Assoziierung der Identität des Clientgeräts mit einem eindeutigen Erkennungstoken zur Verfügung zu stellen. Die Gerätekennung identifiziert eindeutig das Clientgerät und basiert typischerweise auf einer oder mehreren Hardwarekennungen (zum Beispiel einen Seriennummer des Geräts, ein ICC-ID (Integrated Circuit Card ID) einer SIM (Subscriber Identity Module) Karte, etc.).
Das SMS-Transitgerät bestimmt die Telefonnummer des Clientgeräts (zum Beispiel durch Überprüfen des Headers der SMS-Nachricht) und übermittelt eine IP (Internet Protocol) Nachricht an einen Registrierungsserver mit dem Erkennungstoken, der Gerätekennung und der Telefonnummer. Der Registrierungsserver erzeugt eine Signatur auf der Basis des Erkennungstokens, der Gerätekennung und der Telefonnummer, und übermittelt diese an das SMS-Transitgerät zur Lieferung an das Clientgerät. Das SMS-Transitgerät übermittelt eine SMS-Nachricht an das Clientgerät, beinhaltend die Signatur und die Telefonnummer. Das Clientgerät übermittelt dann eine IP-Nachricht an den Registrierungsserver mit der Signatur, der Gerätekennung, dem Erkennungstoken und der Telefonnummer.
Der Registrierungsserver validiert die Informationen von dem Clientgerät und speichert eine Verknüpfung zwischen dem Erkennungstoken und der Telefonnummer in einem Online-Kommunikationssitzungsregistrierungsdatenspeicher. Zusammen identifizieren das assoziierte Paar von Erkennungstoken und der Telefonnummer eindeutig das Gerät in einem Online-Kommunikationssitzungsnetzwerk. Nachdem das Clientgerät registriert worden ist, kann der Benutzer Clientgerät eine Einladung für eine Online-Kommunikationssitzung (zum Beispiel Videochat/Konferenzsitzung, Instant Messaging-Sitzungen, etc.) initiieren und/oder annehmen. In einer Ausführungsform wird die Telefonnummer eines Clientgeräts verwendet als die Online-Kommunikationssitzungsendpunktkennung einer Online-Kommunikationssitzung. Als Beispiel kann ein Nutzer eines Clientgeräts andere Nutzer oder andere Clientgeräte einladen, um unter Verwendung ihrer Telefonnummern an einer Online-Kommunikationssitzung teilzunehmen. In manchen Ausführungsformen kennt das Clientgerät seine eigene Telefonnummer natürlicherweise nicht.
1 ist ein Datenflussdiagramm, das der Registrierung eines Clientgeräts für eine Online-Kommunikationssitzung gemäß einer Ausführungsform darstellt. 1 umfasst das Clientgerät 110, das SMS-Netzwerk 120, den Registrierungsserver 140, und den IP Benachrichtigungsdatenspeicher 150. Das Clientgerät 110 (zum Beispiel eine Workstation, ein Laptop, ein Palmtop, ein Computertelefon, ein Smartphone, ein Multimediatelefon, ein Tablet, ein tragbarer Mediaplayer, eine GPS-Einheit, ein Spielesystem, etc.) umfasst den Erkennungstoken 115 (der in einer Ausführungsform ein Pushtoken sein kann). Der Erkennungstoken 115 identifiziert das Clientgerät 110 eindeutig zum Empfangen von Einladungsanfragen und Einladungsannahme (oder Ablehnungs-)Nachrichten, die später detaillierter beschrieben werden. Die Gerätekennung 117 identifiziert das Clientgerät eindeutig und basiert typischerweise auf einer oder mehreren Hardwarekennungen (zum Beispiel eine Seriennummer des Geräts, ein ICC-ID (Integrated Circuit Card ID) eines SIM (Subscriber Identity Module) Karte, etc.). Das Clientgerät 110 weist die Fähigkeit auf, sowohl SMS-Nachrichten zu übermitteln und zu empfangen als auch die Fähigkeit IP-Nachrichten zu verbinden und zu senden/empfangen.
Nach der Registrierung für eine Online-Kommunikationssitzung kann das Clientgerät 110 zu Online-Kommunikationssitzungen einladen und/oder Einladungen annehmen. Das Clientgerät 110 wird in den Online-Kommunikationssitzungen über eine Online-Kommunikationssitzungsendpunktkennung identifiziert. Während in einer Ausführungsform die Online-Kommunikationssitzungsendpunktkennung eine Telefonnummer des Clientgeräts 110 ist, ist die Online-Kommunikationssitzungsendpunktkennung in anderen Ausführungsformen eine andere Kennung (zum Beispiel ein Benutzername (zum Beispiel eine Apple-ID), eine E-Mailadresse, eine Postadresse und eine MACadresse oder andere Kennung).
Das SMS-Netzwerk 120, das den Carrier SMSC (short message service center) 125 und das SMS-Transitgerät 130 (zum Beispiel ein SMS Gateway oder ein SMS Aggregator) umfasst. Das Carrier SMSC 125 rechnet carrierspezifisch und empfängt und liefert SMS-Nachrichten. Zum Beispiel übermittelt das Carrier SMSC 125 SMS-Nachrichten, die von dem Clientgerät 110 an das SMS-Transitgerät 130 geschickt wurden, und übermittelt SMS-Nachrichten, die von dem SMS-Transitgerät 130 an das Clientgerät 110 gesendet wurden. Das SMS-Transitgerät 130 trennt das mobile Netzwerk und das IP-Netzwerk.
Der Registrierungsserver 140 registriert Clientgeräte wie beispielsweise das Clientgerät 110 für Online-Kommunikationssitzungen. Bei Registrierung eines Clientgeräts für Online-Kommunikationssitzungen umfasst das Assoziieren eines Erkennungstokens eines Geräts mit der Telefonnummer des Geräts (oder andere Online-Kommunikationssitzungsendpunktkennung). Die Assoziation zwischen Erkennungstoken und Online-Kommunikationssitzungsendpunktkennung werden in dem Online-Kommunikationssitzungsregistrierungsdatenspeicher 150 gespeichert.
Wenn ein Ereignis bei dem Clientgerät 110 eintritt (zum Beispiel wenn das Clientgerät einschaltet, eine Online-Kommunikationssitzungsanwendung (zum Beispiel eine P2P-Videokonferenzanwendung, eine P2P-Instant Message Anwendung, etc.) beginnt das Clientgerät 110 einen Registrierungsprozess für Online-Kommunikationssitzungen. In einer Ausführungsform beginnt der Registrierungsprozess automatisch (ohne Nutzerinteraktion) während der Registrierungsprozess in anderen Ausführungsbeispielen beginnt, nachdem ein Benutzer entschieden hat, das Clientgerät für Online-Kommunikationssitzungen zu registrieren.
In Ausführungsformen, in denen die Telefonnummer des Clientgeräts 110 als Online- Kommunikationssitzungsendpunktkennung verwendet wird, und somit mit dem Erkennungstoken 115 des Clientgeräts 110 in den Registrierungsdatenspeicher 150 verknüpft werden muss, muss die Telefonnummer des Clientgeräts 110 bestimmt werden. Da das Clientgerät 110 natürlich seine eigene Telefonnummer nicht kennt, wird in manchen Ausführungsformen die Telefonnummer des Clientgeräts 110 über das Clientgerät 110, das eine SMS-Nachricht übermittelt, bestimmt. Zum Beispiel bei Ablauf 1, übermittelt das Clientgerät 110 eine SMS-Nachricht mit seinem Erkennungstoken 115 und der Gerätekennung 117 an das SMS-Transitgerät 130 über das Carrier SMSC 125. In manchen Ausführungsformen wird die SMS-Nachricht an eine Telefonnummer adressiert, die eine Nummer mit einer Standardlänge ist oder ein kurzer Code (eine Art von Telefonnummern, die typischerweise deutlich kürzer ist als eine vollständige Telefonnummer), die speziell für Online-Kommunikationssitzungsregistrierung aufgebaut ist. Die Telefonnummer, an die die SMS-Nachricht adressiert ist, ist in dem Clientgerät gespeichert (zum Beispiel in einem Carrierbund).
Das Carrier SMSC 125 empfängt die SMS-Nachricht und liefert es an das SMS-Transitgerät 130. Das SMS-Transitgerät 130 bestimmt die Telefonnummer des Clientgerät bei Ablauf 2. Zum Beispiel überprüft das SMS-Transitgerät 130 den Header der SMS-Nachricht, um die Telefonnummer des Clientgeräts 110 zu bestimmen. Nach der Bestimmung der Telefonnummer, übermittelt das SMS-Transitgerät 130 eine IP-Nachricht an den Registrierungsserver 140 mit der Telefonnummer des Clientgeräts 110 des Erkennungstokens 115 und der Gerätekennung 117. Dies wird manchmal als Registrierungsanfragenachricht bezeichnet.
Der Registrierungsserver 140 empfängt die IP-Nachricht von dem SMS-Transitgerät einschließlich der Telefonnummer des Clientgeräts 110, des Erkennungstoken 115 und der Gerätekennung 117 und zeugt eine Signatur. Die Signatur kann auf der Telefonnummer des Clientgeräts 110, des Erkennungstoken 115 und/oder der Gerätekennung 117 basieren, und wird zu Validierungszwecken verwendet (was hier noch später detaillierter beschrieben wird). In manchen Ausführungsformen wird auch eine Zufallszahl verwendet, wenn die Signatur erzeugt wird, um Situationen zu berücksichtigen, in denen eine Vielzahl von Clientgeräten die gleiche Telefonnummer haben. Der Registrierungsserver 140 übermittelt die Signatur, die Telefonnummer, die Gerätekennung und den Token zurück an das SMS-Transitgerät 130 bei Ablauf 5 (zum Beispiel in einer IP-Nachricht). Es wird manchmal als Registrierungsantwortnachricht bezeichnet.
Das SMS-Transitgerät 130 empfängt die Signatur, die Telefonnummer, die Gerätekennung und den Token von dem Registrierungsserver 140 und erzeugt eine SMS-Nachricht mit der Signatur und der Telefonnummer für das Clientgerät 110. Das SMS-Transitgerät 130 übermittelt die SMS-Nachricht an das Clientgerät 110 mit der Signatur und der Telefonnummer bei Ablauf 6 (über das Carrier SMSC 125).
Das Clientgerät 110 empfängt und verarbeitet die SMS-Nachricht einschließlich der Speicherung seiner Telefonnummer. Das Clientgerät 110 übermittelt eine IP-Nachricht mit seinem Erkennungstoken 115, der Gerätekennung 117, seiner Telefonnummer und der Signatur, die durch den Registrierungsserver erzeugt wurde an den Registrierungsserver 140 bei Ablauf 7. Es wird manchmal als Registrierungsvalidierungsanfragenachricht bezeichnet.
Unter Verwendung der Signatur validiert der Registrierungsserver 140 die Daten, die durch das Clientgerät 110 gesendet werden. Zum Beispiel vergleicht der Registrierungsserver 140 die Signatur, die durch das Clientgerät 110 gesendet wurde mit der Signatur, die während des Ablaufs 4 erzeugt wurde. Falls sie zusammen passen, werden die Daten validiert. Angenommen die Daten sind valide, speichert der Registrierungsserver 140 eine Assoziation zwischen dem Erkennungstoken 115 und der Telefonnummer des Clientgeräts 110 in dem Online-Kommunikationssitzungsregistrierungsdatenspeicher 150.
In einer alternativen Ausführungsform wird anstelle der Bestimmung der Telefonnummer des Clientgeräts 110 über die Übermittlung von SMS-Nachrichten, der Benutzer des Geräts dazu aufgefordert die Telefonnummer des Clientgeräts 110 einzugeben. In diesen Ausführungsformen übermittelt das Clientgerät 110 die Telefonnummer des Clientgeräts 110 direkt (als Eingabe durch den Benutzer) und seines Erkennungstokens 115 an den Registrierungsserver 140, welcher sie mit dem Online-Kommunikationssitzungsregistrierungsdatenspeicher 150 assoziieren kann.
5 stellt einen beispielhaften Registrierungsdatenspeicher 150 gemäß einer Ausführungsform dar. Wie in 5 dargestellt, umfasst jeder der Online-Kommunikationssitzungskennungsdatensätze 510 ein Erkennungstokenfeld 520 und ein Telefonnummerfeld 525. In manchen Situationen ist es für eine einzelne Telefonnummer möglich, mit einer Vielzahl von Erkennungstoken verknüpft zu sein. Zum Beispiel können verschiedene Clientgeräte die gleiche Telefonnummer haben. In diesen Fällen würden diese verschiedenen Clientgeräte verschiedene Erkennungstoken haben. Somit wird wenn eine Online-Kommunikationssitzungseinladung für eine Telefonnummer, die mit einer Vielzahl von Erkennungstoken verknüpft ist gesendet wird, eine Einladung an jedes Gerät, das mit dem Erkennungstoken verknüpft ist, gesendet.
2 ist ein Blockdiagramm, das das Clientgerät 110 detailliert darstellt gemäß einer Ausführungsform. 2 wird in Bezug zu der beispielhaften Ausführungsform von 4 beschrieben, welche ein Flussdiagramm ist, die beispielhafte Abläufe für das Registrieren eines Clientgeräts für Online-Kommunikationssitzungen darstellt. Jedenfalls versteht sich, dass die Abläufe von 4 durch andere Ausführungsformen als solche, die mit Bezug auf 2 diskutiert werden, ausgeführt werden können, und dass die Ausführungsformen, die mit Bezug auf 2 diskutiert werden, Abläufe ausführen können, die sich von denen, die mit Bezug auf 4 diskutiert werden, unterscheiden.
Wie in 2 dargestellt, umfasst das Clientgerät 110 das Client-Online-Kommunikationssitzungsregistrierungsmodul („Client Registration Module”) 210, die Carrierbündel 215, den Pushtoken 115, die Gerätekennung 117, das SMS-Modul 220 und den Client-Online-Kommunikationssitzungsregistrierungsdatenspeicher („Client Registration Data Store”) 230. Das Clientregistrierungsmodul 210 steuert der Registrierung des Clientgeräts 110 für Online-Kommunikationssitzungen. Die Carrierbündel 215 umfassen Einstellungen, die für Carrier spezifisch sind, einschließlich der Telefonnummer für das SMS-Transitgerät, das für die Registrierung benutzt wird (zum Beispiel die Nummer des SMS-Transitgeräts 130) und andere Einstellungen (zum Beispiel Acces Point Name (APN) Einstellungen, Multimedia Messaging Service (MMS) Einstellungen, etc.). Das SMS-Modul 220 übermittelt und empfängt SMS-Nachrichten. Der Clientregistrierungsdatenspeicher 230 speichert Daten, die sich auf Online-Kommunikationssitzungsregistrierung beziehen (zum Beispiel die Telefonnummer des Clientgeräts 110, sobald es bestimmt ist).
In Bezug auf 4 bei Block 410 detektiert oder empfängt das Clientregistrierungsmodul 210 ein Ereignis, das die Online-Kommunikationssitzungsregistrierung triggert. Beispiele solcher Ereignisse umfassen das Anschalten des Clientgeräts 110, das Öffnen einer Online-Kommunikationsanwendung durch einen Nutzer (zum Beispiel eine P2P-Videokonferenzanwendung, eine P2P Instant Messaging Anwendung, etc.), etc. In manchen Ausführungsformen wird Registrierungsprozess jedes Mal wenn das Clientgerät 410 angeschaltet wird durchgeführt, während in anderen Ausführungsformen der Registrierungsprozess beim ersten Mal, wenn das Clientgerät 110 angeschaltet wird, durchgeführt wird. Der Fluss bewegt sich von Block 410 zu Block 415.
Bei Block 415 bestimmt das Clientregistrierungsmodul 210, ob ein valider Erkennungstoken für das Clientgerät 110 existiert. Falls kein Erkennungstoken existiert oder der Erkennungstoken abgelaufen ist, bewegt sich der Fluss zu Block 425, wo eine alternative Aktion durchgeführt wird. Zum Beispiel kann in Ausführungsformen, die den Pushtoken benutzen, das Clientgerät 110 eine Tokenerzeugungsprozedur initiieren, indem es verlangt, das ein Pushtoken durch den Pushbenachrichtigungsservice erzeugt wird (welche typischerweise von dem Clientgerät 110 entfernt liegt). Der Pushbenachrichtigungsservice erzeugt Pushtoken, spezifisch für das Clientgerät 110 und gibt es dem Clientgerät 110 zurück. Falls ein valider Erkennungstoken existiert, bewegt sich der Fluss zu Block 420, wo das Clientregistrierungsmodul 210 auf das Erkennungstoken 115 zugreift. Der Fluss bewegt sich von Block 420 zu Block 428.
Bei Block 428 greift das Clientregistrierungsmodul 210 auf die Gerätekennung 117 zu. Der Fluss bewegt sich dann zu Block 430, für das Clientregistrierungsmodul 210 Telefonnummer für das SMS-Transitgerät bestimmt, welches in dem Registrierungsprozess verwendet wird. Z. B. greift das Clientregistrierungsmodul 210 auf die Carrier-Bündel 215 zu, um die Telefonnummer des SMS-Transitgeräts zu bestimmten. Die Telefonnummer kann ein kurzer Code sein oder eine Nummer mit einer Standardlänge. In diesem Beispiel ist das SMS-Transitgerät, das in dem Registrierungsprozess verwendet wird, das SMS-Transitgerät 130. Der Fluss bewegt sich von Block 430 zu Block 435.
Bei Block 435 wird eine SMS-Nachricht mit dem Erkennungston 115 und der Gerätekennung 117 an die ermittelte Nummer übermittelt (das SMS-Transitgerät 130). Z. B. fordert das Clientregistrierungsmodul 210 das SMS-Modul 220 auf, eine SMS-Nachricht mit dem Erkennungstoken 115 und der Gerätekennung 117 an die ermittelte Nummer zu übertragen. Das SMS-Modul 220 übermittelt SMS-Nachricht mit dem Erkennungstoken an die ermittelte Nummer. Der Fluss bewegt sich von Block 435 zu Block 440, die SMS-Nachricht wird durch das Carrier-SMS c 125 empfangen, welche es an das SMS-Transitgerät 130 führt.
Bei Block 440 bestimmt das SMS-Transitgerät 130 die Telefonnummer des Clientgeräts 310 auf der Grundlage empfangener SMS-Nachricht. Z. B. Überprüft das SMS-Transitgerät den Header der SMS-Nachricht, der die Telefonnummer des Senders inne halten wird, der in diesem Fall das Clientgerät 110 ist. Der Fluss bewegt sich von Block 445 wo das SMS-Transitgerät 130 die Telefonnummer des Clientgeräts 110 den Erkennungstoken 115, und die Gerätekennung 117 einen Registrierungsserver 140 übermittelt (z. B. in einer sicheren IP-Nachricht). Der Fluss bewegt sich von Block 445 zu Block 450.
3 ist ein Blockdiagramm, das den Registrierungsserver 140 detaillierter gemäß einer Ausführungsform darstellt. 3 wird mit Bezug auf die beispielhafte Ausführungsform von 4 beschrieben. Es ist jedoch zu verstehen, dass die Abläufe von 4 durchaus auch durch andere Ausführungsformen als solche die mit Bezug auf 3 diskutiert werden ausgeführt werden können, und die Ausführungsformen die mit Bezug auf 3 diskutiert werden, Abläufe durchführen können, die sich von denen die mit Bezug auf 4 diskutiert werden unterscheiden. Wie in 3 dargestellt, umfasst der Registrierungsserver 440 das Serveronlinekommunikationssitzungsregistrierungsmodul 305, das die SMS-Transitschnittstelle 310, den Signaturgenerator 315 die Clientgeräteschnittstelle 325, das Validierungsmodul 330, den Validierungsdatenspeicher 335, und das Assoziationsmodul 340 fasst.
Die SMS-Transitschnittstelle 310 empfängt und sendet Nachrichten an das SMS-Transitgerät 130. Z. B. empfängt die SMS-Transitschnittstelle 310 Telefonnummer, Kennungstoken und Gerätekennungstupel von der SMS-Transitschnittstelle 310 und übermittelt Telefonnummern, Erkennungstoken, Gerätekennung und Signaturtupel (manchmal als „Validierungstupel” bezeichnet) an die SMS-Transitschnittstelle 310. Die Clientgeräteschnittstelle 325 empfängt und kann Nachrichten an die Clientgeräte übermitteln. Z. B. empfängt die Clientgeräteschnittstelle 325 Validierungstubel von Clientgeräten.
Zurückverweisend auf 4 bei Block 450 erzeugt der Signaturgenerator 310 die Signatur für die Telefonnummer, einen Erkennungstoken und Gerätekennungstubel das es von dem SMS-Transitgerät 130 empfangen hat. Die Signatur wird verwendet, um die Paarung von Telefonnummer und Erkennungstoken zu validieren, bevor das Paar in dem Registrierungsdatenspeicher 150 gespeichert wird. In manchen Ausführungsformen basiert die Signatur auf der Telefonnummer, dem Erkennungstoken und/oder der Gerätekennung (z. B. wird ein kryptisches Hash auf die Telefonnummer, auf den Erkennungstoken, und/oder der Gerätekennung, oder manchen Teilen davon angewandt, um die Signatur zu erzeugen. In manchen Ausführungsformen wird die Signatur auch per Zufallszahl, um Situationen zu berücksichtigen, in denen einen Vielzahl von Clientgeräten die gleiche Telefonnummer haben. Der Signaturgenerator 310 speichert die Signatur optional die Telefonnummer, den Erkennungstoken und/oder die Gerätekennung in den Validierungsdatenspeicher 325. Der Fluss bewegt sich dann von Block 455, wo die SMS-Transitschnittstelle 310 die Signatur, die Telefonnummer, die Gerätekennung, und den Erkennungstoken an das SMS-Transitgerät 130 übermittelt. Der Fluss bewegt sich von Block 455 zu Block 460.
Das SMS-Transitgerät 130 empfängt die Signatur, die Telefonnummer, und den Erkennungstoken von dem Registrierungsserver 140. In Block 460 ermittelt das SMS-Transitgerät eine SMS-Nachricht (über das Carrier-SMS c 125) mit der Signatur und der Telefonnummer für das Clientgerät 110. Der Fluss bewegt sich als nächstes zu Block 465.
In Block 465 empfängt das SMS-Modul 220 die SMS-Nachricht mit der Signatur und der Telefonnummer und speichert die Signatur und die Telefonnummer in dem Clientregistrierungsdatenspeicher 230. Der Fluss bewegt sich dann zu Block 470, wo das Clientregistrierungsmodul 210 eine IP-Nachricht an den Registrierungsserver mit seiner Telefonnummer, Erkennungstoken 115, Gerätekennung 117 und Signatur übermittelt. Der Fluss bewegt sich dann zu Block 475.
Die Clientgeräteschnittstelle 325 empfängt die Telefonnummer, Erkennungstoken, Gerätekennung, und Signatur von dem Clientgerät. Die Information wird das Validierungsmodul 330 übergeben, welche bestimmt, ob die Daten in Block 475 valide sind. Z. B. wird die gleiche Hash-Funktion die bei der Erzeugung der Signatur angewandt wird auf die Telefonnummer, den Erkennungstoken, und/oder Gerätekennung, die von dem Clientgerät empfangen wurde verwendet, und das Validierungsmodul 330 vergleicht das Ergebnis mit der Signatur, die vorher erzeugt wurde (gespeichert in dem Validierungsdatenspeicher 335). Falls die Signaturen übereinstimmen, sind die Daten valide und der Fluss bewegt sich zu Block 480.
In Block 480 speichert das Verknüpfungsmodul 330 des Registrierungsservers 140 an der Verknüpfung der Telefonnummer des Clientgeräts und des Erkennungstokens des Clientgeräts in dem Registrierungsdatenspeicher 150. In manchen Ausführungsformen kann der Registrierungsserver 140 eine Registrierungsstatusnachricht an das Clientgerät 110 übermitteln und das Clientgerät 110 darüber alarmieren, ob die Registrierung erfolgreich war.
Nachdem das Clientgerät registriert worden ist, kann ein Nutzer bei dem Clientgerät eine Einladung für eine Onlinekommunikationssitzung (z. B. Videochat, Konferenzsitzung, Instand-Messaging-Session, etc.) initiieren, und/oder annehmen. Als Beispiel kann ein Nutzer bei dem Clientgerät andere Nutzer und anderen Clientgeräte dazu einladen, unter Verwendung ihrer Telefonnummer an einer Onlinekommunikationssitzung teilzunehmen. In manchen Ausführungsformen weist das Clientgerät nicht natürlich seine eigene Telefonnummer, während manche Ausführungsformen die Verwendung von SMS-Nachrichten während der Registrierung beschrieben haben, bei den anderen Ausführungsformen andere Typen von Textbenachrichtigungen verwendet werden (z. B. MMS (multimedia messaging service)).
Registrierung von E-Mail-Adressen für Onlinekommunikationssitzungen
Während 1 mit Bezug zur Registrierung von Telefonnummern als eine Onlinekommunikationssitzungsendpunktkennung beschrieben wurde, wird in anderen Ausführungsformen eine E-Mail-Adresse als eine Onlinekommunikationssitzungsendpunktkennung verwendet. 21 stellt eine allgemeine Netzwerktopologie, die zur Registrierung eines Clientgeräts für Onlinekommunikationssitzungen verwendet wird, dar, die eine E-Mail-Adresse als eine Onlinekommunikationssitzungsendpunktkennung verwenden. Die Clientgeräte 2110A–N verwenden einen Registrierungsdienst 2130 zur Registrierung von Onlinekommunikationssitzungen. Z. B. verwendet der Nutzer eines Clientgerätes 2110A in einer Ausführungsform die Onlinekommunikationssitzungsclient 2115 zur Registrierung einer E-Mail-Adresse zur Verwendung als eine Onlinekommunikationssitzungskennung für Onlinekommunikationen über das Netzwerk 2180 (z. B. das Internet).
22A–B sind Flussdiagramme, die beispielhafte Abläufe zur Registrierung einer E-Mail-Adresse als eine Online-Kommunikationssitzungsendpunktkennung gemäß einer Ausführungsform darstellen. 22a bis b werden mit Bezug zu der beispielhaften Ausführungsform, die in Figur 120 dargestellt ist, beschrieben. Es wird jedoch verstanden, dass die Abläufe von den 22A–B durch andere Ausführungsformen durchgeführt werden können als jene, die Bezug zu 21 diskutiert wurden, und dass die Ausführungsform die mit Bezug auf 21 diskutiert wurden andere Abläufe durchführen können, die sich von denen unterscheiden, die mit Bezug auf die 22a–b diskutiert worden sind.
Bei Ablauf 2210 empfängt der Registrierungsdienst 2130 eine Authentifizierung-Anfrage von dem Clientgerät 2110a. Z. B. mit Bezug zu 23, die beispielhafte Abläufe einen Benutzer beschreibt, der Spezialisierungsinformationen liefert, wird bei Ablauf 2310 die Onlinekommunikationssitzungsanwendung 215 auf dem Clientgerät 2110a gestartet. Der Fluss bewegt sich dann zu Ablauf 2315 um das Clientgerät 2110a empfängt eine Eingabe von dem Benutzer einschließlich einer User-ID und Passwort und einer oder mehreren E-Mail-Adressen zur Registrierung für die Verwendung als Onlinekommunikationssitzungsendpunktkennung. Der Fluss bewegt sich dann zu Ablauf 2320 und das Clientgerät 2110a übermittelt die Benutzer-ID und ein Passwort an den Registrierungsdienst 2130.
Obwohl das Clientgerät 2110a eine E-Mail-Adresse als eine Onlinekommunikationssitzungsendpunktkennung registriert und keine Telefonfunktionalitäten beinhalten kann, kann es eine Onlinekommunikationssitzungseinladung schicken, in dem es eine Telefonnummer anstelle einer E-Mail-Adresse verwendet. Zusätzlich zum Empfang einer User-ID, eines Passworts, und einer oder mehreren E-Mail-Adressen zur Registrierung, kann in manchen Ausführungsformen der Nutzer auch Informationen darüber, in welchem Land und/oder Region er aktuell lokalisiert ist, liefern, sodass ein entsprechender Ländercode und/oder Regionscode verwendet werden kann, falls der Nutzer der Onlinekommunikationssitzung an eine Telefonnummer, das keine Ländercode und/oder Regionscode beinhaltet initiiert. Z. B. kann in den Vereinigten Staaten, ein lokales Telefongespräche durch die Verwendung von sieben Ziffern platziert werden, somit wird der Ländercode und der Bereichscode nicht nötig. Das zugrundeliegende Telefonsystem bestimmt automatisch den Länder- und Bereichscode und vervollständigt das Gespräch. Jedoch in Fällen in denen das Clientgerät 210a keine Telefonfunktionalitäten beinhaltet, kann das Clientgerät 2110a sich nicht auf das zugrundeliegende Telefonsystem verlassen, das es automatisch den Ländercode und/oder Regionscode einsetzt, wenn Nutzer zu einer Onlinekommunikationssitzung unter Verwendung einer Telefonnummer, die nicht den Ländercode und/oder den Regionscode beinhaltet eingeladen wird.
Bei Ablauf 2320 empfängt das Client-Gerät 2110A vom Nutzer Eingaben in Bezug darauf, in welchem Land und/oder Region (z. B. Gebietscode, Staat, Provinz, Stadt, usw.) sie sich befinden. Der Fluss bewegt sich dann zum Ablauf 2320, wo das Client-Gerät 2320 Länder- und/oder Region-Telefoncodes mit der Online-Kommunikationssitzungs-Anwendung 2115 für die Verwendung verknüpft, falls der Nutzer einer Online-Kommunikationssitzung eine Telefonnummer initiiert, die nicht einen Länder- und/oder Regionscode aufweist. Zum Beispiel , wenn der Nutzer anzeigt, dass sie sich in den Vereinigten Staaten befinden, und ein Nutzer einen Nutzer unter Verwendung einer zehnziffrigen Telefonnummer, die nicht einen Ländercode aufweist, zu einer Online-Kommunikationssitzung einlädt, fügt das Client-Gerät 2110A automatisch den Ländercode für die Vereinigten Staaten der Telefonnummer hinzu.
In Bezug auf 22A wird nach dem Empfangen einer Authentifizierungsanfrage von dem Client-Gerät 2110A ein Authentifizierungsprozess unter Verwendung des zur Verfügung gestellten Nutzernamens und Passworts ausgeführt. In einer Ausführungsform führt der Registrierungs-Service 2130 den Authentifizierungsprozess aus, während in einer anderen Ausführungsform der Benutzerverzeichnisdienst 2160 den Authentifizierungsprozess ausführt. Der Benutzerverzeichnisdienst 2160 ist ein zentralisierter Dienst, der Nutzern Accounting, Authentifizierung, und andere Dienste zur Verfügung stellt. Der Benutzerverzeichnisdienst 2160 verwaltet die Benutzerdatensätze 2165. In einer Ausführungsform wird jeder authentifizierte Nutzer mit einem Nutzerdatensatz verknüpft, der verschiedene Informationen beinhaltet (z. B. ein oder mehrere Nutzer-ID, Passwort, Postadresse, Telefonnummer, Name, Geburtstag, Land, eine Liste von Emails, die mit dem Nutzer verknüpft sind (die auch anzeigen können, ob die Email-Adresse validiert wurde), etc.). Falls die Authentifizierung erfolgreich ist, bewegt sich der Fluss zu Ablauf 2216. Falls die Authentifizierung fehlschlägt, bewegt sich der Fluss zu Ablauf 2214 und alternative Aktionen werden durchgeführt (z. B. übermittelt der Registrierungsdienst 2130 eine Fehlermeldung an das Client-Gerät 2110A, das anzeigt, dass der Nutzername und/oder Passwort nicht korrekt ist).
Bei Ablauf 2216 erzeugt und/oder greift der Registrierungsdienst 2130 auf ein Online-Kommunikationssitzungsprofil zu, das mit der Nutzer-ID verknüpft ist. Zum Beispiel kann der Registrierungs-Service 2130 einen Online-Kommunikationssitzungs-Accountserver 2140 beinhalten, der die Online-Kommunikationssitzungsdatensätze 2150 verwaltet. In einer Ausführungsform hat jeder Nutzer, der sich für Online-Kommunikationssitzungen registriert oder bereits registriert ist, einen entsprechenden Online-Kommunikationssitzungsprofildatensatz. Jeder Online-Kommunikationssitzungsprofildatensatz kann einen Satz von einer oder mehreren Email-Adressen beinhalten, einschließlich ihres Validierungsstatus, die mit dem Profil verknüpft sind. Jeder Online-Kommunikationssitzungsprofildatensatz kann auch ein oder mehrere Push-Tokens beinhalten, die einem oder mehreren Client-Geräten entsprechen, bzw. die für Online-Kommunikationssitzungen registriert sind. Jeder Profildatensatz kann auch Profilberechtigungsnachweise beinhalten, die zum Validieren bestimmter Kommunikationen von den Client-Geräten verwendet werden. Jeder Profildatensatz kann auch anzeigen, welche Client-Geräte (wie durch Push-Tokens angezeigt) welche Email-Adressen registriert haben oder versuchen zu registrieren.
Der Fluss bewegt sich von Ablauf 2216 zu Ablauf 2218, und der Registrierungsdienst 2130 übermittelt eine Authentifizierungsantwort an das Client-Gerät 2110A, das die Profil-ID beinhaltet (z. B. als String, das das Profil, das mit der gegebenen Nutzer-ID verknüpft ist, identifiziert) und Profilberechtigungsnachweise beinhaltet. Die Authentifizierungsantwort kann auch anzeigen, dass die Authentifizierung erfolgreich war. Der Fluss bewegt sich dann zu Ablauf 2220 und der Registrierungsdienst 2130 empfängt eine Email-Validierungsanfrage von dem Client-Gerät 2110A, die eine oder mehrere Email-Adressen zum Validieren, Profil-ID, Profilberechtigungsnachweise, und Push-Token des Client-Geräts 2110A beinhaltet. Die Email-Validierungsanfragenachricht kann auch die Geräte-ID des Client-Geräts 2110A beinhalten. Der Registrierungsdienst 2130 bestimmt dann, ob die Profilberechtigungsnachweise für die Profil-ID bei Ablauf 2222 valide sind. Falls sie es nicht sind, bewegt sich der Fluss zu Ablauf 2224 und eine alternative Aktion wird durchgeführt (z. B. übermittelt der Registrierungsdienst 2130 eine Fehlermeldung an das Client-Gerät 2110A). Falls die Profilberechtigungsnachweise valide sind, bewegt sich der Fluss zu Ablauf 2223. Bei Ablauf 2223 verknüpft der Registrierungsdienst 2130 den Push-Token mit dem Profil. Zum Beispiel speichert der Online-Kommunikationssitzungs-Accountserver 2140 den Push-Token in dem Profildatensatz für den Nutzer.
Der Fluss bewegt sich dann zu Ablauf 2226, und der Registrierungsdienst 2130 bestimmt, ob die Email-Adresse validiert wurde. Eine validierte Email-Adresse ist eine Email-Adresse, die als zur Nutzeranfrage gehörig validiert worden ist, die anfragt, dass es für die Nutzung als eine Online-Kommunikationsdienst-Endpunktkennung registriert wird. Der Online-Kommunikationssitzungs-Accountserver 2140 greift auf den Profildatensatz 2150 des Nutzers zu, um zu bestimmen, ob die Email-Adresse validiert ist. Falls der Profildatensatz nicht anzeigt, dass die Email-Adresse validiert ist, übermittelt in manchen Ausführungsformen der Registrierungsdienst 2130 eine Email-Adressvalidierungsanfrage an den Benutzerverzeichnisdienst 2160, um zu bestimmen, ob der Nutzerdatensatz 2165 für den Nutzer anzeigt, dass die Email-Adresse validiert ist. Falls die Email-Adresse nicht validiert ist, bewegt sich der Fluss zu ablauf 2127, und der Registrierungsdienst 2130 veranlasst, dass eine Validierungs-Email-Nachricht an die Email-Adresse gesendet wird, die einen Link beinhaltet, der, wenn er ausgewählt wird (oder in einem Internetbrowser eingegeben wird) verursacht, dass die Email-Adresse validiert wird. Zum Beispiel veranlasst die Auswahl des Links, dass eine Validierungs-Email-Nachricht gesendet wird, die die Email-Adresse beinhaltet und einen Validierungs-Token beinhaltet, der zum Validieren der Email-Adresse verwendet wird. Der Registrierungsdienst 2130 kann auch eine Email-Adressanforderungsvalidierungsnachricht an das Client-Gerät übermitteln, die anzeigt, dass die Email-Adresse nicht validiert ist (und somit validiert werden muss) und kann auch anzeigen, dass eine Validierungs-Email-Nachricht an die betreffende Email-Adresse gesendet wurde. Der Fluss bewegt sich dann zu Ablauf 2410, der mit Bezug zur 24 beschrieben wird. Falls die Email-Adresse validiert wurde, bewegt sich der Fluss zu Ablauf 2228.
Bei Ablauf 2228 übermittelt der Registrierungsdienst 2130 eine Email-Adresse-erfolgreich-validiert-Nachricht an das Client-Gerät 2228, die anzeigt, dass die Email-Adresse validiert worden ist. Der Fluss bewegt sich dann zu Ablauf 2230, und der Registrierungsdienst 2130 empfängt eine Aktivierungs-Email-Anfrage von dem Client-Gerät 2228, die die Email-Adresse, Profil-ID, und Profilberechtigungsnachweise beinhaltet. Der Registrierungsdienst 2130 prüft dann, ob die Profilberechtigungsnachweise für die Profil-ID bei Ablauf 2232 valide sind. Falls sie es nicht sind, bewegt sich der Fluss zu Ablauf 2224, und alternative Aktionen werden durchgeführt (z. B. übermittelt der Registrierungsdienst 2130 eine Fehlermeldung an das Client-Gerät 2110A). Falls die Profilberechtigungsnachweise valide sind, bewegt sich der Fluss zu Ablauf 2240.
Bei Ablauf 2240 erzeugt oder greift der Registrierungsdienst 2130 auf Email-Berechtigungsnachweise für Email-Adressen zu. Zum Beispiel speichert der Online-Kommunikationssitzungs-Accountserver 2140 in einer Ausführungsform die Email-Berechtigungsnachweise für jede validierte Email-Adresse eines Nutzers in dem Profildatensatz 2150 dieses Nutzers. Der Fluss bewegt sich dann zu Ablauf 2242 und der Registrierungsdienst 2130 übermittelt eine Aktivierungserfolgsnachricht an das Client-Gerät 2110A, das die Email-Adresse und die Email-Berechtigungsnachweise beinhaltet.
Der Fluss bewegt sich von Ablauf 2242 zu Ablauf 2244, und der Registrierungsdienst 2130 empfängt eine Registrierungsanfragenachricht, die die Email-Adresse, die Email-Berechtigungsnachweise, die Profil-ID, die Profilberechtigungsnachweise, den Push-Token des Client-Geräts 2110A und die Geräte-ID des Client-Geräts 2110A beinhaltet. In einer Ausführungsform wird die Anfragennachricht bei einem Online-Kommunikationssitzungs-Registrierungsserver 2145 empfangen. Der Online-Kommunikationssitzungs-Registrierungsserver verwaltet den Online-Kommunikationssitzungs-Registrierungsdatenspeicher 2155. Der Online-Kommunikationssitzungs-Registrierungsdatenspeicher 2155 verknüpft einen Push-Token (optional die Geräte-ID) mit dem Profil, das einen Satz von einer oder mehreren Email-Adressen als Online-Kommunikationssitzungs-Endpunktkennung(en) hat. Somit repräsentiert jeder Datensatz im Kommunikationssitzungs-Registrierungsdatenspeicher 2155, dass ein bestimmtes Gerät mit einem bestimmten Push-Token ein Online-Kommunikationssitzungsprofil verwendet, das ein oder mehrere Email-Adressen hat, die verwendet werden können, um einen Nutzer an diesem Gerät zu einer Online-Kommunikationssitzung einzuladen. Der Fluss bewegt sich von Ablauf 2244 zu Ablauf 2246.
Bei Ablauf 2246 bestimmt der Registrierungsdienst 2130 (z. B. der Online-Kommunikationssitzungs-Registrierungsserver 2145), ob die Profilberechtigungsnachweise valide sind. Falls sie es nicht sind, bewegt sich der Fluss zu Ablauf 2250 und alternative Aktionen werden durchgeführt (z. B. übermittelt der Registrierungsdienst 2130 eine Fehlermeldung an das Client-Gerät 2110A). Falls sie valide sind, bewegt sich der Fluss zu Ablauf 2248 und der Registrierungsdienst 2130 (z. B. der Online-Kommunikationssitzungs-Registrierungsserver 2145) bestimmt, ob die Email-Adressberechtigungsnachweise valide sind. Falls sie es nicht sind, bewegt sich der Fluss zu Ablauf 2250. Falls sie valide sind, bewegt sich der Fluss zu Ablauf 2252.
Bei Ablauf 2252 verknüpft der Registrierungsdienst 2130 (z. B. der Online-Kommunikationssitzungs-Registrierungsserver 2145) das Client-Gerät 2110A mit seinen Push-Token mit dem Profil, das die Email-Adresse hat, und speichert die Verknüpfung in dem Registrierungsdatenspeicher 2155. Der Fluss bewegt sich dann zu Ablauf 2254, und der Registrierungsdienst 2130 erzeugt eine Online-Kommunikationssitzungs-Accountkennung und Online-Kommunikationssitzungs-Berechtigungsnachweise und übermittelt sie an das Client-Gerät 2110A bei Ablauf 2256.
Es gibt verschiedene Möglichkeiten Email-Adressen in verschiedenen Ausführungsformen zu validieren. Mit Bezug zu 24, die ein Flussdiagramm ist, das beispielhafte Abläufe zur Validierung von Email-Adressen anzeigt, bestimmt das Client-Gerät 2110A bei Ablauf 2410, ob es einen Email-Client beinhaltet, der einen Account für eine Email-Adresse beinhaltet, die es versucht hat, zu registrieren und keine positive Validierungs-Email-Nachricht empfangen hat. Falls es nicht einen solchen Email-Client aufweist, bewegt sich der Fluss zu Ablauf 2440, anderenfalls bewegt sich der Fluss zu Ablauf 2415.
Bei Ablauf 2415 wird der Email-Account automatisch periodisch für eine Validierungs-Email-Nachricht überprüft (z. B. die Validierungs-Email-Nachricht, die in Ablauf 2227 übermittelt wurde). In einer Ausführungsform fordert die Online-Kommunikationssitzungs-Anwendung 2115 den Email-Client 2120 periodisch dazu auf, auf Validierungs-Email-Nachrichten zu überprüfen (der Email-Client 2120 kann den Emailserver 2170 abfragen, auf Validierungs-Email-Nachrichten zu überprüfen). Die Validierungs-Email-Nachricht wird gekennzeichnet durch einen Satz von einem oder mehreren Kriterien, einschließlich das Von:Feld, An:Feld, und ein Validierungs-Token (der Validierungs-Token kann für jede validierte Email-Adresse eindeutig sein), das verwendet wird, um Email-Adressen zu validieren. Der Validierungs-Token kann sich in dem Header über dem Body der Validierungs-Email-Nachricht befinden. Falls die Validierungs-Email-Nachricht empfangen wird, bewegt sich der Fluss von dem Ablauf 2420 zu dem Ablauf 2425, anderenfalls bewegt sich der Fluss zu dem Ablauf 2435.
Bei Ablauf 2425 wird die Validierungs-Email-Nachricht an die Online-Kommunikationssitzungs-Anwendung 2115 zurückgegeben und es analysiert die Nachricht, um den Validierungs-Token zu lokalisieren.
Nach der Lokalisierung des Validierungs-Tokens übermittelt die Online-Kommunikationssitzungs-Anwendung 2115 eine Email-Adressvalidierungsnachricht an den Registrierungsdienst 2130 mit dem Validierungs-Token, der Email-Adresse, der Profil-ID, und den Profilberechtigungsnachweisen. Somit wird in dieser Ausführungsform die Email-Adresse automatisch validiert, ohne dass der Nutzer auf einen Link klicken muss oder anderweitig die Email-Adresse validieren muss. In einer Ausführungsform übermittelt der Registrierungsdienst 2130, nach dem Empfangen der Nachricht und dem Bestimmen, dass Profilberechtigungsnachweise valide sind, eine Email-validiert-Push-Nachricht (über den Push-Benachrichtigungs-Service 640) an das Gerät, das anzeigt, dass die Email-Adresse erfolgreich validiert worden ist. Somit bewegt sich der Fluss von Ablauf 2425 zu Ablauf 2430 und das Client-Gerät 2110A wartet darauf, die Email-Adresse-validiert-Push-Nachricht zu empfangen.
Falls eine Email-Validierungsnachricht nicht empfangen worden ist, bewegt sich der Fluss zu Ablauf 2435, wo das Client-Gerät bestimmt, ob eine Email-validiert-Push-Nachricht empfangen worden ist, die anzeigt, dass die Email-Adresse, die registriert werden will, validiert worden ist. Falls eine solche Nachricht empfangen wird, bewegt sich der Fluss zu Ablauf 2445, anderenfalls bewegt sich der Fluss zurück zu Ablauf 2415.
Bei Ablauf 2440 (das Client-Gerät 2110A beinhaltet nicht einen Email-Client, der ein Account für die Email-Adresse, die registriert worden ist, aufweist), wartet das Client-Gerät 2110A darauf, eine Email-validiert-Push-Nachricht zu empfangen, die anzeigt, dass die Email-Adresse, die registriert werden soll, validiert worden ist. Falls eine solche Nachricht empfangen wird, bewegt sich der Fluss zu Ablauf 2445, anderenfalls bleibt der muss bei Ablauf 2440.
Bei Ablauf 2445 zeigt das Client-Gerät 2110A an, dass die Email-Adresse validiert worden ist, und fragt den Nutzer mit dem Registrierungsprozess mit dieser Email-Adresse fortzufahren. Falls das Client-Gerät 2110A Eingaben empfängt, die anzeigen, dass mit dem Registrierungsprozess fortgefahren werden soll, bewegt sich der Fluss zu Ablauf 2455 und das Client-Gerät 2110A übermittelt eine aktive Emailanfrage, die die Email-Adresse, die Profil-ID, und die Profilberechtigungsnachweise enthält, an den Registrierungsserver. Die beschriebenen Abläufe, die bei Ablauf 2230 von 22 beginnen, werden dann ausgeführt. Falls das Client-Gerät 2110A Eingaben empfängt, die anzeigen, dass der Nutzer nicht mit dem Registrierungsprozess fortfahren möchte, bewegt sich der Fluss von Ablauf 2450 zu Ablauf 2460 und der Prozess endet.
25 ist ein Flussdiagramm, das beispielhafte Abläufe darstellt, die beim Registrierungsdienst ausgeführt werden, wenn eine Email-Adresse gemäß einer Ausführungsform validiert worden ist. Bei Ablauf 2510 erhält der Registrierungsdienst 2130 eine Email-Adresse-validiert-Statusnachricht, die anzeigt, dass eine Email-Adresse, die mit einem Online-Kommunikationssitzungsprofil verknüpft ist, validiert worden ist. Die Email-Adresse-validiert-Statusnachricht kann als ein Ergebnis von Ablauf 2425 empfangen worden sein, oder als Ergebnis davon empfangen worden sein, dass die Email-Adresse auf eine andere Weise validiert worden ist (z. B. ein Nutzer klickt auf einen Validierungslink in einer Validierungs-Email-Nachricht, die veranlasst, dass die Email-Adresse validiert wird, die an Geräte geschickt werden kann, die sich von dem Gerät unterscheiden, das versucht, die Email-Adresse für die Verwendung in Online-Kommunikationssitzungen registrieren zu können).
Der Fluss bewegt sich dann zu Ablauf 2415 und der Registrierungsdienst 2130 aktualisiert den Validierungsstatus für die Email-Adresse in den Profildatensätzen 2150. Der Fluss bewegt sich dann zu Ablauf 2515 und der Registrierungsdienst 2130 bestimmt, ob Client-Geräte vorhanden sind, die mit dem Online-Kommunikationssitzungsprofil verknüpft sind, die die Validierung der Email-Adresse erfragt haben, die keine Email-Adresse-validiert-Nachricht empfangen haben. Zum Beispiel greift der Registrierungsdienst 2130 auf den Profildatensatz 2150 für das Online-Kommunikationssitzungsprofil zu, um zu bestimmen, welche Client-Geräte (z. B. wie durch eindeutige Push-Tokens identifiziert) die Validierung der Email-Adressen angefragt haben und welche keine Email-Adressvalidierungsnachricht für diese Email-Adresse empfangen haben. Für jedes solcher Client-Geräte übermittelt der Registrierungsdienst eine Email-validiert-Push-Nachricht an das Client-Gerät, das die Profil-ID, Profilberechtigungsnachweise, und die Email-Adresse, die bei Ablauf 2525 validiert worden ist, enthält. Die Emailvalidiert-Push-Nachricht kann auch ein Statusupdate enthalten, um anzuzeigen, dass die Email-Adresse validiert worden ist. Falls es keine Geräte gibt, die die Validierung der Email-Adresse angefragt haben, die keine Email-Adresse-validiert-Nachricht empfangen haben, bewegt sich der Fluss zu Ablauf 2530 und der Prozess endet.
Aufbauen von Online-Kommunikationssitzungen
Wie in 6 dargestellt, kann eine grundsätzliche Netzwerktopologie, die in einer Ausführungsform implementiert wurde, eine Reihe von Client-Geräten A–N, 670A–N aufweisen, bzw. miteinander und mit einem oder mehreren Diensten 610, 620, 630, 640, und 650 über ein Netzwerk 660 kommunizieren. Obwohl das als eine einzelne Netzwerk-Cloud dargestellt ist, kann das Netzwerk 660 eine Vielzahl von verschiedenen Komponenten, einschließlich öffentliche Netzwerke wie beispielsweise das Internet, und private Netzwerke wie beispielsweise lokale WiFi-Netzwerke (z. B. 802.11n Home Wireless Networks oder Wireless Hotspots) umfassen, Local-Area-Ethernet-Netzwerke, Cellular-Data-Datennetzwerke (z. B. 3G, 4G, Edge, etc.) und WiMAX-Netzwerke, um nur einige zu nennen. Die Client-Geräte 670A–N können das Netzwerk 660 über verschiedene Netzwerklinks verbinden. Zum Beispiel kann das Client-Gerät 670A an ein Home-WiFi-Netzwerk, das durch ein Netzwerklink 675A repräsentiert wird, verbunden werden, und Client-Gerät 670N kann mit einem 3G-Netzwerk verbunden werden (z. B. Universal Mobile Telecommunications System (”UMTS”), High-Speed Uplink Packet Access (”HSUPA”), etc.) über den Netzwerklink 675N. Jedes der Netzwerklinks 675A–N, über die Client-Geräte 675A–N verbunden sind, kann an ein öffentliches Netzwerk wie beispielsweise das Internet über einen Gateway und/oder NAT(Network Address Translation)-Gerät (nicht in 6 gezeigt) verknüpft werden, und dadurch Kommunikation zwischen verschiedenen Client-Geräten 670A–N über das öffentliche Netzwerk ermöglichen. Jedenfalls können zwei Client-Geräte, die sich auf dem gleichen lokalen oder privaten Netzwerk befinden (z. B. das gleiche WiFi-Netzwerk), direkt über das lokale/private Netzwerk kommunizieren, und das öffentliche Netzwerk umgehen. Es ist natürlich darauf hinzuweisen, dass die zugrundeliegenden Prinzipien der Erfindung nicht auf irgendwelche bestimmten Netzwerktypen oder Netzwerktopologien festgelegt sind.
Jedes der Client-Geräte 670A–N kann mit einem Connection Data Exchange (CDX) Dienst 610, einem Einladungsdienst 620, einem registrierungsdienst 630, einem Push-Benachrichtigungsdienst 640, und einem Relay-Dienst 650 kommunizieren. In einer Ausführungsform können die Dienste 610–650 als Software implementiert sein, die über ein oder mehrere physische Computergeräte wie beispielsweise Server ausgeführt werden.
In einer Ausführungsform arbeitet der CDX-Dienst 610 als zentraler Austauschpunkt für Verbindungsdaten, die zum Aufbau von Onlinekommunikationsdiensten zwischen zwei oder mehreren Client-Geräten erforderlich sind. Speziell eine Ausführungsform von dem CDX-Dienst 610 erzeugt NAT-Traversaldaten (manchmal als ”Hole Punch”-Daten bezeichnet) als Antwort darauf, dass das Client-Gerät verlangt, dass externe Dienste und Clients befähigt werden, über das NAT von jedem Client-Gerät zu kommunizieren (d. h. um ”ein Loch zu stanzen” durch das NAT, um das Gerät zu erreichen). Zum Beispiel detektiert der CDX-Dienst in einer Ausführungsform die externe IP-Adresse und Port, die zur Kommunikation mit dem Client-Gerät benötigt werden, und stellt diese Informationen dem Client-Gerät zur Verfügung. In einer Ausführungsform empfängt und verarbeitet der CDX-Dienst auch Listen von Client-Geräten, die durch den Einladungsdienst 620 erzeugt wurden, und verteilt auf effiziente und sichere Weise Verbindungsdaten an jedes der Client-Geräte, die in den Listen enthalten sind (wie im Detail unten beschrieben).
Nutzer der Client-Geräte 670A–N benutzen den Einladungsdienst 620, um Nutzer einzuladen, an kommunikativen Online-Kommunikationssitzungen teilzunehmen (z. B. P2P-Videokonferenz, P2P-Instantmessaging-Chats/-Konferenz, etc.). Zum Beispiel fordert ein Nutzer des Client-Geräts 670A eine Online-Kommunikationssitzung mit einem oder mehreren Nutzern von einem oder mehreren verschiedenen Client-Geräten an durch Übermittlung einer Einladungsanfrage an den Einladungsdienst 620, die eine Online-Kommunikationssitzungs-Endpunktkennung von jedem der anderen Nutzer aufweist. Die Online-Kommunikationssitzungs-Endpunktkennung kann in verschiedenen Ausführungsformen unterschiedlich sein (z. B. eine Telefonnummer, ein Nutzername (z. B. eine Apple-ID), eine Email-Adresse, eine Postadresse, eine MAC-Adresse, oder andere Kennungen). Der Einladungsdienst 620 liest die Online-Kommunikationssitzungs-Endpunktkennung(en) von der Einladungsanfrage und führt eine Suche in dem Registrierungsdatenspeicher 655 durch, um die Client-Geräte, die mit dem Online-Kommunikationssitzungs-Endpunktkennung assoziiert sind, zu lokalisieren.
Die Client-Geräte 670A–N verwenden den Registrierungsdienst 630, um für Online-Kommunikationssitzungen zu registrieren. Zum Beispiel in einer Ausführungsform, wenn jedes der Client-Geräte 670A–N eingeschaltet ist und auf dem Netzwerk aktiviert ist, veranlasst es seinen Zugangsschlüssel dazu (z. B. seinen Push-Token), mit einer Online-Kommunikationssitzungs-Endpunktkennung verknüpft zu werden. Verknüpfungen werden in dem Registrierungsdatenspeicher 655 gespeichert. In einer Ausführungsform registrieren sich die Client-Geräte 670A–N für die Teilnahme an einem Online-Kommunikationssitzungsdienst unter Verwendung des Registrierungsdiensts 630, wie mit Bezug zu 4 beschrieben, während der Registrierungsprozess in anderen Ausführungsformen anderer Weise stattfindet (z. B. indem sowohl ihre Push-Token als auch ihre Online-Kommunikationssitzungs-Endpunktkennung liefern).
Der Push-Benachrichtigungsdienst 640 benutzt die Push-Token der Client-Geräte 670A–N, um die Push-Benachrichtigungen an die Client-Geräte 670A–N zu übermitteln. In einer Ausführungsform werden die Push-Benachrichtigungen verwendet, um die Einladungen für die Online-Kommunikationssitzungen zu übermitteln. Der Relay-Dienst 650 baut Online-Kommunikationssitzungsverbindungen zwischen Client-Geräten auf, wenn die NAT-Typen der Client-Geräte nicht kompatibel sind oder der P2P-Verbindungsaufbau zwischen den Client-Geräten fehlgeschlagen ist.
In einer Ausführungsform wird die Kommunikation zwischen den Client-Geräten und dem CDX-Dienst 610 aufgebaut unter Verwendung eines relativ leichten Netzwerkprotokolls, wie beispielsweise eines Nutzer-Datagramm-Protocol(”UDP”)-Sockels. Wie dem Fachmann bekannt ist, benötigen UDP-Socket-Verbindungen keine Handshaking-Dialoge, um die Zuverlässigkeit der Pakete, Bestellung, oder Datenintegrität zu garantieren und verbrauchen daher nicht so viel Verarbeitungsoverhead wie TCP-Socket-Verbindungen. Infolgedessen ist die leichte, zustandslose Natur UDPs nützlich für Server, die kleine Abfragen von einer Vielzahl von Clients antworten. Vielmehr ist UDP, im Gegensatz zu TCP, kompatibel mit Paketausstrahlung (in welchem Pakete an alle Geräte im lokalen Netzwerk versendet werden) und Multitasking (in welchem Pakete an eine Untergruppe von Geräten in dem lokalen Netzwerk versendet werden). Wie unten beschrieben, kann, obwohl UDP genutzt werden kann, die Sicherheit auf dem CDX-Dienst 610 beibehalten werden, indem NAT-Traversaldaten verschlüsselt werden mithilfe von Sitzungsschlüsseln.
Im Gegensatz zu dem Niedrig-Overhead, leichten Netzwerkprotokollen, das durch den CDX-Dienst 610 verwendet wird, wird in einer Ausführungsform die Kommunikation zwischen den Client-Geräten 670A–N und dem Einladungsdienst 620, Registrierungsdienst 630, Push-Benachrichtigungsdienst 640, und/oder dem Relay-Dienst 650 mit einem inhärent sicheren Netzwerkprotokoll wie beispielsweise Hypertext Transfer Protocol Secure (”HTTPS”) aufgebaut, der auf Secure Sockets Layer (”SSL”) oder Transport Layer Security (”TLS”) Verbindungen beruht. Details, die mit diesen Protokollen in Verbindung stehen, sind dem Fachmann wohlbekannt.
7 ist ein Datenflussdiagramm, das den Online-Kommunikationssitzungsaufbau zwischen Client-Geräten gemäß einer Ausführungsform darstellt. Im Beispiel von 7 lädt ein Nutzer am Client-Gerät A 710 einen Nutzer am Client-Gerät B 720 zu einer Online-Kommunikationssitzung ein (z. B. eine P2P-Videokonferenz, ein P2P-Instantmessaging-System, etc.). In diesem Beispiel wird das Client-Gerät A 710 manchmal als ein initiierendes Client-Gerät bezeichnet, der Nutzer des Client-Geräts B 720 wird manchmal als der beabsichtigte Empfänger bezeichnet, und das Client-Gerät B 720 wird manchmal als beabsichtigtes EmpfängerClient-Gerät bezeichnet. In manchen Ausführungsformen ist die Online-Kommunikationssitzungseinladung eine blinde Einladung ohne Präsenz. Zum Beispiel weiß der Nutzer am Client-Gerät A 710 nicht, ob der Nutzer am Client-Gerät B 720 gerade online oder verfügbar ist, um an einer Online-Kommunikationssitzung teilzunehmen.
Während Ausführungsformen, die mit Bezug zu den 6 und 7 beschrieben wurden, spezifisch für die Verwendung von Push-Tokens und Push-Benachrichtigungen sind, sind andere Ausführungsformen nicht auf diese Weise beschränkt. Zum Beispiel können in anderen Ausführungsformen jede Registrierung oder Abbildung von Client-Geräten auf eindeutige Token verwendet werden, um Zugangsschlüssel mit Client-Geräten zu assoziieren und ein zuverlässiges Verfahren für die Assoziierung der Identität von Client-Geräten mit einem eindeutig identifizierten Token zur Verfügung zu stellen.
Bei Ablauf 1 fragt das Client-Gerät A 710 seine Verbindungsdaten von dem Verbindungsdatenaustausch 610 ab. Die Verbindungsdatei beinhaltet Informationen für Client-Geräte, die miteinander ausgetauscht werden können, um eine Online-Kommunikationssitzung aufzubauen (z. B. eine P2P-Sitzung). Eine Verbindungsdatei beinhaltet die IP-Adresse von dem Client-Gerät (z. B. die öffentliche IP-Adresse), die Portnummer der Anfrage, und andere Informationen (z. B. Prioritätsinformationen, etc.). Der Verbindungsdatenaustausch 610 bestimmt die Verbindungsdatei von dem Client-Gerät A 710 (z. B. die öffentlichen/privaten IP-Adressen und Ports, NAT-Typ von dem Client-Gerät A NAT-Gerät). Bei Ablauf 2 gibt der Verbindungsdatenaustausch 610 die Verbindungsdatei an das Client-Gerät A 710 zurück.
Bei Ablauf 3 übermittelt das Client-Gerät A 710 eine Online-Kommunikationssitzungs-Einladungsanfrage an den Einladungsdienst 620, um das Client-Gerät B 720 zu einer Online-Kommunikationssitzung einzuladen (z. B. eine P2P-Videokonferenz, eine P2P-Instantmessaging-Sitzung, etc.). In einer Ausführungsform beinhaltet die Einladung die Verbindungsdaten des Client-Geräts A 710, die öffentliche/private IP-Adressen und Ports für ein Client-Gerät A 710 und den NAT-Typ für Client-Gerät A NAT-Gerät und eine Online-Kommunikationssitzungs-Endpunktkennung, die mit dem Nutzer an dem Client-Gerät B 720 assoziiert ist (z. B. eine Telefonnummer vom Client-Gerät B 720, ein Benutzername des Nutzers (z. B. eine Apple-ID), eine Email-Adresse, eine Postadresse, eine MAC-Adresse, etc.). Die Online-Kommunikationssitzungs-Einladungsanfrage kann die Form einer HTTPS-Anfrage annehmen und kann ein Clientzertifikat, das durch eine vorab spezifizierte Zertifikatsautorität signiert wurde, aufweisen.
Bei Ablauf 4 bestimmt Einladungsdienst 620 die Push-Token, die mit der Online-Kommunikationssitzungs-Endpunktkennung, die in der Anfrage von Ablauf 3 enthalten ist, verknüpft sind. Zum Beispiel greift der Einladungsdienst 620 auf den Registrierungsdatenspeicher 655 zu, um die Push-Token zu bestimmen, die mit der Online-Kommunikationssitzungs-Endpunktkennung verknüpft sind. Wie in 7 dargestellt, ist der Push-Token 725 dem Client-Gerät B 720 zugeordnet und somit mit seiner Online-Kommunikationssitzungs-Endpunktkennung verknüpft. 10 stellt einen beispielhaften Registrierungsdatenspeicher 655 gemäß einer Ausführungsform dar. Wie in 10 dargestellt, umfasst jeder Online-Kommunikationssitzungs-Kennungsdatensatz 1010 ein Push-Token-Feld 1015 und ein Online-Kommunikationssitzungs-Kennungsfeld 1020 auf. Wie in 10 dargestellt, kann die gleiche Online-Kommunikationssitzungs-Kennung mit einer Mehrzahl von Push-Token verknüpft sein. In einem solchen Fall wird eine Mehrzahl von Einladungen übermittelt (z. B. jeweils eine pro Push-Token).
Der Einladungsdienst 620 übermittelt eine Push-Anfragenachricht an den Push-Benachrichtigungsdienst 640. Bei Ablauf 5 übermittelt der Push-Benachrichtigungsdienst 640 eine Online-Kommunikationssitzungs-Einladungsanfrage, in Form einer Push-Benachrichtigungs-Nachricht an das Client-Gerät B 720. Die Anfrage umfasst die Verbindungsdatei, die Online-Kommunikationssitzungs-Endpunktkennung, und den Push-Token von dem Client-Gerät A 710 (der Push-Token 715). Die Einladungsanfrage kann auch für die Online-Kommunikationssitzung spezifische Anfragen umfassen, um den Nutzer des Client-Geräts B 720 mit Informationen über die Einladung zu versorgen (z. B. der Name der Person, die die Einladung schickt (z. B. Benutzername, realer Name, Telefonnummer, oder jede Kombination davon), wofür die Einladung ist (z. B. eine P2P-Videokonferenz, eine P2P-Instantmessaging-Sitzung, etc.), etc.).
Die Online-Kommunikationssitzungs-Einladungsanfrage wird empfangen und auf dem Client-Gerät B 720 angezeigt, falls es angeschaltet ist und korrekt betrieben wird. Die Einladungsanfrage umfasst einen Mechanismus für Nutzer, um die Einladung anzunehmen oder abzulehnen (z. B. eine Annahmeschaltfläche und eine Abweisungsschaltfläche). Der Benutzer am Client-Gerät A 710 kann eine Benachrichtigung empfangen, falls die Einladungsanfrage abgelehnt wird. Angenommen, ein Nutzer am Client-Gerät B 720 nimmt die Einladungsanfrage an, dann fordert das Client-Gerät B 720 bei Ablauf 6 seine Verbindungsdaten von dem Verbindungsdatenaustausch 610 an. Der Verbindungsdatenaustausch 610 bestimmt die Verbindungsdatei des Client-Geräts B 720 (z. B. die öffentlichen/privaten IP-Adressen und Ports, NAT-Typ des Client-Geräts B NAT-Gerät), und bei Ablauf 7 gibt er die Verbindungsdatei an das Client-Gerät B 720 zurück.
Das Client-Gerät B 720 übermittelt dann eine Annahmenachricht an den Einladungsdienst 620 bei Ablauf 8. Die Annahmenachricht umfasst die Verbindungsdaten des Client-Geräts B 720 und umfasst den Push-Token des Client-Geräts A 710. Die Annahmenachricht kann auch einen Hinweis beinhalten darüber, ob es ein Wiederholungslauf von einem zuvor fehlgeschlagenen direkten P2P-Verbindungsversuch zwischen Client-Gerät A 710 und Client-Gerät B 720 ist. Die Annahmenachricht kann die Form einer HTTPS-Nachricht annehmen.
In manchen Ausführungsformen bestimmt der Einladungsdienst 620, ob die P2P-Verbindung zwischen dem Client-Gerät A 710 und dem Client-Gerät B 720 möglich ist. Bei Ablauf 9 bestimmt der Einladungsdienst 620, ob eine direkte P2P-Verbindung zwischen den Client-Geräten A und B möglich ist. Zum Beispiel in einer Ausführungsform, wenn die Annahmenachricht, die von dem Client-Gerät B 620 empfangen wurde, andeutet, dass es ein Wiederholungslauf von einem zuvor fehlgeschlagenen direkten P2P-Verbindungsversuch ist (oder eine bestimmte Reihe von vorherigen fehlgeschlagenen direkten Verbindungsversuchen), dann kann der Einladungsdienst 620 beschließen, dass eine direkte P2P-Verbindung möglich ist. Um die Durchführbarkeit zu bestimmen, kann der Einladungsdienst 620 die NAT-Typ-Daten für die Client-Geräte A und B vergleichen, um zu bestimmen, ob die NAT-Geräte von den Client-Geräten A und B eine direkte P2P-Verbindung unterstützen werden. In einer Ausführungsform enthält die oben beschriebene Annahmenachricht keinen Hinweis auf zuvor fehlgeschlagene Versuche. Vielmehr kann jedes der Client-Geräte 710–720 immer nach einem fehlgeschlagenen direkten Verbindungsversuch eine spezielle ”Relay-Einladungs”-Anfrage übermitteln, (z. B. anstelle der Einladungsanfrage bei Ablauf 3 in 7) darauf hinweisend, dass eine Relay-Verbindung benötigt wird. Daraufhin kann der Einladungsdienst automatisch die hier beschriebenen Relay-Abläufe aktivieren (wie unten beschrieben).
Bestimmte Kombinationen von NAT-Typen sind bekanntermaßen inkompatibel für den Aufbau von P2P-Verbindungen. Zum Beispiel kann ein Vollkegel-NAT mit jedem anderen NAT-Typ außer einem geschlossenen/Firewall NAT verwendet werden, um eine direkte P2P-Verbindung aufzubauen. Im Gegensatz dazu kann eine symmetrische NAT nur mit einem Vollkegel-NAT verwendet werden, um eine direkte P2P-Verbindung aufzubauen. Die Durchführbarkeit des Kombinierens verschiedener NAT-Typen in einer Ausführungsform wird in der NAT-Kompatibilitätstabelle 1110 gezeigt in 11 fortgesetzt, in der die Spalten NAT-Typen eines Client-Geräts repräsentieren (z. B. Client-Gerät A 710) und Reihen NAT-Typen des anderen Client-Geräts repräsentieren (z. B. Client-Gerät B 720). Ein ”1.0” in einer Zelle besagt, dass die NAT-Typen in den assoziierten Reihen und Spalten kompatibel sind, und ein ”0.0” besagt, dass die NAT-Typen nicht kompatibel sind.
Falls der Einladungsdienst 620 bestimmt, dass eine direkte P2P-Verbindung durchführbar ist, dann übermittelt der Einladungsdienst 620 eine Push-Anfrage an den Push-Benachrichtigungsdienst 640, um die Annahme der Einladungsanfrage zu übermitteln. Somit übermittelt der Push-Benachrichtigungsdienst 640 bei Ablauf 10B eine Online-Kommunikationssitzungsannahmenachricht in der Form einer Push-Benachrichtigung an das Client-Gerät A 710. Die Annahmenachricht umfasst die Verbindungsdaten, die Online-Kommunikationssitzungs-Endpunktkennung, und den Push-Token des Client-Geräts B 720. Die Annahmenachricht wird auf dem Client-Gerät A 710 angezeigt, da die Client-Geräte A und B die Verbindungsdaten des anderen haben, haben die Client-Geräte A und B genügend Informationen, um eine direkte P2P-Verbindung aufzubauen. Daher bauen die Client-Geräte A und B bei Ablauf 11A eine direkte P2P-Verbindung unter Verwendung der ausgetauschten Verbindungsdaten auf. Die direkte P2P-Verbindung kann über bekannte Mechanismen aufgebaut werden (z. B. unter Verwendung von Internet Connectivity Establishment (ICE) oder anderen bekannten P2P-Verbindungsmechanismen).
Falls jedoch der Einladungsdienst 620 bestimmt, dass eine direkte P2P-Verbindung nicht durchführbar ist, übermittelt er bei Ablauf 10B eine Relay-Lookup-Anfrage an den Relay-Dienst 650, um einen oder mehrere Rosts für die Client-Geräte A und B für die Verbindung zu bestimmen. Die Relay-Suchanfrage kann die Netzwerkinformationen für die Client-Geräte A und B enthalten (z. B. NAT-Traversal-/Verbindungsdaten und/oder NAT-Typdaten), die durch den Relay-Dienst 650 verwendet wird zum Auswählen von passenden Relay-Hosts für beide der Client-Geräte.
Wie in 8 dargestellt, umfasst der Relay-Dienst 65o in einer Ausführungsform ein Relay-Suchmodul 805, einen Multiple-Relay-Host 815A–B, und eine Relay-Host-Datenbank 810, die Netzwerkinformationen, die im Zusammenhang mit jedem der Relay-Hosts 815A–B steht, enthält. Während 8 zwei Relay-Hosts darstellt, können selbstverständlich mehr oder weniger Relay-Hosts in manchen Ausführungsformen gegeben sein. Der Einladungsdienst 620 übermittelt eine Relay-Suchanfrage an das Relay-Suchmodul 805, das die Relay-Host-Datenbank 810 unter Verwendung der Netzwerkinformationen für die Client-Geräte A und B fragt. Bei Empfang der Datenbankergebnisse liefert das Relay-Suchmodul 805 eine Antwort, die die ausgewählten Relay-Hosts 815A–B bei Ablauf 11B identifiziert bei dem Einladungsdienst 620.
In einer Ausführungsform enthält die Relay-Suchantwort einen Relay-Token, der durch den Relay-Dienst 650 erzeugt wurde und die Netzwerkadresse (IP-Adressen/Ports) der ausgewählten Relay-Hosts 815A–B, die von den Client-Geräten A und B für die Relay-Verbindung zu verwenden sind. In einer Ausführungsform wird der Relay-Token mit der Relay-Sitzung verknüpft und wird durch die Relay-Hosts 815A–B verwendet, um die Client-Geräte A und B bei Verbindung mit dem Relay-Dienst 650 zu authentifizieren. Der Token kann verschiedene Formen annehmen, einschließlich zum Beispiel ein eindeutiger ID-Relay-Sitzungs-ID-Code, ein digitales Zertifikat und/oder ein eindeutiger kryptischer Schlüssel, der mit der Relay-Sitzung verknüpft ist.
Der Einladungsdienst 620 übermittelt eine Relay-Antwort an die Client-Geräte A und B und zeigt an, dass die Relay-Verbindung aufgebaut wird. In einer Ausführungsform kann die Relay-Antwort das Client-Gerät B, den Relay-Token und die Netzwerkinformation für das Relay-Host 815B beinhalten. In einer Ausführungsform kann die Antwort an das Client-Gerät B direkt gesendet werden (den Push-Benachrichtigungsdienst 640 umgehend), weil es in Antwort zur Einladungsannahmenachricht des Client-Geräts B gesendet wurde. Der Einladungsdienst 620 übermittelt auch eine Relay-Antwort an das Client-Gerät A, die den Relay-Token und die Netzwerkinformation für das Relay-Host A 815A beinhalten kann. In diesem Fall wird die Antwort zu dem Client-Gerät A über den Push-Benachrichtigungsdienst 640 gepushed.
Bei Ablauf 12B verwendet das Client-Gerät A 710 die Netzwerkinformation für Relay-Host 815A, um eine Verbindung mit dem Relay-Dienst 640 aufzubauen. In ähnlicher Weise verwendet bei Ablauf 13B das Client-Gerät B 720 die Netzwerkinformation für den Relay Host 815B, um eine Verbindung mit dem Relay-Dienst 650 aufzubauen. In jeder dieser Transaktionen werden neue Löcher in allen NAT-Firewalls der Client-Geräte A und B geöffnet und die NAT-Traversal/Verbindungsdaten für die Client-Geräte A und B können durch den Relay-Dienst 650 bestimmt werden und an die Client-Geräte A bzw. B zurückgegeben werden (z. B. durch Bestimmung der öffentlichen IP/Ports für die Geräte). In einer Ausführungsform implementieren der Relay-Dienst 650 und die Client Geräte A und B das Traversal-Using-Relay-NAT (”TURN”)-Protokoll, welches, wie dem Fachmann bekannt ist, einem Element hinter einer NAT oder Firewall erlaubt, eingehende Daten über TCP- oder UDP-Verbindungen zu empfangen.
Bei Ablauf 14B übermittelt das Client-Gerät A 710 ein Relay-Update an den Einladungsdienst 620, welches an den Push-Benachrichtigungsdienst weitergeleitet wird und bei Ablauf 17B an das Client-Gerät B 720 gepushed wird. [SFr1] Das Relay-Update, das durch das Client-Gerät A 710 übermittelt wurde, kann den Sitzungs-Token, die Online-Kommunikationssitzungs-Endpunktkennung, und die NAT-Traversal/Verbindungsdaten, die durch den Relay-Dienst 650 bestimmt wurden, enthalten.
Bei Ablauf 18B und 19B bauen die Client-Geräte A bzw. B eine Online-Kommunikations-Sitzungsverbindung über den Relay-Dienst 650 auf. In einer Ausführungsform können die Relay-Verbindungen aufgebaut werden, wenn das Client-Gerät A 710 die NAT-Traversal/Verbindungsdaten von Client-Gerät B 720 an den Relay-Dienst 650 sendet und umgekehrt, und dabei dem Relay-Dienst erlaubt, den korrekten Pfad zu dem Relay-Host 815A–B von jedem Peer zu bestimmen.
Unter Verwendung der oben beschriebenen Techniken kann der Einladungsdienst 620 als zustandsloser Service implementiert werden, der inhärent skalierbar und belastbar ist, sogar in großen Systemen mit einer großen Anzahl von Client-Geräten. Zum Beispiel, weil der Push-Benachrichtigungsdienst 640 inhärent fähig ist, Inhalte zu lokalisieren und an registrierte Client-Geräte zu pushen, braucht der Einladungsdienst 620 nicht den momentanen Standort von jedem Gerät zu tracken. Außerdem, weil Geräte NAT-Traversal/Verbindungsdaten, Anfragen und Antworten übermitteln können, braucht der Einladungsdienst 620 niemals irgendwelche pro-Verbindung-Statusinformationen zu erhalten, wodurch der Speicher und die Verarbeitungserfordernisse des Einladungsdienstes reduziert werden. Solch eine Implementierung ist insbesondere nützlich in großen Systemen.
Während 7 einen Nutzer bei einem Client-Gerät beschreibt, der einen einzelnen Nutzer zu einer Online-Kommunikationssitzung einlädt, sind die Ausführungsformen nicht auf diese Weise beschränkt. Zum Beispiel kann ein Nutzer in manchen Ausführungsformen an einem Client-Gerät eine Vielzahl von Nutzern zu einer Online-Kommunikationssitzung einladen. Zum Beispiel kann der Nutzer eine einzelne Einladungsanfragenachricht an den Einladungsdienst mit einer Vielzahl von Online-Kommunikationssitzungs-Endpunktkennungen übermitteln, um eine Vielzahl von Nutzern an verschiedenen Client-Geräten zur Teilnahme an einer Online-Kommunikationssitzung einzuladen.
In manchen Situationen kann ein Nutzer eine Vielzahl von Client-Geräten haben, die mit der gleichen Online-Kommunikationssitzungs-Endpunktkennung verknüpft sind. 26 ist ein Datenflussdiagramm, das beispielhafte Abläufe zur Verwaltung von Einladungen darstellt, wenn ein Nutzer eine Vielzahl von Client-Geräten hat, die mit der gleichen Online-Kommunikationssitzungs-Endpunktkennung verknüpft sind.
Das Client-Gerät A (betrieben durch den Nutzer A) 2610 übermittelt eine Anfrage für seine Verbindungsdaten von dem Verbindungsdatenaustausch 610 bei Ablauf 2632. Der Verbindungsdatenaustausch 610 gibt die Verbindungsdaten des Client-Geräts A bei Ablauf 2634 wieder zurück. Das Client-Gerät übermittelt dann eine Online-Kommunikationssitzungs-Einladungsanfrage an den Einladungsdienst 620 mit einer Nutzer-ID B, um den Nutzer B zu einer Online-Kommunikationssitzung einzuladen (z. B. eine P2P-Videokonferenz, eine P2P-Instant-Messaging-Sitzung, ein Videogespräch, etc.). Die Einladungsanfrage umfasst Verbindungsdaten von A.
Der Einladungsdienst führt bei Ablauf 2638 eine Datenverzeichnissuche auf der Grundlage von B's ID, die in der Einladungsanfragenachricht enthalten ist, durch. In diesem Beispiel gibt der Datenverzeichnis-Suchablauf ein Push-Token für das Client-Gerät B1 und ein Push-Token für das Client-Gerät B2 zurück. Somit werden die Client-Geräte B1 und B2 mit der ID von B verknüpft. Der Einladungsdienst 620 übermittelt dann eine Push-Anfragenachricht bei Ablauf 2640 an den Push-Benachrichtigungsdienst 640, um die Einladungsanfragenachricht an das Client-Gerät B1 2615 und das Client-Gerät B2 2620 zu pushen. Der Push-Benachrichtigungsdienst 640 übermittelt eine Online-Kommunikationssitzungs-Einladungsanfrage an das Client-Gerät B1 2615 bei Ablauf 2642 und an das Client-Gerät B2 2620 bei Ablauf 2644. Jede Einladungsanfragenachricht beinhaltet die Verbindungsdaten von Client-Gerät A 2610, die Online-Kommunikationssitzungs-Endpunktkennung, die von Nutzer A verwendet wird, und den Push-Token des Client-Geräts A 2610. Die Einladungsanfragen können auch Information spezifisch für die Online-Kommunikationssitzung beinhalten (z. B. der Name der Person, die die Einladung sendet (z. B. Nutzername, realer Name, Telefonnummer oder beliebige Kombination davon), wofür die Einladung ist (z. B. eine P2P-Videokonferenz, eine P2P-Instant-Messaging-Sitzung, etc.) etc.). Somit wird eine Online-Kommunikationssitzungs-Einladungsanfrage an jedes der Geräte, die mit der Online-Kommunikationssitzungs-Endpunktkennung, die in der ursprünglichen Einladungsanfrage enthalten ist, sendet.
In einer Ausführungsform übermittelt der Einladungsdienst 620 eine Statusnachricht an das einladende Client-Gerät, um darauf hinzuweisen, an welche Client-Geräte die Einladung übermittelt worden ist. Somit übermittelt der Einladungsdienst 620 bei Ablauf 2646 ein Einladungsstatus-Update an das Client-Gerät A 2610, das darauf hinweist, dass eine Online-Kommunikationssitzungs-Einladungsanfrage an das Client-Gerät B1 2615 und an das Client-Gerät B2 2620 gesendet worden ist. In einer Ausführungsform tracked das Client-Gerät A 2610, welche Client-Geräte die Einladung annehmen und hält die anderen Kleingeräte auf dem aktuellen Stand der Online-Kommunikationssitzung.
In einer Ausführungsform werden die Client-Geräte B1 2615 und das Client-Gerät B2 2620 eine Einladungsanfrage anzeigen, wenn sie angeschaltet werden und in der Lage sind, Einladungsanfragen zu empfangen. In dem Beispiel, das in 26 dargestellt ist, wird der Nutzer bei Client-Gerät B1 2615 die Einladung annehmen. Daher fordert das Client-Gerät B1 2615 bei Ablauf 2648 seine Verbindungsdaten von dem Verbindungsdatenaustausch 610 an. Der Verbindungsdatenaustausch 610 bestimmt die Verbindungsdaten des Client-Geräts B1 2615 und gibt diese bei Ablauf 2650 an das Client-Gerät B1 2615 wieder zurück.
Das Client-Gerät B1 2615 übermittelt dann eine Annahmenachricht an den Einladungsdienst 620 bei Ablauf 2652. Die Annahmenachricht beinhaltet die Verbindungsdaten des Client-Geräts B1 2615 und den Push-Token des Client-Geräts A 2610. Die Annahmenachricht kann auch einen Hinweis darauf enthalten, ob sich ein Wiederholungslauf von einem zuvor fehlgeschlagenen direkten P2P-Verbindungsversuch zwischen dem Client-Gerät A 2610 und dem Client-Gerät B1 2615 handelt. Zusätzlich kann die Annahmenachricht auch die Online-Kommunikationssitzungs-Endpunktkennungen von A und B und den Push-Token für das Client-Gerät B 2615 enthalten.
In manchen Ausführungsformen bestimmt der Einladungsdienst 620, nach dem Empfang einer Annahmenachricht zu einer Online-Kommunikationssitzung, ob eine direkte P2P-Verbindung durchführbar ist. Somit führt der Einladungsdienst 620 bei Ablauf 2654 einen direkten P2P-Kompatibilitäts-Check durch, um zu bestimmen, ob eine direkte P2P-Verbindung zwischen dem Client-Gerät A 2610 und dem Client-Gerät B1 2615 durchführbar ist, in einer ähnlichen Weise wie oben beschrieben. Falls die Client-Geräte für eine direkte P2P-Verbindung kompatibel sind, werden die Abläufe, die im Bezug auf 27 (beginnend mit Ablauf 2710) beschrieben wurden, ausgeführt. Falls die Client-Geräte nicht für eine direkte P2P-Verbindung kompatibel sind, werden die Abläufe, die im Bezug auf 28 (beginnend mit Ablauf 2810) beschrieben wurden, ausgeführt.
Mit Bezug auf 27, welche Abläufe zeigt, die durchgeführt werden, wenn eine direkte P2P-Verbindung durchführbar ist, übermittelt der Einladungsdienst 620 bei Ablauf 2710 eine Push-Anfrage an den Push-Benachrichtigungsdienst 640, um die Annahme der Einladung durch das Client-Gerät B1 2615 zu übermitteln. Bei Ablauf 2712 übermittelt der Push-Benachrichtigungsdienst 640 eine Online-Kommunikationssitzungs-Annahmenachricht in der Form einer Push-Benachrichtigung an das Client-Gerät A 2610. Diese Annahmenachricht beinhaltet die Verbindungsdaten und den Push-Token des Client-Geräts B1 2615, und die Online-Kommunikationssitzungs-Endpunktkennungen, die von dem Nutzer B benützt wird.
In einer Ausführungsform informiert das Client-Gerät A 2610, irgendwann nach dem Empfangen der Annahmenachricht, die anzeigt, dass das Client-Gerät B1 2615 die Einladung angenommen hat, das Client-Gerät A 2610 das Client-Gerät B2 2620 darüber, dass das Client-Gerät A 2620 die Einladung angenommen hat. Somit übermittelt das Client-Gerät A 2610 bei Ablauf 2714 eine Einladungs-Update-Anfrage an den Einladungsdienst, die die Online-Kommunikationssitzungs-Endpunktkennung des Nutzers B beinhaltet und zeigt an, dass das Client-Gerät B1 2615 die Einladung angenommen hat. Die Einladungs-Update-Anfrage kann auch den Einladungsdienst 620 anweisen oder darauf hinweisen, welches Client-Gerät, dass mit der Online-Kommunikationssitzungs-Endpunktkennung von Nutzer B verknüpft ist, die Einladungs-Update-Nachricht empfangen soll (in diesem Beispiel sollte das Client-Gerät B2 2620 die Einladungs-Update-Nachricht empfangen).
Der Einladungsdienst 620 führt eine Datenverzeichnissuche 2716 basierend auf der Online-Kommunikationssitzungs-Endpunktkennung von Nutzer B durch, um den Push-Token des Client-Geräts B2 2620 zu bestimmen. Nach der Bestimmung des Push-Tokens übermittelt der Einladungsdienst eine Push-Anfrage bei Ablauf 2720 an den Push-Benachrichtigungsdienst 640, um die Einladungs-Update-Nachricht an das Client-Gerät B2 2620 zu pushen. Bei Ablauf 2720 übermittelt der Push-Benachrichtigungsdienst 640 eine Einladungs-Update-Nachricht in Form einer Push-Benachrichtigungs-Nachricht an das Client-Gerät B2 2620. Die Einladungs-Update-Nachricht zeigt an, dass das Client-Gerät B1 2615 die Online-Kommunikationssitzungs-Einladung angenommen hat. Das Client-Gerät B2 2620 kann die Einladungs-Update-Nachricht anzeigen und kann den Status der Online-Kommunikationssitzung zwischen dem Client-Gerät A 2610 und dem Client-Gerät B1 2615 aufrecht erhalten (z. B. Dauer der Online-Kommunikationssitzung, etc.). Wie im Bezug auf 30 genauer beschrieben wird, kann in einer Ausführungsform das Client-Gerät B2 2620 eine Transferanfrage übermitteln, um zu veranlassen, dass die Online-Kommunikationssitzung von den dem Client-Gerät B1 2615 an das Client-Gerät B2 2620 übermittelt wird.
Irgendwann nach dem Empfangen der Einladungs-Annahmenachricht in Ablauf 2712 bauen das Client-Gerät A 2610 und das Client-Gerät B1 2615 eine direkte P2P-Verbindung unter Verwendung der ausgetauschten Verbindungsdaten bei Ablauf 2722 auf. Die direkte P2P-Verbindung kann über bekannte Mechanismen aufgebaut werden (z. B. unter Verwendung von Internet Connectivity Establishment (ICE) oder anderen bekannten P2P-Verbindungsmechanismen). Es ist verständlich, dass der Ablauf 2722 vor oder während der Abläufe 2714–2720 ausgeführt werden kann.
Während 26 ein Beispiel beschreibt, in dem nur ein einzelnes Client-Gerät die Einladungsnachricht annimmt, können in vielen Situationen eine Vielzahl von Client-Geräten eine Einladung zu einer Online-Kommunikationssitzung, die an einen einzelnen Nutzer gerichtet ist, annehmen. Zum Beispiel können das Client-Gerät B1 2615 und das Client-Gerät B2 2620 die Einladung in manchen Situationen annehmen. In einer Ausführungsform baut das Client-Gerät A 2610 eine Online-Kommunikationssitzung mit dem ersten Client-Gerät mit dem ersten Client-Gerät, von dem es eine Annahmenachricht empfängt, auf. Das Client-Gerät A 2610 kann veranlassen, dass eine Cancel-Nachricht an die anderen Client-Geräte gesendet wird (z. B. kann die Cancel-Nachricht an den Einladungsdienst übermittelt werden und dann über den Push-Benachrichtigungsdienst an jene anderen Client-Geräte gepushed werden).
Bezugnehmend auf Ablauf 2654 von 26, falls eine direkte P2P-Verbindung zwischen Client-Gerät A 2610 und Client-Gerät B1 2615 nicht durchführbar ist, werden die Abläufe, die in 28 beschrieben sind, durchgeführt. 28 ist ein Datenflussdiagramm, das beispielhafte Abläufe anzeigt, die durchgeführt werden, wenn eine direkte P2P-Verbindung nicht durchführbar ist. Bei Ablauf 2810 übermittelt der Einladungsdienst 620 eine Relay-Suchanfrage 2810 an den Relay-Dienst 650, um einen Relay-Host, der von dem Client-Gerät A 2610 und dem Client-Gerät B1 2615 verwendet wird, zu bestimmen. Die Relay-Suchanfrage kann Netzwerkinformationen für die Client-Geräte enthalten (z. B. NAT-Traversal/Verbindungsdaten und/oder NAT-Typdaten), welche von dem Relay-Dienst 650 zum Auswählen von geeigneten Relay-Hosts für die Client-Geräte verwendet werden. Wie in 8 dargestellt, enthält eine Ausführungsform von dem Relay-Dienst 650 eine Vielzahl von Relay-Hosts 815A–B und eine Relay-Host-Datenbank 810, die Netzwerkinformationen, die sich auf die jede der Relay-Hosts beziehen, enthält. Zum Beispiel übermittelt der Einladungsdienst 620 eine Relay-Suchanfrage an den Relay-Dienst 650, welche die Relay-Host-Datenbank 810 unter Verwendung der Netzwerkinformation für die Client-Geräte abfragt. Bei Empfang der Datenbank-Suchergebnisse liefert der Relay-Dienst 650 eine Relay-Suchantwort bei Ablauf 1201, die die ausgewählten Relay-Hosts 815A–B identifiziert. In einer Ausführungsform enthält die Relay-Suchantwort einen Relay-Token, der durch den Relay-Dienst 650 erzeugt wurde, und die Netzwerk-Adressen (IP-Adressen/Ports) der Relay-Hosts 815A–B, die von den Client-Geräten für die Relay-Verbindung zu verwenden sind. In einer Ausführungsform wird der Relay-Token mit der Relay-Sitzung verknüpft und wird durch die Relay-Hosts 815A–B für die Authentifizierung des Client-Geräts A 2610 und des Client-Geräts B1 2615 bei der Verbindung mit dem Relay-Dienst 650 verwendet. Der Token kann verschiedene Formen annehmen, einschließlich beispielsweise eindeutiger ID-Relay-Sitzungs-ID-Code, ein digitales Zertifikat und/oder einen eindeutigen kryptischen Schlüssel, der mit der Relay-Sitzung verknüpft ist.
Der Einladungsdienst 620 übermittelt dann eine Relay-Antwort an das Client-Gerät B1 2615 bei Ablauf 2814, die einen Hinweis darauf enthält, dass die Relay-Verbindung aufgebaut wird. In einer Ausführungsform kann die Relay-Antwort den Relay-Token und die Netzwerkinformation für den Relay-Host, der für das Client-Gerät B1 2615 ausgewählt wurde, enthalten. In einer Ausführungsform kann die Relay-Antwort direkt an das Client-Gerät B1 2615 gesendet werden (dabei den Push-Benachrichtigungsdienst 640 umgehend). Der Einladungsdienst 620 übermittelt auch eine Relay-Antwort an das Client-Gerät A 2610 bei Ablauf 2816, die den Relay-Token und die Netzwerkinformation für den Relay-Host, der für das Client-Gerät A 2610 ausgewählt wurde, enthält. In manchen Ausführungsformen wird die Relay-Antwort an ein mobiles Gerät A über den Push-Benachrichtigungsdienst 640 gepushed.
Bei Ablauf 2818 kann das Client-Gerät A 2610 dann eine Einladungs-Update-Anfrage an den Einladungsdienst 620 übermitteln, die die Online-Kommunikationssitzungs-Endpunktkennung des Nutzers B enthält und anzeigt, dass Client-Gerät B1 2615 die Einladung angenommen hat. Die Einladungs-Update-Anfrage kann auch den Einladungsdienst 620 anweisen oder darauf hinweisen, welches Client-Gerät, das mit der Online-Kommunikationssitzungs-Endpunktkennung von Nutzer B verknüpft ist, die Einladungs-Update-Nachricht empfangen soll (in diesem Beispiel soll das Client-Gerät B2 2620 die Einladungs-Update-Nachricht empfangen).
Der Einladungsdienst 620 führt eine Datenverzeichnissuche 2820 basierend auf der Online-Kommunikationssitzungs-Endpunktkennung des Nutzers B durch, um den Push-Token des Client-Geräts B2 2620 zu bestimmen. Nach der Bestimmung des Push-Tokens übermittelt der Einladungsdienst eine Push-Anfrage bei Ablauf 2822 an den Push-Benachrichtigungsdienst 640, um die Einladungs-Update-Nachricht an das Client-Gerät B2 2620 zu pushen. Bei Ablauf 2824 übermittelt der Push-Benachrichtigungsdienst 640 eine Einladungs-Update-Nachricht in Form einer Push-Benachrichtigungs-Nachricht an das Client-Gerät B2 2620. Die Einladungs-Update-Nachricht zeigt an, dass das Client-Gerät B1 2615 die Online-Kommunikationssitzungs-Einladung angenommen hat. Das Client-Gerät B2 2620 kann die Einladungs-Update-Nachricht anzeigen und kann den Status der Online-Kommunikationssitzung zwischen dem Client-Gerät A 2610 und dem Client-Gerät B1 2615 aufrecht erhalten (z. B. die Dauer der Online-Kommunikationssitzung, etc.). In einer Ausführungsform kann das Client-Gerät B2 2620 eine Transferanfrage übermitteln, um zu veranlassen, dass die Online-Kommunikationssitzung von dem Client-Gerät B1 2615 an das Client-Gerät B2 2620 transferiert wird.
Bei Ablauf 2826 verwendet das Client-Gerät A 2610 die Netzwerkinformation für seinen ausgewählten Relay-Host, um eine Verbindung mit dem Relay-Dienst 650 aufzubauen. In ähnlicher Weise verwendet das Client-Gerät B1 2620 bei Ablauf 2828 die Netzwerkinformation für seinen ausgewählten Relay-Host, um eine Verbindung mit dem Relay-Dienst 650 aufzubauen. In jedem dieser Abläufe können neue Löcher in jeder NAT-Firewall der Client-Geräte eröffnet werden und die NAT-Traversal/Verbindungsdaten für Client-Geräte können durch den Relay-Dienst 650 bestimmt werden und an diese zurückgegeben werden (z. B. durch Bestimmung der öffentlichen IP/Port der Client-Geräte). In einer Ausführungsform implementieren der Relay-Dienst 650 und das Client-Gerät A 2610 und das Client-Gerät B1 2615 das Traversal-Using-Relay-NAT(”TURN”)-Protokoll, welches, wie dem Fachmann bekannt, einem Element der NAT oder Firewall erlaubt, eingehende Daten über TCP- oder UDP-Verbindungen zu empfangen.
Bei Ablauf 2830 übermittelt das Client-Gerät A 2610 ein Relay-Update an den Einladungsdienst 620, welches an den Push-Benachrichtigungsdienst bei Ablauf 2832 weitergeleitet wird und an das Client-Gerät B1 2615 bei Ablauf 2834 gepushed wird. In ähnlicher Weise übermittelt das Client-Gerät B1 2615 bei Ablauf 2836 ein Relay-Update an den Einladungsdienst 620, welches an den Push-Benachrichtigungsdienst 640 bei Ablauf 2838 weitergeleitet wird und an das Client-Gerät A 2610 bei Ablauf 2840 gepushed wird. Die Relay-Update-Nachricht, die durch das Client-Gerät A 2610 übermittelt wird, kann Relay-Token, jede Online-Kommunikationssitzungs-Kennung und die NAT-Traversal/Verbindungsdaten, die durch den Relay-Dienst 650 bei Ablauf 2826 und 2828 bestimmt wurden, enthalten. In einer Ausführungsform werden die Relay-Update-Abläufe durchgeführt, sobald eine oder mehrere NAT-Informationen der Client-Geräte sich geändert haben könnten. Schließlich bauen das Client-Gerät A 2610 bzw. das Client-Gerät B1 2620 in den Abläufen 2842 und 2844 eine P2P-Verbindung über den Relay-Dienst 650 auf. In einer Ausführungsform können die Relay-Verbindungen aufgebaut werden in Antwort darauf, dass das Client-Gerät A 2610 die NAT-Traversal/Verbindungsdaten des Client-Geräts B1 2615 an den Relay-Dienst 650 übermittelt, und umgekehrt, dadurch dem Relay-Dienst 650 ermöglichend, den richtigen Pfad zu dem Relay-Host von jedem Peer zu bestimmen.
29 ist ein Datenflussdiagramm, das beispielhafte Abläufe darstellt, die durchgeführt werden, wenn eine Online-Kommunikationssitzung gemäß einer Ausführungsform endet. Bei Ablauf 2910 hat die Online-Kommunikationssitzung zwischen dem Client-Gerät A 2610 und dem Client-Gerät B1 2615 geendet. Zum Beispiel hat entweder das Client-Gerät A 2610 oder das Client-Gerät B1 2615 die Online-Kommunikationssitzung beendet (oder die Online-Kommunikationssitzung wurde anderweitig beendet). Die Online-Kommunikationssitzung kann über eine direkte P2P-Verbindung oder ein Relay stattgefunden haben.
Irgendwann nachdem die Online-Kommunikationssitzung beendet ist, übermittelt das Client-Gerät A 2610 bei Ablauf 2912 eine Online-Kommunikationssitzungs-Update-Anfrage an den Einladungsdienst 620. Das Online-Kommunikationssitzungs-Update wird gesendet, um das Client-Gerät B2 2620, das nicht Teil der Online-Kommunikationssitzung war, über die Beendigung der Online-Kommunikationssitzung zu benachrichtigen. Die Online-Kommunikationssitzungs-Update-Anfrage kann die Online-Kommunikationssitzungskennung von B beinhalten und kann den Einladungsdienst 620 anweisen oder darauf hinweisen, welches Client-Gerät, das mit dem Nutzer B (z. B. dem Client-Gerät B2 2620) verknüpft ist, das Update empfangen soll.
Der Einladungsdienst 620 führt einen Datenverzeichnissuchablauf 2914 basierend auf der Online-Kommunikationssitzungsendpunktkennung des Nutzers B durch, um den Push Token des Client-Geräts B2 2620 zu bestimmen. Nach der Bestimmung des Push Tokens übermittelt der Einladungsdienst eine Push-Anfrage bei Ablauf 2916 an den Push-Benachrichtigungsdienst 640, um die Update-Nachricht an das Client-Gerät B2 2620 zu pushen. Bei Ablauf 2720 übermittelt ein Push-Benachrichtigungsdienst 640 eine Online-Kommunikationssitzungs-Update-Nachricht in Form einer Push-Benachrichtigungsnachricht an das Client-Gerät B2 2620. Die Online-Kommunikationssitzungs-Update-Nachricht weist darauf hin, dass die Online-Kommunikationssitzung zwischen dem Client-Gerät A 2910 und dem Client-Gerät B1 2615 beendet ist.
30 ist ein Flussdiagramm, das beispielhafte Abläufe darstellt, die durchgeführt werden, um eine Online-Kommunikationssitzung von einem Client-Gerät zu einem anderen Client-Gerät gemäß einer Ausführungsform zu transferieren. In dem Beispiel, das in 30 dargestellt ist, wird angenommen, dass jedes der Client-Geräte B1 2615 und B2 2620 eine Einladung zu einer Online-Kommunikationssitzung empfangen hat, die durch das Client-Gerät A 2610 erzeugt wurde (jedes von ihnen teilt die Online-Kommunikationssitzungsendpunktkennung, die in der Einladung verwendet wurde) und das Client-Gerät B1 2615 hat eine Online-Kommunikationssitzung mit dem Client-Gerät A 2610 angenommen und aufgebaut (wie in den 26 und 27 oder 28 beschrieben). Zusätzlich hat das Client-Gerät B2 2620 ein Einladungs-Update empfangen, das anzeigt, dass das Client-Gerät B1 2615 die Einladung angenommen hat. In dem Beispiel, das in 30 dargestellt ist, wird die Online-Kommunikationssitzung von dem Client-Gerät B1 2615 an das Client-Gerät B2 2620 transferiert. Zum Beispiel hat der Nutzer am Client-Gerät B2 2620 darauf hingewiesen, dass es die Online-Kommunikationssitzung zwischen den Client-Geräten A 2610 und dem Client-Gerät B1 2620 übernehmen möchte. In einer Ausführungsform zeigt die Online-Kommunikationssitzungsanwendung 2115 einen Status der Online-Kommunikationssitzung zwischen dem Client-Gerät A 2610 und dem Client-Gerät B1 2615 an, das dem Nutzer bei dem Client-Gerät B2 2620 erlaubt, eine Transfer-Online-Kommunikationssitzungsanfrage auszustellen (z. B. über ein Klicken oder Drücken eines Links oder einer virtuellen Schaltfläche, die auf der Online-Kommunikationssitzungsanwendung 2115 des Client-Geräts B1 2615 zur Verfügung steht).
Bei Ablauf 3010 fordert das Client-Gerät B2 2620 seine Verbindungsdaten von dem Verbindungsdatenaustausch 610 an und empfängt die angeforderten Verbindungsdaten bei Ablauf 3012 (wenn es nicht schon seine Verbindungsdaten kennt). Das Client-Gerät B2 2620 übermittelt dann eine Transferanfragenachricht bei Ablauf 3014 an den Einladungsdienst 620, das den Push-Token des Client-Gerät A 2610 und die Verbindungsdaten des Client-Gerät B2 2620 beinhaltet. Die Transferanfragenachricht kann auch die Online-Kommunikationssitzungs-Endpunktkennungen von A und/oder B und/oder dem Push-Token für das Client-Gerät A 2610 beinhalten.
Der Einladungsdienst 620 übermittelt dann eine Push-Anfrage an den Push-Benachrichtungsdienst 640 bei Ablauf 3016, um den Push-Benachrichtungsdienst 640 dazu zu veranlassen, die Transfer-Nachricht in Form einer Push-Benachrichtigung an das Client-Gerät A 2610 zu übermitteln. Der Einladungsdienst 620 führt auch einen P2P-Kompatabilitätscheck bei Ablauf 3018 durch, um zu bestimmen, ob eine direkte P2P-Verbindung zwischen dem Client-Gerät A 2610 und dem Client-Gerät B2 2620 durchführbar ist. Zum Zwecke dieses Beispiels ist eine direkte Verbindung durchführbar, es versteht sich jedoch, dass ein Online-Kommunikationssitzungstransfer auch in einer Relay-Situation stattfinden kann.
Bei Ablauf 3020 übermittelt der Push-Benachrichtungsdienst die Transferanfragenachricht an das Client-Gerät A 2610. Die Transfer-Anfragenachricht nach die Online-Kommunikationssitzungsendpunktkennung von B und die Verbindungsdaten für das Client-Gerät B2 2620 beinhalten. Die Transfer-Anfragenachricht weist auch darauf hin, welches Gerät (d. h. das Client-Gerät B2 2620), das den Online-Kommunikationssitzungstransfer anfordert (z. B. über eine Geräte-ID und/oder Push-Token des Client-Gerät B2 2620). Die Transferanfragenachricht kann die Online-Kommunikationssitzungsanwendung 2115 des Client-Gerät A 2610 dazu veranlassen, die Transferanfrage anzuzeigen, und kann dem Nutzer erlauben, die Transferanfrage anzunehmen oder zu verweigern. Unter der Annahme, dass die Transferanfrage angenommen wird, baut das Client-Gerät A 2610 eine direkte P2P-Verbindung mit dem Client-Gerät B 2620 unter Verwendung der ausgetauschten Verbindungsdaten bei Ablauf 3022 auf. Es versteht sich, dass an diesem Punkt die Online-Kommunikationssitzung zwischen dem Client-Gerät A 2610 und dem Client-Gerät B1 2615 aktiv ist. Das Client-Gerät A 2610 übermittelt dann ein Online-Kommunikationssitzungs-Update an das Client-Gerät B1 2615, das anzeigt, das die Online-Kommunikationssitzung an das Client-Gerät B2 2620 transferiert wird. In einer Ausführungsform wird diese Update-Nachricht auf die existierende Online-Kommunikationssitzung zwischen den Client-Geräten übermittelt. Das Client-Gerät A 2610 wechselt dann zu der Online-Kommunikationssitzung mit dem Client-Gerät B2 2620 bei Ablauf 3026 und bricht die Online-Kommunikationssitzung mit dem Client-Gerät B1 2615 bei Ablauf 3028 ab.
Während Ausführungsformen im Zusammenhang mit dem Einladen eines einzelnen Nutzers zu einer Online-Kommunikationssitzung (welche mit einer Vielzahl von Client-Geräten verknüpft sein kann oder auch nicht) beschrieben worden sind, kann in manchen Ausführungsformen eine Vielzahl von Nutzern zu einer Online-Kommunikationssitzung eingeladen werden. 31 ist ein Flussdiagramm, das beispielhafte Abläufe zur Initiierung und Aufbau einer Online-Kommunikationssitzung mit einer Vielzahl von Nutzern darstellt.
Das Client-Gerät 3110 fordert seine Verbindungsdaten von dem Verbindungsdatenaustausch 610 bei Ablauf 3132 an und die angeforderten Verbindungsdaten werden bei Ablauf 3134 wieder zurückgegeben. Bei Ablauf 3136 übermittelt das Client-Gerät A 3110 eine Einladungsanfrage an den Einladungsdienst 620, die die Verbindungsdaten des Client-Geräts A 3110 einer Online-Kommunikationssitzungsendpunktkennung, die mit dem Nutzer B verknüpft ist und eine Online-Kommunikationssitzungsendpunktkennung, die mit dem Nutzer C verknüpft ist, beinhaltet. Somit lädt der Nutzer am Client-Gerät A 3110 eine Vielzahl von Nutzern zu einer Online-Kommunikationssitzung ein.
Der Einladungsdienst 620 führt einen Datenverzeichnissuchablauf 3138 durch, um die Push-Tokens, die mit der Online-Kommunikationssitzungsendpunktkennung des Nutzers B und der Online-Kommunikationssitzungsendpunktkennung des Nutzers C zu verknüpfen. In diesem Beispiel und zur Vereinfachung gibt die Datenverzeichnissuche ein Ergebnis des Client-Gerät B 3115, das mit der Online-Kommunikationssitzungsendpunktkennung des Nutzers B verknüpft und des Client-Gerät C 3120, das mit der Online-Kommunikationssitzungsendpunktkennung des Nutzers C verknüpft ist, zurück. Der Einladungsdienst 620 übermittelt dann eine Push-Anfrage 3140 an den Push-Benachrichtigungsdienst 640, um anzufordern, das Push-Benachrichtigungsdienst 640 Einladungen in Form einer Push-Nachricht an die Client-Geräte B und C übermittelt. Der Push-Benachrichtigungsdienst 640 übermittelt dann die Einladungsanfrage an das Client-Gerät B 3115 bei Ablauf 3142 und übermittelt die Einladungsanfrage an das Client-Gerät C 3120 bei Ablauf 3144. Jede Einladungsanfragenachricht beinhaltet die Verbindungsdaten des Client-Geräts A 3110, die Online-Kommunikationssitzungsendpunktkennung, die von dem Nutzer A verwendet wird, und den Push-Token des Client-Geräts A 3110.
In einer Ausführungsform übermittelt der Einladungsdienst 620 eine Statusnachricht an das einladende Client-Gerät, um anzuzeigen an welche Client-Geräte die Einladung übermittelt worden ist. Somit übermittelt der Einladungsdienst 620 bei Ablauf 3146 ein Einladungsstatus-Update an das Client-Gerät A 3110, das anzeigt, das eine Online-Kommunikationssitzungseinladungsanfrage an das Client-Gerät B 3115 und an das Client-Gerät C 3120 gesendet wurde. In einer Ausführungsform werden die Client-Geräte B 3115 und das Client-Gerät C 3120 eine Einladungsanfrage anzeigen, wenn sie angeschaltet werden und in der Lage sind, Einladungsanfragen zu empfangen.
In dem Beispiel, das in 31 dargestellt ist, werden alle Einladungen angenommen. Somit fordert das Client-Gerät B 3115 bei Ablauf 3148 seine Verbindungsdaten von dem Verbindungsdatenaustausch 610 an. Der Verbindungsdatenaustausch 610 bestimmt die Verbindungsdaten des Client-Geräts B 3115 und gibt sie bei Ablauf 3115 an das Client-Gerät B 3115. In ähnlicher Weise fordert das Client-Gerät C 3120 seine Verbindungsdaten von dem Verbindungsdatenaustausch 610 bei Ablauf 3152 an. Der Verbindungsdatenaustausch 610 bestimmt die Verbindungsdaten des Client-Geräts C 3120 und gibt sie Ablauf 3154 wieder an das Client-Gerät C 3120 zurück. Das Client-Gerät B 3115 übermittelt dann eine Annahmenachricht an den Einladungsdienst 620 bei Ablauf 3156 und das Client-Gerät C 3120 übermittelt eine Annahmenachricht an den Einladungsdienst bei Ablauf 3158. Der Einladungsdienst 620 führt dann einen direkten P2P-Kompatibilitätscheck 3160 durch, um zu bestimmen, ob eine direkte P2P-Verbindung zwischen dem Client-Gerät A 3110 und dem Client-Gerät B 3115, und dem Client-Gerät A 3110 und dem Client-Gerät C 3120 durchführbar ist. Zum Zwecke dieses Beispiels ist eine direkte P2P-Verbindung zwischen den Client-Geräten durchführbar. Somit bauen das Client-Gerät A 3110 und das Client-Gerät B 3115 unter Verwendung der ausgetauschten Verbindungsdaten eine direkte P2P-Verbindung für die Online-Kommunikationssitzung bei Ablauf 3162 auf, und das Client-Gerät A 3110 und das Client-Gerät B 3120 bauen eine direkte P2P-Verbindung für die Online-Kommunikationssitzung bei Ablauf 3164 auf. In diesem Beispiel fungiert das Client-Gerät A 3110 im Wesentlichen als Host der Online-Kommunikationssitzung. Somit werden Daten, die zwischen dem Client-Gerät B 3115 und dem Client-Gerät C 3120 übermittelt wurden, durch das Client-Gerät A 3110 weiterleitet. In anderen Ausführungsformen wird ein vollständiges Netzwerk von Verbindungen zwischen den Parteien aufgebaut. In solchen Ausführungsformen würde eine weitere P2P-Verbindung zwischen dem Client-Gerät B 3115 und dem Client-Gerät C 3120 aufgebaut.
Während die hier beschriebenen Ausführungsformen einen Mechanismus zum Registrieren von Client-Geräten für Online-Kommunikationssitzungen beschreiben, kann in manchen Ausführungsformen die Registrierung 140 eine API implementieren, um es verschiedenen Anwendungen zu ermöglichen, Online-Kommunikationssitzungsendpunktkennungen und Push-Tokens zu registrieren. Die API, die in einer Ausführungsform implementiert ist, ist eine Schnittstelle, die durch eine Softwarekomponente implementiert ist (hiernach ”API-implementierende Softwarekomponente), die es verschiedenen Softwarekomponenten (hiernach ”API-aufrufende Softwarekomponente”) erlaubt, eine oder mehrere Funktionen, Verfahren, Prozeduren, Datenstrukturen, und/oder andere Dienste, die durch die API-implementierende Softwarekomponente zur Verfügung gestellt werden, zuzugreifen und diese zu nutzen. Zum Beispiel ermöglicht eine API einem Entwickler, eine API-aufrufende Softwarekomponente (die ein dritter Entwickler sein kann), spezifische Merkmale, die durch die API-implementierende Softwarekomponente zur Verfügung gestellt werden, wirksam einzusetzen. Es kann eine API-aufrufende Softwarekomponente existieren oder es können auch mehr als eine solche Softwarekomponente existieren. Eine API kann eine Quellcodeschnittstelle sein, die ein Computersystem oder eine Programmbibliothek zur Verfügung stellt, um Anfragen für Dienste von einer Softwareanwendung zu unterstützen. Eine API kann durch Begriffe einer Programmiersprache angegeben werden, die ausgelegt oder erarbeitet werden kann, wenn die Anwendung aufgebaut wird, vielmehr als eine ausdrückliche Niedriglevelbeschreibung davon, wie die Daten im Speicher aufgebaut sind.
Die API definiert die Sprache und die Parameter, die die API-aufrufenden Softwarekomponenten verwenden, wenn sie auf spezifizierte Merkmale einer API-implementierenden Softwarekomponente zugreifen und verwenden. Zum Beispiel greift eine API-aufrufende Softwarekomponente die spezifischen Merkmale einer API-implementierenden Softwarekomponente über ein oder mehrere API-Aufrufe zu (manchmal als Funktion oder Verfahrensaufrufe bezeichnet), freigelegt durch die API. Die API-implementierende Softwarekomponente kann einen Wert über die API-Antwort auf einen API-Anruf von einer API-aufrufenden Softwarekomponente zurückgeben. Während die API die Syntax und das Ergebnis eines API-Anrufs definiert (z. B. wie ein API-Anruf aufzurufen ist und was der API-Anruf macht), lässt die API typischerweise nicht erkennen, wie der API-Anruf die Funktion, die durch den API-Anruf spezifiziert wird, ausführt. Verschiedene Funktionsanrufe oder Nachrichten werden über die eine oder mehrere anwendungsprogrammierenden Schnittstellen zwischen der anrufenden Software (API-aufrufende Softwarekomponente) und einer API-implementierenden Softwarekomponente transferiert. Das Transferieren der Funktionsanrufe oder Nachrichten kann Ausstellen, Initiieren, Aufrufen, Anrufen, Empfangen, Zurückgeben oder Antworten auf Funktionsanrufe oder Nachrichten beinhalten. Daher kann eine API-aufrufende Softwarekomponente einen Anruf transferieren und eine API-implementierende Softwarekomponente kann einen Anruf transferieren.
Beispielsweise können die API-implementierende Softwarekomponente und die API-aufrufende Softwarekomponente ein Betriebssystem, eine Bibliothek, ein Gerätetreiber, ein API, ein Anwendungsprogramm oder andere Softwaremodule sein (es sollte klargestellt werden, dass die API-implementierende Softwarekomponente und die API-aufrufende Softwarekomponente gleich oder voneinander unterschiedliche Softwaremodule sein können). Die API-aufrufende Softwarekomponente kann eine lokale Softwarekomponente sein (d. h. auf dem gleichen Daten verarbeitenden System wie die API-implementierende Softwarekomponente) oder eine entfernte Softwarekomponente sein (d. h. auf einem anderen Daten verarbeitenden System als die API-implementierende Softwarekomponente), die mit der API-implementierenden Softwarekomponente durch die API über ein Netzwerk kommuniziert. Es soll klargestellt werden, dass eine API-implementierende Softwarekomponente auch als eine API-aufrufende Softwarekomponente agieren kann (d. h. es könnte API-Anrufe und ein API durchführen, die durch eine andere API-implementierende Softwarekomponente ausgestellt wird) und eine API-aufrufende Softwarekomponente könnte auch als eine API-implementierende Softwarekomponente agieren, indem sie eine API implementiert, die einer anderen API-aufrufenden Softwarekomponente ausgesetzt ist.
Die API könnte eine Vielzahl von API-aufrufenden Softwarekomponenten, die in verschiedenen Programmiersprachen geschrieben wurden, ermöglichen, mit der API-implementierenden Softwarekomponente zu kommunizieren (somit könnte die API Merkmale zur Übersetzung von Anrufen und Antworten zwischen der API-implementierenden Softwarekomponente und der API-aufrufenden Softwarekomponente enthalten); ebenfalls könnte die API in Begriffen einer spezifischen Programmiersprache implementiert werden.
9 stellt eine Ausführungsform einer API-Architektur dar, welche eine API-implementierenden Softwarekomponente 910 enthält (z. B. Betriebssystem, eine Bibliothek, einen Gerätetreiber, eine API, ein Anwendungsprogramm oder andere Softwaremodule), die die API 920 implementiert. Die API 920 spezifiziert eine oder mehrere Funktionen, Verfahren, Klassen, Objekte, Protokolle, Datenstrukturen, Formate und/oder andere Merkmale der API-implementierenden Softwarekomponente, die durch die API-aufrufenden Softwarekomponente 930 verwendet werden könnte. Die API 920 kann mindestens eine Anrufkonvention spezifizieren, die spezifiziert, wie eine Funktion in der API-implementierenden Softwarekomponente Parameter von der API-aufrufenden Softwarekomponente empfängt und wie die Funktion ein Ergebnis an die API-aufrufende Softwarekomponente zurückgibt. Die API-aufrufende Softwarekomponente 930 (z. B. ein Betriebssystem, eine Bibliothek, ein Gerätetreiber, eine API, ein Anwendungsprogramm oder andere Softwaremodule) macht API-Anrufe durch die API 920, um auf die Merkmale der API-implementierenden Softwarekomponente 910, die durch die API 920 spezifiziert werden, zuzugreifen oder zu verwenden. Die API-implementierenden Softwarekomponente 910 könnte einen Wert durch die API 920 an die API-aufrufende Softwarekomponente 930 als Antwort auf einen API-Anruf zurückgeben.
Es lässt sich leicht nachvollziehen, dass die API-implementierenden Softwarekomponente 910 zusätzliche Funktionen, Verfahren, Klassen, Datenstrukturen, und/oder andere Merkmale, die nicht durch die API 920 spezifiziert sind und nicht für die API-aufrufende Softwarekomponente 930 verfügbar sind, enthalten könnte. Es versteht sich, dass die API-aufrufende Softwarekomponente 930 auf dem gleichen System wie die API-implementierende Softwarekomponente 910 sein könnte oder entfernt liegen könnte und auf die API-implementierende Softwarekomponente 910 unter Verwendung der API 920 über ein Netzwerk zugreifen könnte. Während 9 eine einzelne API-aufrufende Softwarekomponente 930 darstellt, die mit der API 920 interagiert, versteht sich, dass andere API-aufrufende Softwarekomponenten, die in verschiedenen Sprachen geschrieben worden sein können (oder der gleichen Sprache) als die API-aufrufende Softwarekomponente 930, die API 920 verwenden könnten.
Die API-implementierende Softwarekomponente 910, die API 920 und die API-aufrufende Softwarekomponente 930 könnten in einem maschinenlesbaren Medium gespeichert werden, die jeden Mechanismus zur Speicherung von Information in Form, die durch eine Maschine lesbar ist, umfasst (z. B. ein Computer oder andere Datenverarbeitungssysteme). Zum Beispiel umfasst ein maschinenlesbares Medium Magnetplatten, optische Disks, Random Access Memory, Festspeicher, Flash-Memory-Geräte, etc.
Übergang zwischen leitungsvermittelten Gesprächen und Videogesprächen
In manchen Ausführungsformen kann ein Client-Gerät von einem aufgebauten Audio-leitungsvermittelten Gespräch zu einem Videogespräch übergehen, ohne Kommunikation zwischen den Parteien signifikant zu unterbrechen. Zum Beispiel wählt eine Partei eines aufgebauten reinen Audio-leitungsvermittelten Gespräch aus, zu einem Videogespräch überzugehen (welches Videoframes und Audio beinhaltet), welches veranlasst, dass eine Videogesprächinitiierungsnachricht (eine Form von einer Online-Kommunikationssitzungseinladungsnachricht) an die anderen Teilnehmer des Gesprächs gesendet wird. Wenn die anderen Teilnehmer die Videogesprächseinladung annehmen, wird eine P2P-Verbindung zwischen den Client-Geräten der Teilnehmer aufgebaut. Während die P2P-Verbindung ausgehandelt wird, können die Teilnehmer durch das rein Audio-leitungsvermittelte Gespräch kommunizieren. Nachdem die P2P-Verbindung aufgebaut worden ist und Video zwischen den Parteien kommuniziert wird, gehen die Client-Geräte zu dem Videogespräch über. Das rein Audio-leitungsvermittelte Gespräch wird dann fallengelassen und die Teilnehmer können durch das Videogespräch kommunizieren.
12 stellt ein beispielhaftes Client-Gerät 1210 und eine grafische Benutzerschnittstelle dar, die verwendet wird, um zwischen leitungsvermittelten Gesprächen und Videogesprächen gemäß einiger Ausführungsformen wechseln. Das Client-Gerät 1220 weist einen Lautsprecher 1255 (welcher während des Lautsprechertelefonmodus verwendet wird), Frontkamera 1260 (welche Video aufnimmt, das für das Videogespräch verwendet wird), Mikrofon 1265 (welches Ton aufnimmt), Reiceiver/Speaker 1270 (welches typischerweise verwendet wird, wenn ein Benutzer das Client-Gerät 1220 während eines Gesprächs an sein Ohr hält), und den Display-Bildschirm 1275 (welcher in manchen Ausführungsformen ein Touchscreen ist), auf. Das Client-Gerät 1210 könnte auch einen Kopfhörer/Headsetjack, einen Proximity-Sensor, einen Umgebungslichtsensor, einen Beschleunigungsmesser, oder andere Komponenten aufweisen. Es versteht sich, dass die Architektur des Client-Gerätes 1220 beispielhaft ist und andere Architekturen, die mehr oder weniger Komponenten enthalten, in den Ausführungsformen verwendet werden können.
Wie in 12 dargestellt, wird die grafische Benutzerschnittstelle 1205 aktuell auf dem Display-Bildschirm 1275 angezeigt. Der Nutzer des Client-Geräts 1210 nimmt aktuell an einem reinen Audio-Telefongespräch teil (mit der Telefonnummer (408)555-1234). Die grafische Nutzerschnittstelle 1205 weist verschiedene Optionen für den Nutzer während des Gesprächs auf. Zum Beispiel führt das Client-Gerät 1210 die folgende Antwort auf ein Empfangen von Nutzereingaben aus (z. B. Tippen oder andere vorbestimmte Gesten auf einem angemessenen oder entsprechenden Icon): beendet das Gespräch, wenn eine Eingabe auf die Beende-Gespräch-Schaltfläche 1250 betätigt wird, schaltet das Audiogespräch stumm in Antwort auf eine Eingabe, die auf die Mute-Schaltfläche 1220 betätigt wurde, zeigt eine numerische Tastatur an (z. B. um zusätzliche Telefonnummern zu dem Gespräch hinzuzufügen) in Antwort auf eine Eingabe, die auf die Tastaturschaltfläche 1225 getätigt wurde, platziert das Gespräch auf ein Lautsprechertelefon als Antwort auf eine Eingabe, die auf die Lautsprecherschaltfläche 1230 getätigt wurde (welche den Audio-Output zu den Lautsprechern 1255 wechselt), fügt ein Gespräch als Antwort zu einer Eingabe zu, die auf die Gespräch-Hinzufügen-Schaltfläche 1235 getätigt wurde, platziert das Call-on-Hold als Antwort zu einer Eingabe, die die Halteschaltfläche 1240 getätigt wurde, zeigt die Kontaktliste des Nutzers an, als Antwort auf eine Eingabe, die auf die Kontakteschaltfläche 1245 getätigt wurde, und geht zu einem Videogespräch über, als Antwort auf eine Eingabe, die auf die Videogesprächsschaltfläche 1215 getätigt wurde.
17 bis 18 sind Flussdiagramme, die beispielhafte Abläufe für den Übergang zwischen rein Audio-leitungsvermittelten Gesprächen zu Videogesprächen gemäß einer Ausführungsform darstellen. 17 bis 18 werden mit Bezug zu den beispielhaften Ausführungsformen der 12, 13 und 14 beschrieben. Es versteht sich, dass die Abläufe der 17 bis 18 durch Ausführungsformen der Erfindung ausgeführt werden können, die sich von denen, die im Zusammenhang mit den 12, 13 und 14 diskutiert wurden, unterscheiden und die Ausführungsform, die im Zusammenhang mit den 12, 13 und 14 diskutiert wurden, können Abläufe durchführen, die sich von denen unterscheiden, die im Zusammenhang mit den 17 bis 18 diskutiert wurden.
Wie in 17 dargestellt werden die Client-Geräte 1210 und 1410 durch ein rein Audio-leitungsvermitteltes Gespräch 1710 verbunden (entweder der Nutzer des Client-Geräts 1210 oder der Nutzer des Client-Geräts 1410 initiiert das Gespräch). Somit können die Nutzer der Client-Geräte 1210 und 1410 über das aufgebaute leitungsvermittelte Audiogespräch kommunizieren. Bei Block 1712 empfängt das Client-Gerät 1210 eine Eingabe, um zu einem Videogespräch überzugehen. Zum Beispiel hat der Nutzer ausgewählt, zu einem Videogespräch überzugehen, indem er auf die Videogesprächsschaltfläche 1215 tippt oder eine andere definierte Geste ausführt.
Der Fluss bewegt sich dann zu Block 1714, wo das Client-Gerät 1210 veranlasst, dass eine Videogesprächseinladungsnachricht (welche eine Form einer Online-Kommunikationssitzungseinladungsanfragenachricht ist) an das Client-Gerät 1410 gesendet wird (wie durch die Telefonnummer des Client-Geräts 1410 identifiziert). In manchen Ausführungsformen wird die Online-Kommunikationssitzungseinladungsanfrage unter Verwendung der Architektur, die in den 6 und 7 beschrieben wurde, gesendet. Der Russ bewegt sich dann zu Block 1716.
Bei Block 1716 bestimmt das Client-Gerät 1210, ob das Audio aktuell durch das Lautsprechertelefon (z. B. der Lautsprecher 1255) geroutet wird oder durch den Kopfhörer/Headsetjack. Wenn das der Fall ist, bewegt sich der Fluss zu Block 1720. Wenn das nicht der Fall ist, bewegt sich der Fluss zu Block 1718, wo das Client-Gerät 1210 das Audio durch das Lautsprechertelefon des Client-Geräts 1210 (z. B. der Lautsprecher 1255) geroutet und der Fluss bewegt sich zu Block 1720.
Bei Block 1720 zeigt das Client-Gerät 1210 eine Videovorschau dessen an, was die Frontkamera 1260 aktuell aufnimmt, um es dem Nutzer des Client-Geräts 1210 zu ermöglichen, sich auf das Videogespräch vorzubereiten (z. B. um das Client-Gerät 1210 für das Videogespräch angemessen zu positionieren). 13 stellt das Client-Gerät 1210 dar, das die Videovorschau 1310 anzeigt, die ein Video dessen anzeigt, was die Frontkamera 1216 aktuell aufnimmt. Obwohl es in 13 nicht dargestellt ist, wird in manchen Ausführungsformen auch eine Cancel-Schaltfläche auf der GUI 1305 angezeigt, die es dem Nutzer ermöglicht, die Videogesprächseinladung abzubrechen. Der Fluss bewegt sich von Block 1720 zu Block 1722.
Bei Block 1726 empfängt das Client-Gerät 1410 eine Videogesprächseinladungsnachricht, die Benutzer des Client-Gerät 1410 zu einem Videogespräch einlädt. Der Fluss bewegt sich von Block 1726 zu Block 1728. In manchen Ausführungsformen hat das Client-Gerät 1410 eine Architektur, die der des Client-Geräts 1210 ähnlich ist. Zum Beispiel wie in 14 dargestellt beinhaltet das Client-Gerät 1410 die Lautsprecher 1455 (welche während des Lautsprechertelefonmodus verwendet wird), Frontkamera 1460 (welche Video aufnimmt, die für das Videogespräch verwendet wird), Mikrofon 1465 (welches Ton aufnimmt), die Receiver/Speaker 1470 (welche typischerweise verwendet wird, wenn ein Nutzer das Client-Gerät 1210 während eines Gesprächs an seinem Ohr hält), und der Display-Bildschirm 1475 (welcher in manchen Ausführungsformen ein Touchscreen ist). Das Client-Gerät 1410 könnte auch einen Kopfhörer/Headsetjack, einen Proximity-Sensor, einen Umgebungslichtsensor, einen Beschleunigungsmesser und andere Komponenten beinhalten. Es versteht sich, dass die Architektur des Client-Geräts 1410 beispielhaft ist und verschiedene Architekturen, die mehr oder weniger Komponenten aufweisen, in Ausführungsformen verwendet werden könnten.
Bei Block 1728 spielt das Client-Gerät 1410 ein oder mehrere Audiotöne, die den Empfang der Nachricht anzeigen, um den Nutzer der Nachricht zu alarmieren. Audiotöne könnten in verschiedenen Ausführungsformen unterschiedlich sein (z. B. könnten die Audiotöne ähnlich der Gesprächswartetöne sein, die auf dem Client-Gerät 1410 verwendet werden (obwohl sie nicht durch den Carrier, der mit dem Client-Gerät 1410 verknüpft ist, erzeugt wurden) die Audiotöne könnten eindeutig und spezifisch sein für Videogespräche etc.). In manchen Ausführungsformen spielt das Client-Gerät 1410 keine Audiotöne, die den Empfang der Videogesprächseinladungsnachricht anzeigen, wenn das Client-Gerät 1410 nicht in der Nähe des Ohrs des Benutzers ist (z. B. wie durch einen Proximity-Sensor des Client-Geräts 1410 angezeigt) und/oder wenn das Gespräch aktuell im Lautsprechertelefonmodus ist. Der Fluss bewegt sich von Block 1728 zu Block 1730.
Bei Block 1730 zeigt das Client-Gerät 1410 die Videogesprächseinladungsnachricht an und zeigt optional eine Videovorschau dessen an, was die Frontkamera 1460 aktuell aufnimmt, um es dem Nutzer des Client-Geräts 1410 zu ermöglichen, sich für das Videogespräch vorzubereiten und der Fluss bewegt sich zu Block 1732. 14 stellt die GUI 1405 dar, die Videogesprächseinladung 1440 anzeigt. Wie in 14 dargestellt, beinhaltet die Videogesprächseinladung 1440 eine Annahmeschaltfläche 1432, eine Ablehnungsschaltfläche 1434 und die Videovorschau 1430 (welche zeigt, was die Frontkamera 1460 aktuell aufnimmt). Obwohl Fig. 1410 die Videogesprächseinladung 1440 einschließlich der Videovorschau 1430 anzeigt (d. h. die Videovorschau 1430 ist in der Videogesprächseinladung 1440 enthalten), wird die Videovorschau 1430 in anderen Ausführungsformen außerhalb der Videogesprächseinladung 1440 angeordnet und/oder überlappt die Videogesprächseinladung 1440. Der Nutzer des Client-Geräts 1410 könnte die Annahmeschaltfläche 1432 auswählen, um jede Gesprächseinladung anzunehmen (z. B. durch Tippen oder Ausführen einer anderen vordefinierten Geste für Eingaben auf der Annahmeschaltfläche 1432) und kann die Ablehnungsschaltfläche 1434 auswählen, um die Videogesprächseinladung abzulehnen (z. B. durch Tippen oder Ausführen einer anderen vordefinierten Geste für Eingabe auf der Ablehnungsschaltfläche 1434).
Bei Block 1732 bestimmt das Client-Gerät 1410, ob eine Eingabe zur Annahme des Videogesprächs empfangen worden ist (z. B. ob der Nutzer die Videogesprächseinladung angenommen hat, indem er die Annahmeschaltfläche 1432 auswählt). Wenn das Client-Gerät 1410 keine Eingabe empfängt, um das Videogespräch anzunehmen, bewegt sich der Fluss zu Block 1734, andernfalls bewegt sich der Fluss zu Block 1736. Bei Block 1734 veranlasst das Client-Gerät 1410, dass eine Videogesprächsannahmenachricht an das Client-Gerät 1210 übermittelt wird. In manchen Ausführungsformen wird die Annahmenachricht an das Client-Gerät 1210 unter Verwendung der Architektur, die in den 6 und 7 beschrieben wurde, übermittelt. Der Fluss bewegt sich zu Block 1810.
Bei Block 1736 wird bestimmt, ob eine Eingabe zur Verweigerung der Videogesprächsanfrage empfangen worden ist (z. B. ob der Nutzer die Videogesprächseinladung durch Auswahl der Ablehnungsschaltfläche 1434 das Videogespräch verweigert hat). Wenn das Client-Gerät eine Eingabe zur Ablehnung der Videogesprächseinladung empfängt, bewegt sich der Fluss zu Block 1738, andernfalls bewegt sich der Fluss zurück zu Block 1732. Bei Block 1738 veranlasst das Client-Gerät 1410, dass eine Videogesprächsablehnungsnachricht an das Client-Gerät 1210 übermittelt wird. Das Client-Gerät 1410 könnte auch die Videogesprächseinladung 1440 räumen und aufhören, die Videovorschau 1430 anzuzeigen. In manchen Ausführungsformen wird die Videogesprächsablehnungsnachricht an das Client-Gerät 1210 unter Verwendung der Architektur, die in den 6 und 7 beschrieben wurde, übermittelt.
Bei Block 1722 bestimmt das Client-Gerät 1210, ob es eine Videogesprächsannahmenachricht von dem Client-Gerät 1410 empfangen hat. Wenn dies der Fall ist, bewegt sich der muss zu Block 1816, andernfalls bewegt sich der Fluss zu Block 1724, wo das Client-Gerät 1210 bestimmt, ob es eine Videogesprächsablehnungsnachricht von dem Client-Gerät 1410 empfangen hat. Wenn dies der Fall ist, bewegt sich der Fluss zu Block 1910, andernfalls bewegt sich der muss zu Block 1722.
Im Zusammenhang mit 18 bestimmt das Client-Gerät 1410 bei Block 1810 (der Nutzer des Client-Geräts 1410 hat die Videogesprächseinladung angenommen), ob Audio aktuell durch das Lautsprechertelefon geroutet wird (z. B. der Lautsprecher 1470) oder durch das Headset des Client-Geräts 1410. Wenn dies nicht der Fall ist, bewegt sich der Fluss zu Block 1812, wo die Audioroute vom Lautsprecher 1455 zum Lautsprechertelefon (z. B. Lautsprecher 1470) geändert wird, und der Fluss bewegt sich zu Block 1814. Wenn das Audio schon durch das Lautsprechertelefon oder ein Headset geroutet wird, bewegt sich der Fluss zu Block 1814.
Bei Block 1814 zeigt das Client-Gerät 1410 eine Videovorschau dessen an, was die Frontkamera 1460 aktuell aufnimmt. Der Ablauf in Block 1814 wird nur dann ausgeführt, wenn die Videovorschau ein Ergebnis des Ablaufs im Block 1730 aktuell nicht angezeigt wird.
Der Fluss bewegt sich vom Block 1814 zu Block 1820. Bei den Blöcken 1818 und 1820 bauen die Client-Geräte 1210 und 1410 eine P2P-Verbindung miteinander auf. Die P2P-Verbindung kann durch bekannte Mechanismen aufgebaut werden (z. B. durch Verwendung von Internet Connectivity Establishment (ICE) oder andere bekannte P2P-Verbindungsmechanismen). Angenommen, dass die P2P-Verbindung erfolgreich aufgebaut wird, bewegt sich der Fluss von den Blöcken 1818 und 1820 zu den Blöcken 1822 bzw. 1824, wo die Client-Geräte 1210 und 1410 anfangen, einander über die P2P-Verbindung Videos zu übermitteln (das Video von den Frontkameras 1260 und 1460). In manchen Ausführungsformen beinhaltet das Video sowohl Videoframes als auch entsprechendes Audio (aufgenommen durch die Mikrofone 1265 und 1465 der Client-Geräte 1210 bzw. 1410), während in anderen Ausführungsformen das Video und Audio getrennte Streams sind, die über die P2P-Verbindung kommuniziert werden.
Der Fluss bewegt sich von den Blöcken 1822 und 1824 zu den Blöcken 1826 bzw. 1828. Bei den Blöcken 1826 und 1828 bestimmen die Client-Geräte 1210 bzw. 1410, ob sie über mehrere Videoframes ihren Peer empfangen haben. Wenn sie es haben, bewegt sich der Fluss von den Blöcken 1826 und 1828 zu den Blöcken 1830 bzw. 1832. Wenn sie es nicht haben, bleibt der Fluss bei den Blöcken 1826 und 1828, bis ein oder mehrere Videoframes empfangen worden sind.
In manchen Ausführungsformen warten die Client-Geräte 1210 und 1410 darauf, Videoframes voneinander für eine bestimmte Zeit zu empfangen und wenn sie keine Videoframes über diese Zeit austauschen, werden alternative Operationen durchgeführt. Zum Beispiel wird in manchen Ausführungsformen das Videogespräch abgebrochen und es wird eine Nachricht auf dem Bildschirm der Client-Geräte 1210 und 1410 angezeigt, dass das Videogespräch nicht aufgebaut werden konnte. Dem Videogespräch könnte es aus bestimmten Gründen nicht gelingen aufgebaut zu werden, einschließlich dass die Bandbreite nicht für das Videogespräch ausreicht, die Videoframe nicht übermittelt oder empfangen werden konnten etc. Während in manchen Ausführungsformen die Client-Geräte für ein einzelnes Frame von Video vor der Verarbeitung warten, warten in anderen Ausführungsformen die Client-Geräte darauf, eine Reihe von Frames über eine bestimmte Zeitdauer (z. B. ein Fluss von Videoframes) vor der Verarbeitung zu empfangen.
Bei den Blöcken 1830 und 1832 gehen die Client-Geräte 1210 bzw. 1410 zu dem Videogespräch über. Der Übergang zu dem Videogespräch beinhaltet das Anzeigen des Videos, das empfangen wird und das Wechseln der Audioroute von dem leitungsvermittelten Audiogespräch zu dem Videogespräch. In manchen Ausführungsformen bewegt sich die Videovorschau (z. B. die Videovorschau 1310) in eine Ecke des Bildschirms (und schrumpft in der Größe) und das Video, das von dem Peer empfangen wird, wird gezeigt. Somit versteht sich, dass die Teilnehmer durch das leitungsvermittelte Audiogespräch kommunizieren können bis die Route von dem leitungsvermittelten Audiogespräch zu dem Videogespräch geändert wurde (d. h. das leitungsvermittelte Audiogespräch bleibt aufgebaut, während das Videogespräch ausgehandelt wird). Nach dem Übergang zu dem Videogespräch kann das leitungsvermittelte Audiogespräch fallengelassen werden. Somit bewegt sich der Fluss von den Blöcken 1830 und 1832 zu den Blöcken 1834 bzw. 1836, wo das leitungsvermittelte Audiogespräch fallengelassen wird.
Die 15 und 16 stellen die Client-Geräte 1210 bzw. 1410 dar, nachdem sie zu dem Videogespräch übergegangen sind. Wie in 15 dargestellt zeigt das Client-Gerät 1210 das Video 1510 an, welches ein Video dessen ist, was die Frontkamera 1460 des Client-Geräts 1410 aufnimmt. Das Client-Gerät 1210 zeigt auch das Video 1515 an, welches ein Video dessen ist, was von der Frontkamera 1260 aufgenommen wurde. Die GUI 1505 enthält auch die Video-Beenden-Schaltfläche 1520 und die Video-Beenden- und Anrufen-Schaltfläche 1625. Die Video-Beenden-Schaltfläche 1520 ermöglicht es dem Nutzer, das Videogespräch zu beenden und zu dem reinen Audiogespräch zurückzukehren. Die Video-Beenden- und Anrufen-Schaltfläche 1525 ermöglicht es dem Nutzer, das Videogespräch vollständig zu beenden (z. B. um Konversation mit dem Nutzer bei dem Client-Gerät 1410 zu beenden). Wie in 16 dargestellt, zeigt das Client-Gerät 1410 das Video 1610 an, welches ein Video dessen ist, was durch die Frontkamera 1260 des Client-Geräts 1210 aufgenommen wurde. Das Client-Gerät 1410 zeigt auch das Video 1615 an, welches ein Video dessen ist, was durch die Frontkamera 1460 aufgenommen wurde. Die GUI 1605 enthält auch die Video-Beenden-Schaltfläche 1620 und die Video-Beenden- und Anrufen-Schaltfläche 1625.
19 ist ein Flussdiagramm, das beispielhafte Abläufe, die auf einem Client-Gerät geführt werden, dass eine Videogesprächsverweigerungsnachricht gemäß einer Ausführungsform empfängt, darstellt. Bei Block 1910 empfängt das Client-Gerät 1210 eine Videogesprächsverweigerungsnachricht (der Nutzer der Client-Geräte 1410 hat die Videogesprächseinladung verweigert). Der Fluss bewegt sich Block 1910 zu Block 1912 und das Client-Gerät 1210 zeigt eine Videogesprächsverweigerungsnachricht an und spielt optional ein oder mehrere Audiotöne, die den Empfang der Videogesprächsverweigerungsnachricht anzeigen. Der Fluss bewegt sich dann zu Block 1914, wo das Client-Gerät 1210 das Anzeigen seiner eigenen Videovorschau stoppt. Das Client-Gerät 1210 könnte auch den Nutzer dazu auffordern, zum Originalaudioausgang zurückzukehren (z. B. durch Lautsprecher 1270), wenn der Audioausgang zuvor zu dem Lautsprechertelefon in Block 1718 gewechselt wurde.
20 ist ein Flussdiagramm, das beispielhafte Abläufe anzeigt, die in einem Client-Gerät ausgeführt werden im Übergang von einem Videogespräch zu einem leitungsvermittelten Gespräch gemäß einer Ausführungsform. Ein Videogespräch 2010 wird zwischen den Client-Geräten 1210 und 1410 aufgebaut (das Videogespräch könnte gemäß Mechanismen, die im Zusammenhang mit den 17 und 18 beschrieben wurden, aufgebaut werden oder könnte ohne Übergang bei einem leitungsvermittelten Audiogespräch aufgebaut werden). Bei Block 1712 empfängt das Client-Gerät 1210 eine Eingabe, um zu einem reinen Audio-leitungsvermittelten Gespräch überzugehen. Zum Beispiel im Zusammenhang mit 15 hat der Nutzer des Client-Geräts 1210 die Video-Beenden-Schaltfläche 1520 ausgewählt (z. B. durch Tippen oder Ausführen einer anderen vorbestimmten Geste auf der Video-Beenden-Schaltfläche 1520). Das Client-Gerät 1210 übermittelt dann eine Nachricht an das Client-Gerät 1410, die einen Übergang zu einem rein Audio-leitungsvermittelten Gespräch 2040 anzeigt.
Das Client-Gerät 1210 initiiert dann eine leitungsvermittelte Audiogesprächanfrage an das Client-Gerät 1410 (z. B. ruft das Client-Gerät 1210 automatisch die Nummer des Client-Geräts 1410 an). In manchen Ausführungsformen wird es im Hintergrund ausgeführt und fordert keine Nutzerinteraktion. Das Gespräch wird durch eine Reihe von Netzwerkelementen der Carrier-Netzwerkinfrastruktur geroutet (z. B. Basisstationen, mobile Switching Center, etc.).
Das Client-Gerät 1410 empfängt und beantwortet den leitungsvermittelten Anruf 2020. In einer Ausführungsform zeigt das Client-Gerät 1410 die eingehende Gesprächsanfrage an und könnte Audiotöne abspielen, die auf die einkommende Gesprächsanfrage hinweisen (z. B. Gesprächswartetöne oder andere Töne), und erfordert eine Nutzerintervention, um das Gespräch zu erwidern. In einer anderen Ausführungsform antwortet das Client-Gerät 1410 automatisch auf das Gespräch ohne eine Nutzerintervention (und könnte Audiotöne, die auf die eingehende Gesprächsanfrage hinweisen, abspielen, oder auch nicht). Nachdem das Gespräch beantwortet wurde, wird ein rein Audio-leitungsvermitteltes Gespräch aufgebaut 2030 zwischen Client-Geräten 1210 und 1410.
Nachdem das rein Audio-leitungsvermittelte Gespräch erfolgreich aufgebaut wurde, gehen die Client-Geräte 1210 und 1410 zu dem reinen Audiogespräch 2032 bzw. 2034 über. Zum Beispiel beinhaltet der Übergang zu dem reinen Audiogespräch den Wechsel der Audioroute von Videogespräch zu dem leitungsvermittelten Gespräch, das Stoppen des Anzeigens des Videos, das empfangen wird, und das Stoppen der Übermittlung des Videos. Das Client-Gerät könnte auch das Anzeigen der Videovorschau stoppen. Somit ist verständlich, dass während das leitungsvermittelte reine Audiogespräch ausgehandelt wird, die Nutzer an den Client-Geräten 1210 und 1410 durch das Videogespräch kommunizieren können (d. h. das Videogespräch bleibt aufgebaut, während das reine Audio-leitungsvermittelte Gespräch ausgehandelt wird). Nach dem erfolgreichen Übergang zu dem reinen Audio-leitungsvermittelten Gespräch beenden die Client-Geräte 1210 und 1410 die P2P-Verbindung 2040. Die Nutzer bei den Client-Geräten 1210 und 1410 könnten dann durch das reine Audio-leitungsvermittelte Gespräch kommunizieren.
Während die Ausführungsformen der Erfindung in Bezug auf ein Videogespräch mit zwei Teilnehmern beschrieben worden sind, sind die Ausführungsformen nicht auf diese Weise beschränkt, da es mehrere Teilnehmer in dem Videogespräch geben kann. In solchen Ausführungsform könnte das Client-Gerät eine Vielzahl von Videostreams von jedem unterschiedlichen Teilnehmer in dem Videochat zeigen.
Während die Ausführungsformen der Erfindung in Bezug zu einem Videogespräch mit zwei Teilnehmern, wo jeder Teilnehmer ein Video übermittelt, beschrieben worden sind, sind die Ausführungsformen nicht auf diese Weise beschränkt. Zum Beispiel könnte in manchen Ausführungsformen eine einzelne Partei ein Video zu den anderen Teilnehmern übermitteln und diese anderen Teilnehmer könnten nur Audio übermitteln. In manchen Ausführungsformen könnte jeder Teilnehmer bestimmen, ob er die Übermittlung des Videos zu irgendeinem Zeitpunkt während des Videogesprächs unterbricht.
In manchen Ausführungsformen wird die Qualität des Video, das während des Gesprächs übermittelt wird, dynamisch eingestellt basierend auf Netzwerkkonditionen. Zum Beispiel könnte die Bitrate des Videos in Zeiträumen, wenn das Netzwerk überlastet ist, gesenkt werden. In ähnlicher Weise könnte die Bitrate des Videos in Zeiten, wenn das Netzwerk relativ frei ist von Überlastungen, erhöht werden. In manchen Ausführungsformen, falls die Netzwerkkonditionen das Video davon abhalten übermittelt zu werden, gehen die teilnehmenden Client-Geräte automatisch zu einem rein Audio-leitungsvermittelten Gespräch über. Somit könnten die teilnehmenden Client-Geräte, falls die Bandbreite unter ein bestimmtes Niveau fällt, automatisch zu einem reinen Audio-leitungsvermittelten Gespräch übergehen (oder könnten den Nutzer auffordern, zu einem reinen Audio-leitungsvermittelten Gespräch überzugehen).
Freisprechdienstesupport über eine Freisprecheinrichtung für IP-Videogespräche
In einer Ausführungsform beinhalten die Client-Geräte Funktionalitäten, um Interaktion mit einer Freisprecheinrichtung zu unterstützen (z. B. ein Headset, Autokit) über ein WPAN (Wireless Personal Area Network) (z. B. Bluetooth, ZigBee etc.) einschließlich Unterstützung zur Verwaltung von IP-Videogesprächen mit der Freisprecheinheit. 32 ist ein Blockdiagramm, das ein Client-Gerät darstellt, das eine Schnittstelle mit einer Freisprecheinheit bildet, um IP-Videogespräche gemäß einer Ausführungsform zu verwalten. Das Client-Gerät 3210 weist die Fähigkeit auf, Videogespräche zu initiieren (z. B. ein oder mehrere Empfänger zu einer Online-Kommunikationssitzung, die ein Videogespräch ist, einzuladen) und die Fähigkeit Videogespräche anzunehmen. In manchen Ausführungsformen umfasst das Client-Gerät 3210 auch Mobiltelefonkomponenten, um Mobiltelefongespräche durchzuführen und zu empfangen und/oder für das Internet oder anderes Netzwerk durch eine mobile Verbindung zuzugreifen.
Wie in 32 dargestellt beinhaltet das Client-Gerät 3210 den IP-Videogesprächsmanager 3250, den Telefonmanager 3260, den Audiomanager 3275 und den Freisprechmanager 3270. In manchen Ausführungsformen umfasst das Client-Gerät 3210 auch den mobilen Gesprächsmanager 3255. Der IP-Videogesprächsmanager 3250 verwaltet eine P2P-Videogesprächsanwendung einschließlich des Aufbaus eines IP-P2P-Videogesprächs über das IP-Netzwerk 3235 durch den IP-Videogesprächsdienst 3230 wie zuvor hier beschrieben. In einer Ausführungsform umfasst der IP-Videogesprächsdienst 3230 ein oder mehrere Einladungsdienste 620, den Push-Benachrichtigungsdienst 640, den Registrierungsdienst 630 und/oder den Registrierungsdienst 2130, und den Relaydienst 650. Der mobile Gesprächsmanager 3255 verwaltet die mobilen Komponenten, um reine Audio-Mobiltelefongespräche über das mobile Netzwerk 3245 durchzuführen und zu empfangen unter Verwendung des mobilen Audiogesprächsdiensts 3240.
Der IP-Videogesprächsmanager 3250 und der mobile Gesprächsmanager 3255 sind mit dem Telefoniemanager 3260 verknüpft. Der Telefoniemanager 3260 verwaltet die Telefonieabläufe sowohl für den IP-Videogesprächsmanager 3250 als auch für den mobilen Gesprächsmanager 3255 einschließlich des Trackings der Gesprächshistorie (sowohl für Videogespräche als auch für reine Audiomobilgespräche) und andere Informationen im Zusammenhang mit den Gesprächen. Der Telefoniemanager 3216 stellt auch eine Schnittstelle mit dem Freisprechmanager 3270, um Freisprechdienste über eine externe Freisprecheinrichtung für IP-Videogespräche und mobile Gespräche im Namen des IP-Videogesprächsmanagers 3250 und dem mobilen Gesprächsmanager 3255 zur Verfügung zu stellen. In einer Ausführungsform wird ein gewöhnliches Nachrichtenformat verwendet zwischen dem IP-Videogesprächsmanager 3250, dem mobilen Gesprächsmanager 3255 und dem Telefoniemanager 3260, um Unterstützung für die Freisprechdienste für verschiedene Protokoll- und Gesprächstypen zur Verfügung zu stellen (IP-Videogespräch und rein Audiomobilgespräch). Somit stellt der Telefoniemanager 3260 ähnliche Unterstützung für Freisprechdienste zur Verfügung, unabhängig davon, ob die Freisprechdienste für ein IP-Videogespräch oder ein rein Audiomobilgespräch gedacht sind. Dies verhindert auch den Freisprechmanager 3270 von der Notwendigkeit zu verstehen, ob die Freisprechdienste für ein IP-Videogespräch oder für ein rein Audiomobilgespräch sind, so dass Befehle, die von den Freisprecheinrichtungen verstanden werden, für die zur Verfügung Stellung von Freisprechdiensten für IP-Videogespräche wie auch für rein Audiomobilgespräche verwendet werden können.
In einer Ausführungsform vermittelt der Telefoniemanager 3260 auch zwischen dem IP-Videogesprächsmanager 3250 und dem mobilen Gesprächsmanager 3255. Zum Beispiel kann der Telefoniemanager 3260 veranlassen, dass ein IP-Videogespräch auf Halten gestellt wird, um zu einem aufgebauten rein Audiomobilgespräch zu wechseln und/oder veranlasst ein rein Audiomobilgespräch auf Haken gestellt zu werden, um zu einem IP-Videogespräch zu wechseln.
Der Freisprechmanager 3270 liefert Unterstützung für Freisprechverarbeitung. In einer Ausführungsform implementiert der Freisprechmanager 3270 ein Bluetooth-Protokollstack für die Verbindung zu Bluetooth konforme Freisprecheinrichtungen wie beispielsweise Bluetooth Headset und Bluetooth Carkits. In einer spezifischen Ausführungsform implementiert der Freisprechmanager 3270 ein Bluetooth-Headsetprofil (z. B. wie in dem Headset Profile (HSP) 1.2 Spezifikation vom 18. Dezember 2008 definiert) und/oder ein Bluetooth-Freisprechprofil (z. B. wie in dem Freisprechprofil 1.5 (HFP 1.5) Beschreibung von 25. November 2005 definiert). Der Freisprechmanager 3270 ermöglicht es der Freisprecheinheit 3220 sowohl als audiotives Relay für ein IP-Videogespräch und für ein rein Audiomobilgespräch über das WPAN 3225 zu agieren, als auch andere Freisprechdienste auszuführen. Zum Beispiel für den Fall eines IP-Videogesprächs könnte der Audioteil des Gesprächs durch die Freisprecheinheit 3220 geroutet werden anstelle eines Lautsprechers des Client-Geräts 3210, während der Videoteil des Gesprächs weiterhin durch das Client-Gerät 3210 angezeigt wird (oder durch ein angeschlossenes Display). Die Freisprecheinheit 3220 umfasst auch ein Mikrofon, um Audioinformation zu empfangen, welche dann an das Client-Computergerät 3210 übermittelt wird. Somit kann der Nutzer die Freisprecheinrichtung 3220 verwenden, um sich zu unterhalten oder einer Audio zuzuhören während eines IP-Videogesprächs und/oder während eines rein Audiomobilgesprächs.
Der Freisprechmanager 3270 unterstützt auch andere Freisprechdienste in Antwort auf das Empfangen von einer Eingabe von der Freisprecheinheit 3220 einschließlich des Ausführens von einem oder mehreren der folgenden für IP-Videogespräche und/oder rein Audiomobilgespräche: Einem Nutzer erlauben, ein Gespräch zu erwidern; ein Gespräch beenden; ein Gespräch auf Halten stellen; ein Gespräch stummschalten; die Lautstärke eines Gesprächs erhöhen/senken; Audio an das Client-Gerät transferieren; Audio an die Freisprecheinheit transferieren; ein Gespräch tätigen; und das letzte Gespräch wiederwählen. Somit kann der Nutzer die Freisprecheinheit 3220 nutzen, um ein IP-Videogespräch zu beantworten, ein IP-Videogespräch zu beenden, ein IP-Videogespräch auf Halten zu stellen und/oder auf stumm zu schalten, die Lautstärke eines IP-Videogesprächs zu erhöhen/zu senken, Audio des Videogesprächs zu transferieren, damit es an einen Lautsprecher des Client-Geräts 3210 ausgegeben wird, Audio von dem Client-Gerät 3210 zu der Freisprecheinheit 3220 zu transferieren, ein IP-Videogespräch platzieren, und das letzte IP-Videogespräch wiederzuwählen.
Der IP-Videogesprächsmanager 3250, der mobile Gesprächsmanager 3255, und der Freisprechmanager 3270 sind auch mit dem Audiomanager 3275 verknüpft. Der Audiomanager 3275 routet Audio der IP-Videogespräche und der rein Audiomobilgespräche durch verschiedene Quellen. Zum Beispiel kann der Audiomanager 3275 veranlassen, dass das Audio ausgegeben wird über einen Lautsprecher des Client-Geräts 3210, der für einen Lautsprechertelefonmodus geeignet ist, über einen Lautsprecher des Client-Geräts 3210, das verwendet wird, wenn ein Nutzer das Client-Gerät 3210 während des Gesprächs an sein Ohr hält, über ein Headset/Headphonejack an ein Headset oder Headphone, das in das Client-Gerät 3210 eingesteckt ist, und über ein peered Freisprecheinheit (wie beispielsweise die Freisprecheinheit 3220).
33 stellt das Client-Gerät 3210 dar, das eine Einladung für ein Videogespräch empfängt, die Freisprecheinrichtung veranlasst zu klingeln, einen Antworthinweis von der Freisprecheinrichtung empfängt, das Videogespräch aufbaut und das Audio an die Freisprecheinrichtung gemäß einer Ausführungsform routet. 33 wird im Zusammenhang mit der beispielhaften Ausführungsform von 32 beschrieben werden. Es versteht sich jedoch, dass die Abläufe von 33 durch andere Ausführungen durchgeführt werden können als solche, die mit Bezug zu 32 diskutiert wurden, und dass die Ausführungsformen, die im Zusammenhang mit 32 diskutiert wurden, andere Abläufe als solche, die im Zusammenhang mit 33 diskutiert werden, ausführen kann.
Bei Ablauf 3310 empfängt der IP-Videogesprächsmanager 3250 eine IP-Videogesprächseinladung von einem anderen Client-Gerät, das dem Nutzer des Client-Gerät 3210 dazu einlädt, an einem IP-Videogespräch teilzunehmen. Die IP-Videogesprächseinladung kann die Form der Einladung wie hier zuvor beschrieben annehmen. Der IP-Videogesprächsmanager 3250 verarbeite die Einladungsanfrage einschließlich des Veranlassens, dass die Einladung bei Ablauf 3315 angezeigt wird. Zum Beispiel könnte die Einladungsanfrage in ähnlicher Weise wie die beispielhafte Videogesprächseinladung 1410, die in 14 dargestellt ist, angezeigt werden.
Zusätzlich erzeugt und übermittelt der IP-Videogesprächsmanager 3250 ein Gesprächsobjekt 3320 an den Telefoniemanager 3260. Das Gesprächsobjekt 3320 beinhaltet eine Reihe von Parametern bezüglich des Gesprächs. Zum Beispiel umfassen die Gesprächsobjektparameter ein oder mehrere Status des Gesprächs (z. B. verbindet) und Gesprächsteilnehmerkennung (z. B. die Telefonnummer, Emailadresse, oder andere Online-Kommunikationssitzungsendpunktkennung), eine Startzeit, einen Hinweis, ob es ein ausgehende oder eingehendes Gespräch ist, und eine Gesprächskennung, die intern zur Identifizierung des Gesprächs verwendet wird.
In einer Ausführungsform ist das Gesprächsobjekt 3320 ein generisches Gesprächsobjekt, das, während Parameter auf den Informationen von der IP-Videogesprächseinladung basieren, in einem Format ist, das sowohl für IP-Videogesprächseinladungsanfragen als auch für eingehende rein Audiomobilgespräche üblich ist. Somit erzeugt der mobile Gesprächsmanager 3255, wenn er ein eingehendes rein Audiomobilgespräch empfängt, ein eingehendes Gesprächsobjekt selben Formats. Somit erscheint zur Perspektive des Telefoniemanagers 3260 eine IP-Videogesprächseinladungsanfrage oder ein eingehendes rein Audiomobilgespräch das gleiche zu sein.
Der Telefoniemanager 3260 speichert die Information in dem Gesprächsobjekt 3320 als Teil einer Gesprächshistoriestruktur. Der Telefoniemanager 3260 erzeugt und sendet auch eine eingehende Gesprächsnachricht 3322 an den Freisprechmanager 3270. In einer Ausführungsform sendet der Telefoniemanager 3260 nur die eingehende Gesprächsnachricht 3322, falls eine Freisprecheinrichtung, wie beispielweise die Freisprecheinrichtung 3220 vorhanden ist, dass mit dem Client-Gerät 3210 gepeert ist (z. B. der Telefoniemanager 3260 überprüft zuerst, ob eine Freisprecheinrichtung, die mit dem Client-Gerät 3210 gepeert ist, vorhanden ist). In anderen Ausführungsformen sendet der Telefoniemanager 3260 die eingehende Gesprächsnachricht 3322 an den Freisprechmanager 3270, unabhängig davon, ob eine peered Freisprecheinrichtung vorhanden ist und der Freisprechmanager 3270 bestimmt, ob es die Nachricht fallenlässt/ignoriert oder es in Abhängigkeit davon, ob eine peered Freisprecheinrichtung vorhanden ist, verarbeitet. Für den Zweck der 33 und der folgenden Figuren wird angenommen, dass die Freisprecheinrichtung 3220 an das Client-Computergerät 3210 gepeert ist. In einer Ausführungsform umfasst die eingehende Gesprächsnachricht 3322 die Gesprächskennung.
Als Antwort auf den Empfang der eingehenden Gesprächsnachricht 3320 veranlasst der Freisprechmanager 3270, dass eine Reihe von Nachrichten an die Freisprecheinrichtung 3220 übermittelt wird und es und den Nutzer darüber alarmiert, dass ein eingehendes Gespräch vorhanden ist. In 33 dargestellt baut der Freisprechmanager eine Audioverbindung 3325 (z. B. ein Synchronous Connection Oriented (SCO) Link) mit der Freisprecheinrichtung 3220 vor dem Senden einer Klingeltonnachricht 3330 über die aufgebaute Audioverbindung 3325 auf. Diese Klingeltonnachricht wurde durch das Client-Gerät 3210 ausgewählt und könnte durch den Nutzer des Client-Geräts 3210 anpassbar sein. In einer Ausführungsform unterscheidet sich die Klingeltonnachricht für IP-Videogespräche von dem Klingelton für rein Audiomobilgespräche. In einer anderen Ausführungsform wird eine Audioverbindung nicht aufgebaut, bis das Gespräch beantwortet worden ist. In solch einer Ausführungsform wird die Klingelalarmnachricht an die Freisprecheinrichtung 3220 gesendet, welche dann lokal bestimmt, ob es ein Klingelton zum Alarmieren des Nutzers des eingehenden Gesprächs abspielt (die Klingelalarmnachricht könnte auch vor dem Senden der Klingeltonnachricht 3330 gesendet werden). In solch einer Ausführungsform könnte eine Klingelalarmnachricht mehrere Male an die Freisprecheinrichtung 3220 gesendet werden, bis das Gespräch beantwortet wird oder endet.
Irgendwann nach dem Empfangen der Klingelalarmnachricht und/oder der Klingelnachricht 3330 übermittelt die Freisprecheinrichtung 3220 die beantwortete Nachricht 3335, die darauf hinweist, das ein Nutzer das Gespräch beantwortet hat. Zum Beispiel hat der Nutzer eine Antwortschaltfläche auf einer Freisprecheinrichtung 3220 gedrückt oder auf eine andere Weise eine Aktion auf der Freisprecheinrichtung 3220 zur Beantwortung des Gesprächs vorgenommen. Der Freisprechmanager 3270 empfängt die beantwortete Nachricht 3335 und übermittelt eine beantwortete Nachricht 3340 an den Telefoniemanager 3260. In einer Ausführungsform umfasst die beantwortete Nachricht 3340 die Gesprächskennung. Obwohl es in 33 nicht dargestellt ist, könnte der Freisprechmanager 3270 auch eine Anerkennung an die Freisprecheinrichtung 3220 als Antwort auf den Empfang der beantworteten Nachricht 3335 übermitteln.
Der Telefoniemanager 3260 bestimmt, dass die beantwortete Gesprächsnachricht 3340 zu dem Gespräch, das in dem Gesprächsobjekt 3320 angedeutet wurde, gehört (z. B. durch Vergleich der Gesprächskennung, die in der Nachricht 3340 enthalten ist, oder Information, die von dem Gesprächsobjekt 3320 gespeichert ist) und übermittelt eine Nachricht 3345 an den IP-Videogesprächsmanager 3250, die darauf hinweist, dass das Gespräch beantwortet worden ist. In Antwort auf das Empfangen dieser Nachricht baut der IP-Videogesprächsmanager 3250 ein IP-Videogespräch bei Ablauf 3350 auf. Zum Beispiel veranlasst der IP-Videogesprächsmanager 3250, dass eine IP-Videogesprächsannahmenachricht an einen Einladungsdienst wie hier zuvor beschrieben gesendet wird und eine P2P-Verbindung aufgebaut wird (entweder direkt oder über ein Relay) mit dem Computergerät, das die Einladung übermittelt hat.
Irgendwann nachdem das IP-Videogespräch aufgebaut worden ist, übermittelt der IP-Videogesprächsmanager 3250 ein Gesprächsobjekt 3355 an den Telefoniemanager 3260. Das Gesprächsobjekt 3355 umfasst eine ähnliche Reihe von Parametern wie das Gesprächsobjekt 3320 mit der Ausnahme von verbindet zu verbunden gewechselt hat. In einer Ausführungsform ist das Gesprächsobjekt 3355 ein generisches Gesprächsobjekt, das ein Format hat, das sowohl für aufgebaute IP-Videogespräche als auch verbundene rein Audiomobilgespräche üblich ist.
Zusätzlich, nachdem das IP-Videogespräch aufgebaut worden ist, routet der Audiomanager 3275 das Audioteil des aufgebauten IP-Videogesprächs durch die Freisprecheinrichtung 3220. In einer Ausführungsform fordert der IP-Videogesprächsmanager 3250 oder der Telefoniemanager 3260 den Audiomanager 3275 auf, das Audio durch die Freisprecheinrichtung zu routen. Der Audiomanager 3275 könnte auch eine Nachricht 3360 an den Freisprechmanager 3270 übermitteln, der darauf hinweist, dass die Audioroute dahingehend geändert wird, dass sie durch die Freisprecheinrichtung 3220 geht. Falls eine Audioverbindung noch nicht aufgebaut worden ist, wird der Freisprechmanager 3270 eine Audioverbindung mit der Freisprecheinrichtung 3220 aufbauen. Angenommen, dass eine aufgebaute Audioverbindung besteht, wird der Audioteil 3365 des Videogesprächs zu der Freisprecheinrichtung 3220 geroutet. Somit wird der Audioteil des Videogesprächs durch die Freisprecheinrichtung 3220 gehandhabt, während der Videoteil des Videogesprächs auf dem Client-Gerät 3210 angezeigt wird.
34 stellt das Client-Gerät 3210 dar, das ein Videogespräch initiiert und das Audio für das aufgebaute Videogespräch durch eine Freisprecheinrichtung gemäß einer Ausführungsform routet. 34 wird im Zusammenhang mit der beispielhaften Ausführungsform von 32 beschrieben. Es versteht sich jedoch, dass die Abläufe von 34 durch andere Ausführungsformen als jene, die im Zusammenhang mit 32 diskutiert wurden, durchgeführt werden können, und Ausführungsformen, die im Zusammenhang mit 32 diskutiert wurden, können Abläufe durchführen, die sich von denen unterscheiden, die im Zusammenhang mit 34 diskutiert wurden.
Bei Ablauf 3410 veranlasst der IP-Videogesprächsmanager 3250, dass ein oder mehrere IP-Videogesprächseinladungsnachrichten an andere Client-Geräte gesendet werden, um Nutzer zu einem IP-Videogespräch einzuladen. Die IP-Videogesprächseinladungsnachricht könnte die Form einer Einladung wie hier zuvor beschrieben annehmen. Der IP-Videogesprächsmanager 3250 erzeugt und übermittelt ein Gesprächsobjekt 3415 an den Telefoniemanager 3260. Ähnlich dem Gesprächsobjekt 3320 beinhaltet das Gesprächsobjekt 3415 eine Reihe von Parametern bezüglich des Gesprächs und ist in einem generischen Format. Der Telefoniemanager 3260 speichert die Information in dem Gesprächsobjekt 3415 als Teil der Gesprächshistoriestruktur.
In einer Ausführungsform erzeugt und sendet der Telefoniemanager 3260 auch eine ausgehende Gesprächsnachricht 3420 an den Freisprechmanager 3270, die anzeigt, dass ein ausgehendes Gespräch vorhanden ist. Als Antwort auf diese Nachricht baut der Freisprechmanager 3270 eine Audioverbindung 3425 mit der Freisprecheinrichtung 3220 auf (falls ein gewöhnlicher Bandklingelton zu senden ist) und übermittelt eine Klingeltonnachricht 3430 an die Freisprecheinrichtung 3220. In anderen Ausführungsformen übermittelt der Freisprechmanager 3270 nur eine Klingeltonalarmnachricht an die Freisprecheinrichtung 3220 anstelle eine Audioverbindung aufzubauen und übermittelt einen In-Band-Klingelton.
Irgendwann nach dem Senden der IP-Videogesprächseinladung fängt der IP-Videogesprächsmanager 3250 ein IP-Videogesprächsannahmenachricht 3435, die die Form einer Videogesprächsannahmenachricht wie hier zuvor beschrieben annehmen kann. Nach dem Empfang dieser Nachricht wird ein P2P-IP-Videogespräch aufgebaut mit dem annehmenden Client-Gerät bei Ablauf 3440 (z. B. eine P2P-Verbindung (entweder direkt oder über ein Relay) wird aufgebaut mit dem Computergerät, das die Einladung angenommen hat).
Irgendwann nachdem das IP-Videogespräch aufgebaut worden ist, übermittelt der IP-Videogesprächsmanager 3250 ein Gesprächsobjekt 3445 an den Telefoniemanager 3260. Das Gesprächsobjekt 3445 beinhaltet eine ähnliche Reihe von Parametern wie das Gesprächsobjekt 3415 mit der Ausnahme, dass der Status von verbindet zu verbunden gewechselt hat. Das Gesprächsobjekt 3445 ist auch in einem generischen Format. Zusätzlich irgendwann nachdem das IP-Videogespräch aufgebaut worden ist, routet der Audiomanager 3275 den Audioteil des aufgebauten IP-Videogesprächs durch die Freisprecheinrichtung 3220.
In einer Ausführungsform fordert der IP-Videogesprächsmanager 3250 oder der Telefoniemanager 3260 den Audiomanager 3275 dazu auf, das Audio durch die Freisprecheinrichtung zu routen. Der Audiomanager 3275 könnte auch eine Nachricht 3455 an den Freisprechmanager 3270 übermitteln, die darauf hinweist, dass die Audioroute dahingehend geändert wird, dass sie durch die Freisprecheinrichtung 3220 geht. Falls eine Audioverbindung noch nicht aufgebaut worden ist, wird der Freisprechmanager 3270 eine Audioverbindung mit der Freisprecheinrichtung 3220 aufbauen. Angenommen, dass eine aufgebaute Audioverbindung besteht, wird der Audioteil 3460 des Videogesprächs an die Freisprecheinrichtung 3220 geroutet. Somit wird der Audioteil des Videogesprächs durch die Freisprecheinrichtung 3220 gehandhabt, während der Videoteil des Videogesprächs auf dem Client-Gerät 3210 angezeigt wird.
35 stellt das Client-Gerät 3210 dar, das ein Videogespräch als Antwort auf den Empfang einer Gesprächsanfrage von der Freisprecheinrichtung 3220 gemäß einer Ausführungsform initiiert. 35 wird im Zusammenhang mit der beispielhaften Ausführungsform von 32 beschrieben werden. Es versteht sich jedoch, dass die Abläufe von 35 durch andere Ausführungsformen durchgeführt werden können als solche, die im Zusammenhang mit 32 diskutiert wurden, und die Ausführungsformen, die im Zusammenhang mit 32 diskutiert wurden, Abläufe durchführen können, die sich von denen unterscheiden, die im Zusammenhang mit 35 diskutiert wurden.
Der Freisprechmanager 3270 empfängt eine Gesprächsanfrage 3510 von der Freisprecheinrichtung 3220. Die Gesprächsanfrage 3510 könnte als Antwort darauf erzeugt werden, dass ein Nutzer eine Telefonnummer oder andere Kommunikationssitzungsendpunktkennung, die angerufen werden soll, gewählt hat. Zum Beispiel könnte der Nutzer die Wiederwahlschaltfläche auf der Freisprecheinrichtung 3220 auswählen, welche erfordert, dass das letzte Gespräch wiedergewählt wird.
Der Freisprechmanager 3270 übermittelt eine Gesprächsanfragenachricht 3520 an den Telefoniemanager 3260. Der Telefoniemanager 3260 bestimmt, ob die Gesprächsanfragenachricht 3520 ein Gespräch zu einer Kennung anfragt, die mit einem Videogespräch assoziiert ist (und somit sollte die Gesprächsanfragenachricht an den IP-Videogesprächsmanager 3250 gesendet werden) oder mit einer Telefonnummer für ein rein Audiomobilgespräch assoziiert ist (und somit an den Mobilgesprächsmanager 3255 gesendet werden soll). Zum Beispiel für den Fall, dass die Gesprächsanfrage 3520 eine Wiederwahlanfrage ist, greift der Telefoniemanager 3260 auf das letzte gewählte Gespräch zu, welches entweder ein IP-Videogespräch oder ein rein Audiomobilgespräch sein kann, um zu bestimmen, wo die Gesprächsanfrage hingesendet werden soll. Wie in 35 dargestellt, sendet der Telefoniemanager Gesprächsanfragenachricht 3525 an den IP-Videogesprächsmanager 3250. Die Gesprächsanfragenachricht 3525 beinhaltet die Kennung von dem angefragten Teilnehmer für das Videogespräch (z. B. eine Telefonnummer, eine Emailadresse, oder andere Kommunikationssitzungsendpunktkennung). Als Antwort auf den Empfang der Gesprächsanfragenachricht 3525 veranlasst der IP-Videogesprächsmanager 3250, dass eine IP-Videogesprächseinladungsnachricht an den angezeigten Teilnehmer bei Ablauf 3410 wie in 34 beschrieben gesendet wird. Die verbleibenden Abläufe, die in 35 dargestellt sind, werden wie im Zusammenhang mit 34 beschrieben durchgeführt. Somit unterstützt das Client-Gerät 3210 den Aufbau eines IP-Videogesprächs als Ergebnis einer Nutzerhandlung bei einer peered Freisprecheinrichtung.
36 stellt das Client-Gerät 3210 dar, das Audio von einem aufgebauten Videogespräch zu einer Freisprecheinrichtung 3220 gemäß einer Ausführungsform routet. Es existiert ein aufgebautes IP-Videogespräch 3610 zwischen dem Client-Gerät 3210 und einem oder mehreren anderen Client-Geräten. Der Audioteil dieses Gesprächs wird zu diesem Zeitpunkt durch einen Lautsprecher des Client-Geräts 3210 ausgegeben oder durch Kopfhörer, die in dem Client-Gerät 3210 eingesteckt sind, ausgegeben. Bei Ablauf 3615 empfängt der IP-Videogesprächsmanager 3250 Eingaben, um das Audio an die Freisprecheinrichtung 3220 zu transferieren. Zum Beispiel hat ein Nutzer des Client-Geräts 3210 Eingaben an die IP-Videogesprächsanwendung geliefert, um Audio an eine peered Freisprecheinrichtung zu transferieren. Als Antwort auf dem Empfang einer solchen Eingabe sendet der IP-Videogesprächsmanager 3250 eine Audiorouteanfrage 3620 an den Audiomanager 3275, um den Audioteil des Videogesprächs durch die Freisprecheinrichtung 3220 zu routen. Der Audiomanager 3275 könnte eine Nachricht 3625 an den Freisprechmanager 3270 übermitteln, die anzeigt, dass die Audioroute geändert werden wird, um durch die Freisprecheinrichtung 3220 zu gehen. Falls eine Audioverbindung noch nicht aufgebaut wurde, wird der Freisprechmanager 3270 eine Audioverbindung 3630 mit der Freisprecheinrichtung 3220 aufbauen. Unter der Annahme, dass eine aufgebaute Audioverbindung existiert, wird der Audioteil 3635 des Videogesprächs zu der Freisprecheinrichtung 3220 geroutet. Somit erlaubt das Client-Gerät 3210 dem Nutzer, nachdem ein IP-Videogespräch aufgebaut wurde, das Audio an eine Freisprecheinrichtung zu transferieren.
Während 36 den Transfer von Audio zu einer Freisprecheinrichtung als Antwort auf den Empfang einer direkten Eingabe bei dem Client-Gerät darstellt, könnte der Nutzer in anderen Ausführungsformen veranlassen, dass das Audio zu der Freisprecheinrichtung durch Eingabe bei der Freisprecheinrichtung 3220 transferiert wird. In solchen Ausführungsformen empfängt der Freisprechmanager 3270 einen Befehl von der Freisprecheinrichtung 3220, um das Audio zu transferieren. Der Freisprechmanager 3270 sendet dann die Anfrage an den Audiomanager 3275, welcher dann das Audio reroutet.
Zusätzlich, während 36 den Transfer von Audio zu einer Freisprecheinrichtung darstellt, kann Audio in manchen Ausführungsformen auch von Freisprecheinrichtungen zu einem Lautsprecher (oder Kopfhörer) des Client-Geräts 3210 transferiert werden. Dies kann bei dem Client-Gerät 3210 und/oder der Freisprecheinrichtung 3220 initiiert werden. In solchen Ausführungsformen empfängt der Audiomanager 3275 die Routeaudioanfrage (entweder vom IP-Videogesprächsmanager 3250 oder dem Freisprechmanager 3270), um das Audio an das Client-Gerät 3210 zu routen und entsprechend zu handeln.
37 stellt das Client-Gerät 3210 beim Beenden eines Videogesprächs als Antwort auf den Empfang einer Gespräch beenden Anfrage von der Freisprecheinrichtung 3220 gemäß einer Ausführungsform dar. Der Freisprechmanager 3270 empfängt eine Gespräch beenden Nachricht 3710 von der Freisprecheinrichtung 3220 als Antwort darauf, dass ein Nutzer auswählt, das Gespräch zu beenden (z. B. eine Endschaltfläche wurde auf der Freisprecheinrichtung 3220 ausgewählt) bei der Freisprecheinrichtung 3220. Der Freisprechmanager 3270 übermittelt die Gespräch beenden Anfrage 3715 an den Telefoniemanager 3260. In einer Ausführungsform beinhaltet die Gespräch beenden Anfrage 3715 eine Gesprächskennung, um darauf hinzuweisen, welches Gespräch beendet werden soll (für den Fall, dass es eine Vielzahl von Gesprächen gibt). Der Telefoniemanager 3260 bestimmt, dass das Gespräch, das beendet werden soll, mit dem IP-Videogesprächsmanager 3250 assoziiert ist und sendet die Gespräch beenden Nachricht 3720 an den IP-Videogesprächsmanager 3250. Als Antwort auf den Empfang der Gespräch beenden Nachricht 3720 veranlasst der IP-Videogesprächsmanager 3250, dass das IP-Videogespräch beendet wird und veranlasst, dass das Client-Gerät 3210 die Verbindung von der P2P-Verbindung löst. Somit unterstützt das Client-Gerät 3210, dass dem Nutzer ermöglicht wird, ein IP-Videogespräch unter Verwendung einer peered Freisprecheinrichtung zu beenden.
38 ist ein Blockdiagramm, das ein beispielhaftes Computersystem darstellt, welches in manchen Ausführungsformen verwendet werden könnte. Zum Beispiel könnte die beispielhafte Architektur des Computersystems 3800 in den Client-Geräten 110, 1210, 1410, 2110, 2610, 3210 usw. oder anderen Computergeräten, die hier beschrieben sind, umfasst sein. Es versteht sich, dass während 38 verschiedene Komponenten eines Computersystems darstellt, es nicht beabsichtigt ist, irgendeine bestimmte Architektur oder Art von Verbindung der Komponenten zu repräsentieren, da solche Details für die vorliegende Erfindung nicht relevant sind. Andere Computersysteme, die weniger Komponenten oder mehr Komponenten haben, könnten ebenfalls verwendet werden.
Wie in 38 gezeigt beinhaltet das Computersystem 3800, welches eine Form von Datenverarbeitungssystem ist, den Bus/die Busse 3850, welcher/welche mit dem Verarbeitungssystem 3820, Stromversorgung 3825, Speicher 3830 und den nichtflüchtigen Speicher 3840 (z. B. eine Festplatte, ein Flash Memory, ein Phase-Change Memory (PCM) etc.) verknüpft ist. Die Busse 3850 könnten miteinander durch verschiedene Brücken, Steuerungen, und/oder Adapter, wie aus dem Stand der Technik bekannt, verbunden werden. Das Verarbeitungssystem 3820 könnte Weisungen von dem Speicher und/oder dem nichtflüchtigen Speicher 3840 abrufen, und die Anweisungen ausführen, um Abläufe wie oben beschrieben durchzuführen. Der Bus 3850 verbindet die oben genannten Komponenten miteinander und verbindet auch jene Komponenten zu dem optionalen Dock 3860, der Displaysteuerung und dem Displaygerät 3870, Eingang/Ausgangsgeräte 3880 (z. B. NIC (Network Interface Card), eine Cursorsteuerung (z. B. Maus, Touchscreen, Touchpad, etc.), eine Tastatur, etc.), und den optionalen Drahtlostransceiver 3890 (z. B. Bluetooth, WiFi, Infrarot etc.).
39 ist ein Blockdiagramm, das ein beispielhaftes Datenverarbeitungssystem darstellt, welches in manchen Ausführungsformen verwendet werden kann. Zum Beispiel könnte das Datenverarbeitungssystem 3900 ein handgehaltener Computer, ein Personal Digital Assistant (PDA), ein Mobiltelefon, ein tragbares Spielsystem, ein tragbarer Medienplayer, ein Tablet oder handgehaltenes Computergerät sein, welches ein Mobiltelefon, ein Mediaplayer und/oder Spielsystem beinhalten könnte. Als ein weiteres Beispiel könnte das Datenverarbeitungssystem 3900 ein Netzwerkcomputer oder ein eingebettetes Verarbeitungsgerät innerhalb eines anderen Geräts sein.
Gemäß einer Ausführungsform könnte die beispielhafte Architektur des Datenverarbeitungssystems 3900 in den Client-Geräten 110, 1210, 1410, 2110, 2610, 3210 usw. oder anderen Computergeräten, die hier beschrieben sind, umfasst sein. Das Datenverarbeitungssystem 3900 beinhaltet das Verarbeitungssystem 3920, welches einen oder mehrere Mikroprozessoren und/oder ein System auf einem integrierten Schaltkreis beinhalten könnte. Das Verarbeitungssystem 3920 wird mit einem Speicher 3910, einer Stromversorgung 3925 (welche eine oder mehrere Batterien beinhaltet), eine Audio-Eingabe/Ausgabe 3940, eine Displaysteuerung und ein Displaygerät 3960, optionale Eingabe/Ausgabe 3950, Eingabegerät(e) 3970, und Drahtlostransceiver 3930 verknüpft. Zusätzliche Komponenten, die nicht in 39 gezeigt sind, könnten auch Teil des Datenverarbeitungssystems 3900 in bestimmten Ausführungsformen sein und in bestimmten Ausführungsformen könnten weniger Komponenten als in 39 gezeigt verwendet werden. Zusätzlich können ein oder mehrere Busse, die nicht in 39 gezeigt sind, verwendet werden, um die verschiedenen Komponenten zu verbinden, wie aus dem Stand der Technik bekannt.
Der Speicher 3910 könnte Daten und/oder Programme zur Ausführung durch das Datenverarbeitungssystem 3900 speichern. Die Audio-Eingabe/Ausgabe 3940 könnte ein Mikrofon und/oder einen Lautsprecher beinhalten, um z. B. Musik abzuspielen und/oder Telefoniefunktionalitäten durch den Lautsprecher und das Mikrofon bereitzustellen. Die Displaysteuerung und das Displaygerät 3960 könnten eine grafische Nutzerschnittstelle (GUI) beinhalten. Der Drahtlos-(z. B. RF)-Transceiver 3930 (z. B. ein WiFi-Transceiver, ein Infrarot-Transceiver, ein Bluetooth-Transceiver, ein Drahtlosmobiltelefonie-Transceiver, etc.) könnten verwendet werden, um mit anderen Datenverarbeitungssystemen zu kommunizieren. Die ein oder mehreren Eingabegeräte 3970 ermöglichen dem Nutzer, Eingaben an das System zu liefern. Diese Eingabegeräte könnten ein Keypad, eine Tastatur, Touchpanel, Multitouchpanel etc. sein. Die optionalen anderen Eingabe/Ausgabe 3950 könnten ein Verbinder für ein Dock sein.
Die Techniken, die in den Figuren gezeigt sind, könnten unter Verwendung von Codes und Daten, die auf einem oder mehreren Computergeräten (z. B. Clientgeräten, Server etc.) gespeichert und ausgeführt werden, implementiert werden. Solche Computergeräte speichern und übermitteln (intern und/oder mit anderen Computergeräten über ein Netzwerk) Code (zusammengesetzt von Softwareanweisungen) und Daten unter Verwendung von maschinenlesbaren Medium, wie nicht vorübergehendes materielles maschinenlesbares Medium (z. B. maschinenlesbare Speichermedium wie eine magnetische Diskette; optische Diskette; Read-Only-Speicher; Flash Memory Geräte) und Transitory-Propagating Signals (z. B. elektrische, optische, akustische oder andere Formen von propagierten Signalen – wie Carrierwellen, Infrarotsignale, digitale Signale, etc.). Zusätzlich beinhalten solche Computergeräte typischerweise eine Reihe von einem oder mehreren Prozessoren, die mit einer oder mehreren anderen Komponenten verknüpft sind, wie ein oder mehrere nicht vorübergehende materielle maschinenlesbare Medien (um Code und/oder Daten zu speichern), Nutzereingabe/Ausgabegeräte (z. B. eine Tastatur, ein Touchscreen und/oder ein Display) und Netzwerkverbindungen (um Code und/oder Daten unter Verwendung von Transitory propagierende Signale zu übermitteln). Die Verknüpfung von einer Reihe von Prozessoren und anderen Komponenten erfolgt typischerweise durch einen oder mehrere Busse und Brücken (auch als Bussteuerungen bezeichnet). Somit speichert ein nicht vorübergehendes materielles maschinenlesbares Medium eines gegebenen Computergeräts typischerweise Anweisungen zur Ausführung auf der Reihe von einem oder mehreren Prozessoren in diesem Computergerät. Ein oder mehrere Teile von einer Ausführungsform könnten implementiert werden unter Verwendung von verschiedenen Kombinationen von Software, Firmware und/oder Hardware.
Während Abläufe hier im Zusammenhang mit automatischer Validierung einer Emailadresse beschrieben worden sind, ohne dass gefordert wird, dass ein Nutzer einen Link, der in einer Validierungsemailnachricht enthalten ist, klickt, in Bezug zur Validierung eine Emailadresse für die Verwendung als ein Online-Kommunikationssitzungsendpunktkennung, sind die Ausführungsformen nicht auf diese Weise beschränkt. Zum Beispiel in manchen Ausführungsformen werden die Abläufe, die im Zusammenhang mit automatischer Validierung einer Emailadresse beschrieben wurden, ausgeführt, wenn eine Emailadresse aus anderen Gründen validiert werden muss. Zum Beispiel könnte ein Nutzer sich für einen Dienst registrieren, der erfordert, dass eine Emailadresse als zu diesem Nutzer gehörig validiert wird als Teil des Registrierungsprozesses. Der Nutzer liefert die Emailadresse an den Dienst und empfängt eine Nachricht (z. B. durch die Anzeige der Webpage des Dienstes), die anzeigt, dass die Emailadresse validiert werden muss, und dass die Validierungsemailnachricht verwendet worden ist oder an die Emailadresse, die bereitgestellt wurde, gesendet wird (die Validierungsemailnachricht könnte einen Validierungslink beinhalten oder auch nicht). Eine Anwendung auf dem Client-Gerät könnte automatisch einen Emailaccount überprüfen, der zu der Emailadresse für die Validierungsnachricht gehört und wenn es lokalisiert ist, automatisch die Nachricht analysieren, um einen Validierungstoken zu lokalisieren und die Emailadressvalidierungsnachricht, die die Emailadresse beinhaltet und den Validierungstoken an den Emailvalidierungsserver, der mit dem Dienst verknüpft ist, übermitteln, um die Emailadresse zu validieren. Während die Flussdiagramme in den Figuren eine bestimmte Reihenfolge von Abläufen zeigt, die durch bestimmte Ausführungsformen durchgeführt werden, versteht sich, dass eine solche Reihenfolge beispielhaft ist (z. B. alternative Ausführungsformen könnten die Abläufe in einer anderen Reihenfolge durchführen, bestimmte Abläufe kombinieren, bestimmte Abläufe überlappen, etc.).
Während die Erfindung in Form von verschiedenen Ausführungsformen beschrieben worden ist, wird der Fachmann erkennen, dass die Erfindung nicht auf die beschriebenen Ausführungsformen beschränkt ist, sondern mit Modifikationen und Änderungen im Rahmen der angehängten Ansprüche praktiziert werden können. Die Beschreibung muss daher als illustrativ anstelle von beschränkend angesehen werden.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

Headset Profile (HSP) 1.2 Spezifikation vom 18. Dezember 2008 [0208]
Freisprechprofil 1.5 (HFP 1.5) Beschreibung von 25. November 2005 [0208]

Claims

Ein Verfahren durchgeführt auf einem Clientgerät für den Übergang zwischen einem leitungsvermittelnden Audiogespräch und einem Videogespräch, wobei das Clientgerät eine Frontkamera zur Aufnahme von Video für das Videogespräch umfasst, das Verfahren umfassend: Empfangen von Eingaben von einem Nutzer des Clientgerät, das es von einem aufgebauten leitungsvermittelnden Audiogespräch zu einem Videogespräch übergeht, wobei das aufgebaute leitungsvermittelte Audiogespräch eine Vielzahl von Teilnehmern, einschließlich den Nutzer des Clientgeräts, hat, um eine Reihe von einer oder mehreren entfernten Teilnehmern bei einer Reihe von einem oder mehreren Clientgeräten hat; Veranlassen, dass eine Videogesprächseinladungsnachricht zu einer Reihe von anderen Clientgeräten entfernten Teilnehmern ermittelt wird; Empfangen einer Videogesprächsannahmenachricht von der Reihe von anderen Clientgeräten von der Reihe von entfernten Teilnehmern; Ermitteln von Video, das durch die Frontkamera des Clientgeräts aufgenommen wurde, an eine Reihe von anderen Clientgeräten der Reihe von entfernten Teilnehmern; als Antwort auf den Empfang von mindestens einem Videoframe von jedem der Reihe von anderen Clientgeräten der Reihe von entfernten Teilnehmern, übergehen von dem leitungsvermittelnden Audiogespräch zu dem Videogespräch.
Das Verfahren nach Anspruch 1, weiter umfassend: Fallenlassen des leitungsvermittelnden Audiogesprächs als Antwort auf den erfolgreichen Übergang zu dem Videogespräch.
Das Verfahren nach Anspruch 1, weiter umfassend: als Antwort auf die Ermittlung, dass Audio derzeit über ein Empfängerlautsprecher des Clientgeräts geroutet wird, routen von Audio über ein Lautsprechertelefon des Clientgeräts.
Das Verfahren nach Anspruch 1, weiter umfassend: Anzeigen einer Videovorschau, die durch die Fronkamera des Clientgeräts aufgenommen wurde.
Das Verfahren nach Anspruch 1, wobei Übergang von dem leitungsvermittelnden Audiogespräch zu dem Videogespräche die Durchführung des folgenden umfasst: Anzeigen eines Videos, das von der Reihe von anderen Clientgeräten und einer Reihe von entfernten Teilnehmern empfangen worden ist; und Wechseln der Audioroute von dem leitungsvermittelnden Audiogespräch zu dem Videogespräch.
Verfahren nach Anspruch 1, weiter umfassend: Aufbauen einer direkten Peer-to-peer (P2P) Verbindung mit der Reihe von anderen Clientgeräten, wobei das Video über die P2P-Verbindung übermittelt wird.
Ein nicht vorübergehendes materielles maschinenlesbares Medium, das Anweisungen zur Verfügung stellt, die, wenn durch einen Prozessor ausgeführt, den genannten Prozessor zu veranlassen, werden Abläufe für den Übergang zwischen einem leitungsvermittelnden Audiogespräch und einem Videogespräch durchzuführen, Abläufe umfassen: Empfangen von Eingaben von einem Nutzer einem Clientgerät, das es von einem aufgebauten leitungsvermittelnden Audiogespräch zu einem Videogespräch übergeht, wobei das aufgebaute leitungsvermittelnde Audiogespräch einen Vielzahl von Teilnehmern einschließlich dem Nutzer des Clientgeräts und einer Reihe von ein oder mehreren entfernten Teilnehmern bei einer Reihe von ein oder mehreren Clientgeräten hat; Veranlassen, dass eine Videogesprächseinladungsnachricht an eine Reihe von anderen Clientgeräten und eine Reihe von entfernten Teilnehmern übermittelt wird; Empfangen einer Videogesprächsannahmenachricht von einer Reihe von anderen Clientgeräten; Übermitteln von Video, aufgenommen durch die Frontkamera des Clientgeräts an eine Reihe von anderen Clientgeräten der Reihe von entfernten Teilnehmern; und als Antwort auf das Empfangen mindestens einen Videoframes von jedem der Reihe von anderen Clientgeräten der Reihe von entfernten Teilnehmern, übergehend von dem leitungsvermittelnden Audiogespräch zu dem Videogespräch.
Nicht vorübergehendes materielles maschinenlesbares Medium nach Anspruch 7, wobei die Abläufe weiter umfassen: Fallenlassen des leitungsvermittelnden Audiogesprächs als Antwort auf einen erfolgreichen Übergang zu dem Videogespräch.
Nicht vorübergehendes materielles maschinenlesbares Medium nach Anspruch 7, wobei die Abläufe weiter umfassen: als Antwort auf die Ermittlung, dass Audio derzeit durch einen Empfängerlautsprecher des Clientgeräts geroutet wird, routen von Audio durch einen Telefonlautsprecher des Clientgeräts.
Nicht vorübergehendes materielles maschinenlesbares Medium nach Anspruch 7, wobei die Abläufe weiter umfassen: Anzeigen einer Videovorschau, aufgenommen durch Frontkamera des Clientgeräts.
Das nicht vorübergehende materielle maschinenlesbare Medium nach Anspruch 7, wobei der Übergang von dem leitungsvermittelnden Audiogespräch zu dem Videogespräch das Durchführen des folgenden umfasst: Anzeigen eines Videos, das von einer Reihe von anderen Clientgeräten der Reihe von entfernten Teilnehmern empfangen worden ist; und Wechselns einer Audioroute von dem leitungsvermittelnden Audiogespräch zu dem Videogespräch.
Nicht vorübergehendes materielles maschinenlesbares Medium nach Anspruch 7, wobei die Abläufe weiter umfassen: Aufbauen einer Peer-to-peer (P2P) Verbindung mit der Reihe von anderen Clientgeräten, wobei das Video über die P2P-Verbindung übermittelt wird.
Ein Verfahren, durchgeführt auf einem Clientgerät für den Übergang zwischen einem leitungsvermittelnden Audiogespräch zu einem Videogespräch, wobei das Clientgerät eine Frontkamera umfasst, um Video für das Videogespräch aufzunehmen, das Verfahren umfassend: Empfangen einer Videogesprächseinladungsnachricht zeugt von einem Clientgerät eines entfernten Teilnehmers des leitungsvermittelnden Audiogesprächs; Empfangen von Eingaben von einem Nutzer, um die Videogesprächseinladung anzunehmen; Veranlassen, dass eine Videogesprächseinladungsannahmenachricht an das Clientgerät des entfernten Teilnehmers übermittelt wird; Übermitteln eines Videos, aufgenommen durch die Frontkamera an ein Clientgerät des entfernten Teilnehmers; und als Antwort auf den Empfang mindestens eines Videoframes von dem Clientgeräten des entfernten Teilnehmers, übergehen von dem leitungsvermittelnden Audiogespräch zu dem Videogespräch.
Das Verfahren nach Anspruch 13, weiter umfassend: Fallenlassen des leitungsvermittelnden Audiogesprächs als Antwort auf den erfolgreichen Übergang zu dem Videogespräch.
Das Verfahren nach Anspruch 13, weiter umfassend: als Antwort auf die Ermittlung, das Audio derzeit durch einen Empfängerlautsprecher des Clientgeräts geroutet wird, routen Audio durch einen Telefonlautsprecher des Clientgeräts.
Das Verfahren nach Anspruch 13, weiter umfassend: Anzeigen einer Videovorschau, aufgenommen durch die Frontkamera.
Verfahren nach Anspruch 13, wobei Übergang von dem leitungsvermittelnden Audiogespräch zu dem Videogespräch Durchführung des folgenden umfasst: Anzeigen des Videos, das von den Clientgeräten der entfernten Teilnehmer empfangen worden ist; und Ändern einer Audioroute von dem leitungsvermittelnden Audiogespräch zu dem Videogespräch.
Das Verfahren nach Anspruch 13, weiter umfassend: Aufbauen einer direkten Peer-to-peer (P2P) Verbindung mit dem Clientgerät des Teilnehmers, wobei das Video über die P2P-Verbindung übermittelt wird.
Nicht vorübergehendes materielles maschinenlesbares Medium eines Clientgeräts, das Anweisungen zur Verfügung stellt, die, wenn ein Prozessor des Clientgeräts ausgeführt, den genannten Prozessor dazu veranlassen werden, Abläufe für den Übergang zwischen einem leitungsvermittelnden Audiogespräch und einem Videogespräch durchzuführen, die Abläufe umfassend: Empfangen einer Videogesprächseinladungsnachricht, die von einem Clientgerät eines entfernten Teilnehmers des leitungsvermittelnden Audiogesprächs stammt; Empfangen von Eingaben von einem Nutzer, um die Videogesprächseinladung anzunehmen; Veranlassen, dass die Videogesprächseinladungsannahmenachricht an das Clientgerät des entfernten Teilnehmers übermittelt wird; Übermitteln von Video, aufgenommen durch die Kamera des Clientgeräts an das Clientgerät des entfernten Teilnehmers; und als Antwort auf das Empfangen von mindestens eines Frames von Video von dem Clientgeräten des entfernten Teilnehmers, Übergang von dem leitungsvermittelnden Audiogespräch zu dem Videogespräch.
Nicht vorübergehendes materielles maschinenlesbares Medium nach Anspruch 19, wobei die Abläufe weiter umfassen: Fallenlassen des leitungsvermittelnden Audiogesprächs Antwort auf den erfolgreichen Übergang zu dem Videogespräch.
Nicht vorübergehendes materielles maschinenlesbares Medium nach Anspruch 19, wobei die Abläufe weiter umfassen: als Antwort auf die Ermittlung, dass Audio derzeit durch ein Empfängerlautsprecher eines Clientgerät geroutet wird, ändern einer Audioroute, um Audio durch einen Telefonlautsprecher des Clientgeräts zu routen.
Nicht vorübergehendes materielles maschinenlesbares Medium nach Anspruch 19, wobei die Abläufe weiter umfassen: Anzeigen einer Videovorschau, aufgenommen durch die Frontkamera.
Nicht vorübergehendes materielles maschinenlesbares Medium nach Anspruch 19, wobei der Übergang von dem leitungsvermittelnden Audiogespräch zu dem Videogespräch die Durchführung des folgenden umfasst: Anzeigen eines Videos, das von dem Clientgerät des entfernten Teilnehmers empfangen worden ist; und Ändern einer Audioroute von dem leitungsvermittelnden Audiogesprächs zu dem Videogespräch.
Nicht vorübergehendes materielles maschinenlesbares Medium nach Anspruch 19, wobei die Abläufe weiter umfassen: Aufbauen einer direkten Peer-to-peer (P2P) Verbindung mit dem Clientgerät des Teilnehmers, wobei das Video über die P2P-Verbindung übermittelt wird.
Ein Clientgerät für den Übergang zwischen einem leitungsvermittelnden Audiogespräch und einem Videogespräch, das Clientgerät umfassend: eine Frontkamera zum Aufnehmen von Video für das Videogespräch; einen drahtlosen Transceiver für das Kommunizieren mit anderen Clientgeräten; einen Speicher, um Programmcodes zu speichern; ein Prozessor, der mit dem Speicher verknüpft ist, um den Programmcode zu verarbeiten: Empfang von Eingaben von einem Nutzer des Clientgerät zum Übergang von einem aufgebauten leitungsvermittelnden Audiogespräch zu einem Videogespräch, wobei das aufgebaute leitungsvermittelte Audiogespräch eine Vielzahl von Teilnehmern hat, einschließlich dem Nutzer des Clientgeräts und eine Reihe von einem oder mehreren entfernten Teilnehmern bei einer Reihe von ein oder mehreren Clientgeräten; Veranlassen, dass eine Videogesprächseinladungsnachricht an die Reihe von anderen Clientgeräten der entfernten Teilnehmer übermittelt wird; Empfangen einer Videogesprächsannahmenachricht von der Reihe von anderen Clientgeräten der Reihe von entfernten Teilnehmern; Übermitteln ein Video, aufgenommen durch die Frontkamera an die Reihe von anderen Clientgeräten Reihe von entfernten Teilnehmern; und als Antwort auf den Empfang von mindestens einem Videoframe von jeder der Reihe von anderen Clientgeräten der Reihe von entfernten Teilnehmern, Übergang von dem leitungsübermittelnden Audiogespräch zu dem Videogespräch.
Das Clientgerät nach Anspruch 25, wobei der Prozessor weiter dazu bestimmt ist: Das leitungsvermittelnde Audiogespräch als Antwort auf einen erfolgreichen Übergang zu dem Videogespräch fallen zu lassen.
Das Clientgerät nach Anspruch 25, weiter umfassend: Einen Empfängerlautsprecher, um ein Ausgangsaudiosignal zu liefern; ein Lautsprechertelefon, um ein Ausgangsaudiosignal zu liefern; wobei der Prozessor weiter dazu bestimmt ist, in Antwort auf eine Ermittlung, dass Audio derzeit durch den Empfängerlautsprecher geroutet wird, Audio durch den Telefonlautsprecher zu routen.
Das Clientgerät nach Anspruch 25, wobei der Prozessor weiter dazu bestimmt ist: Eine Videovorschau, aufgenommen durch die Frontkamera des Clientgeräts auf dem Display anzuzeigen.
Das Clientgerät nach Anspruch 25, wobei der Prozessor für den Übergang von dem leitungsvermittelnden Audiogespräch zu dem Videogespräch umfasst, dass der Prozessor: Video anzeigt, dass von der Reihe von anderen Clientgeräten der Reihe von entfernten Teilnehmern genommen worden ist; und Ändern einer Audioroute von dem leitungsvermittelnden Audiogesprächs zu dem Videogespräch.
Das Clientgerät nach Anspruch 25, wobei der Prozessor weiter dazu bestimm ist: Eine direkte Peer-to-peer (P2P) Verbindung mit der Reihe von anderen Clientgeräten aufzubauen, wobei das Video über die P2P-Verbindung übermittelt wird.
Ein Clientgerät für den Übergang zwischen einem leitungsvermittelnden Audiogespräch und einem Videogespräch, das Clientgerät umfassend: Eine Frontkamera zum Aufnehmen von Video für das Videogespräch; einen drahtlosen Transceiver zur Kommunikation mit anderen Clientgeräten; ein Speicher zum Speichern von Programmcode; ein Prozessor, verknüpft mit Speicher, um den Programmcode zu verarbeiten, um zu: eine Videogesprächseinladungsnachricht, erzeugt von einem Clientgerät eines entfernten Teilnehmers des leitungsvermittelnden Audiogesprächs zu empfangen; Empfangen von Eingaben von einem Nutzer, um die Videogesprächseinladung anzunehmen; Veranlassen, dass eine Videogesprächseinladungsannahmenachricht an das Clientgerät des entfernten Teilnehmers übermittelt wird; Übermitteln von Video, aufgenommen durch die Frontkamera an das Clientgerät des entfernten Teilnehmers; und als Antwort auf den Empfang von mindestens einem Frame von Video von dem Clientgerät des entfernten Teilnehmers, Übergang von dem leitungsvermittelnden Audiogespräch zu dem Videogespräch.
Das Clientgerät nach Anspruch 31, wobei der Prozessor weiter dazu bestimmt ist: Das leitungsvermittelte Audiogespräch in Antwort auf den erfolgreichen Übergang zu dem Videogespräch fallenzulassen.
Clientgerät nach Anspruch 31, weiter umfassend: Ein Empfängerlautsprecher, um ein Ausgangsaudiosignal zu liefern; ein Lautsprechertelefonlautsprecher, um ein Ausgangsaudiosignal zu liefern, wobei der Prozessor weiter dazu bestimmt ist, in Antwort auf die Ermittlung, das Audio derzeit durch den Empfängerlautsprecher geroutet wird, Audio durch den Lautsprechertelefonlautsprecher zu routen.
Clientgerät nach Anspruch 31, wobei der Prozessor weiter dazu bestimmt ist, eine Videovorschau, aufgenommen durch die Frontkamera, anzuzeigen.
Clientgerät nach Anspruch 31, wobei der Prozessor für den Übergang von dem leitungsvermittelnden Audiogespräch zu dem Videogespräch umfasst, dass der Prozessor: Video anzeigt, das von dem Clientgerät des entfernten Teilnehmers aufgenommen worden ist; und Ändern einer Audioroute von dem leitungsvermittelnden Audiogespräch zu dem Videogespräch.
Clientgerät nach Anspruch 31, wobei der Prozessor weiter dazu bestimmt ist: Eine direkte Peer-to-peer (P2P) Verbindung mit dem Clientgerät des Teilnehmers aufzubauen, wobei das Video über die P2P-Verbindung ermittelt wird.