DE60132433T2

DE60132433T2 - Sofortige nachrichtenübermittlung mit zusätzlicher sprachkommunikation

Info

Publication number: DE60132433T2
Application number: DE60132433T
Authority: DE
Inventors: Shuwu Foothill Ranch WU; James Belmont CRAWFORD
Original assignee: America Online Inc
Current assignee: Historic AOL LLC
Priority date: 2000-03-17
Filing date: 2001-03-19
Publication date: 2008-12-24
Anticipated expiration: 2021-03-20
Also published as: EP1264469B1; CN1448019A; CA2403520A1; CA2403520C; JP2003528543A; US9356891B2; US20130073650A1; US20110320553A1; ATE384399T1; EP1264469A2; US20020023131A1; US20130073649A1; US9049159B2; US8041768B2; US8429231B2; WO2001072020A2; DE60132433D1; AU2001245826A1; US20130080550A1; CN100401733C

Description

Die vorliegende Erfindung betrifft allgemein das Transferieren von Daten zwischen Teilnehmern eines Kommunikationssystems und insbesondere das Transferieren von Audiodaten zwischen Teilnehmern eines Instant-Messaging-Host.
Online-Service-Provider bieten ständig neue Dienste an und verbessern die existierenden Dienste, um das Online-Erlebnis ihrer Teilnehmer zu steigern. Teilnehmer haben On-Demand-Zugang zu Nachrichten, Wetter, Finanzen, Sport und Unterhaltungsdiensten sowie die Fähigkeit, elektronische Nachrichten zu übertragen und an Online-Diskussionsgruppen teilzunehmen. Beispielsweise können Teilnehmer von Online-Service-Providern wie etwa America Online oder CompuServe Informationen über eine große Vielfalt von Themen von Servern auf der ganzen Welt betrachten und abrufen. Ein Server kann durch den Service-Provider oder durch Fremd-Provider gepflegt werden, der Informationen und Dienste durch das weltweite Netz von Computer zur Verfügung stellt, die den Online-Dienst ausmachen.
America Online hat Teilnehmern die Fähigkeit gegeben, Instant-Messages zu senden und zu empfangen. Instant-Messages sind private Online-Unterhaltungen zwischen zwei oder mehr Menschen, die den Instant-Messaging-Service abonniert und die erforderliche Software installiert haben. Weil solche Online-Unterhaltungen im Wesentlichen in Echtzeit stattfinden, kann Instant-Messaging sofortigen Zugang zu gewünschten Informationen bereitstellen. Instant-Messaging wird ein bevorzugtes Mittel zum Kommunizieren unter Online-Teilnehmern.
Aus US 5,848,134 , über das die unabhängigen Ansprüche gekennzeichnet sind, ist ein System bekannt, das eine grafische Benutzerschnittstelle verwendet, die es Benutzern ermöglicht, an einem Echtzeit-Voice-Chat mit anderen Menschen in einem elektronischen Konferenzraum teilzunehmen.
Aus WO 00/60809 ist ein System zum Herstellen einer Audiokonferenz in einer vernetzten Umgebung bekannt. Ein Benutzer kann eine grafische Benutzerschnittstelle zum Herstellen einer Konferenz mit anderen Benutzern verwenden.
Gemäß einem Aspekt der vorliegenden Erfindung wird ein Kommunikationsverfahren, wie in Anspruch 1 beansprucht, bereitgestellt.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird eine Kommunikationsvorrichtung, wie in Anspruch 22 beansprucht, bereitgestellt.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird ein auf einem computerlesbaren Medium gespeichertes Computerprogramm, wie in Anspruch 25 beansprucht, bereitgestellt.
Elektronische Daten werden zwischen Benutzern eines Kommunikationssystems transferiert, indem Instant-Messaging-Kommunikation zwischen einem Sender und mindestens einem Empfänger durch einen Instant-Messaging-Host ermöglicht wird. Zusätzlich wird durch den Instant-Messaging-Host eine Sprachkommunikation zwischen dem Sender und dem Empfänger ermöglicht.
Implementierungen können eines oder mehrere der folgenden Merkmale enthalten. Beispielsweise können Implementierungen Folgendes beinhalten: Empfangen und Authentisieren einer Text-Instant-Message von dem Sender bei dem Instant-Messaging-Host; Bestimmen von Fähigkeiten des Empfängers; Melden der Fähigkeiten des Empfängers; Empfangen einer Anforderung zum Herstellen einer Sprachkommunikation von dem Sender und/oder dem Empfänger; und/oder Authentisieren der Anforderung. Das Authentisieren kann das Identifizieren eines Schirmnamens und/oder einer IP-Adresse des Senders und/oder des Empfängers beinhalten. Das Bestimmen von Fähigkeiten des Empfängers kann das Identifizieren von Hardware oder Software, die mit dem Empfänger assoziiert ist, beinhalten. Eine Benutzerschnittstelle kann gemäß den Fähigkeiten des Empfängers angezeigt werden.
Sprachkommunikation kann ermöglicht werden durch Herstellen eines generischen Zeichengebungsschnittstellenkanals, eines Steuerkanals und eines Audiokanals zwischen dem Sender und dem Empfänger. Ein Modus-UDP-Test kann auf dem Audiokanal versucht werden. Der Steuerkanal kann eine TCP/IP-Socket enthalten. Der Audiokanal kann einen UDP- oder TCP-Kanal enthalten.
Das computerlesbare Medium kann eine Disc, eine Client-Einrichtung, eine Host-Einrichtung und/oder ein verbreitetes Signal sein.
Andere Merkmale und Vorteile ergeben sich aus der folgenden Beschreibung bevorzugter Ausführungsformen einschließlich der Zeichnungen und aus den Ansprüchen.
1 ist ein Blockdiagramm eines Kommunikationssystems.
2–5 sind Erweiterungen des Blockdiagramms von 1.
6 ist ein Flussdiagramm eines Kommunikationsverfahrens, das durch die Systeme der 1–5 implementiert werden kann.
7–10 sind Darstellungen unterschiedlicher grafischer Benutzerschnittstellen, die von den Systemen der 1–5 bereitgestellt werden können.
Zu Veranschaulichungszwecken beschreiben die 1–5 ein Kommunikationssystem zum Implementieren von Techniken zum Transferieren elektronischer Daten. Der Kürze halber werden mehrere Elemente in den unten beschriebenen Figuren als monolithische Entitäten dargestellt. Wie der Fachmann jedoch verstehen würde, können diese Elemente jeweils zahlreiche zusammengeschaltete Computer und Komponenten enthalten, die dafür ausgelegt sind, einen Satz spezifizierter Operationen auszuführen und/oder einem jeweiligen geografischen Gebiet zugewiesen sind.
Unter Bezugnahme auf 1 ist ein Kommunikationssystem 100 in der Lage, Daten zwischen einem Client-System 105 und einem Host-System 110 durch eine Kommunika tionsstrecke 115 zu übergeben und auszutauschen. Das Client-System 105 enthält in der Regel eine oder mehrere Client-Einrichtungen 120 und/oder Client-Controller 125. Beispielsweise kann das Client-System 105 einen oder mehrere Allzweckcomputer (z. B. PCs), einen oder mehrere Spezialrechner (z. B. Einrichtungen, die spezifisch programmiert sind, miteinander und/oder dem Host-System 110 zu kommunizieren) oder eine Kombination aus einem oder mehreren Allzweckcomputern und einem oder mehreren Spezialcomputern enthalten. Das Client-System 105 kann ausgelegt sein, innerhalb eines oder mehrerer anderer Systeme oder mit diesen zusammenzuarbeiten, wie beispielsweise einem oder mehreren LANs ("Local Area Networks") und/oder einem oder mehreren WANs ("Wide Area Networks").
Die Client-Einrichtung 120 ist im Allgemeinen in der Lage, unter dem Befehl eines Client-Controller 125 Anweisungen auszuführen. Die Client-Einrichtung 120 ist durch einen verdrahteten oder drahtlosen Datenweg 130, der in der Lage ist, Daten zu übergeben, mit dem Client-Controller 125 verbunden.
Die Client-Einrichtung 120 und der Client-Controller 125 enthalten jeweils in der Regel eine oder mehrere Hardwarekomponenten und/oder Softwarekomponenten. Ein Beispiel für eine Client-Einrichtung 120 ist ein Allzweckcomputer (z. B. ein PC), der auf definierte Weise auf Anweisungen reagieren und sie ausführen kann. Zu anderen Beispielen zählen ein Spezialcomputer, eine Workstation, ein Server, eine Einrichtung, eine Komponente, andere Geräte oder eine gewisse Kombination davon, die auf Anweisungen reagieren und sie ausführen können. Ein Beispiel für einen Client-Controller 125 ist eine auf die Client-Einrichtung 120 geladene Softwareanwendung zum Befehlen und Anleiten von Kommunikation, die durch die Client-Einrichtung 120 ermöglicht wird. Zu weiteren Beispielen zählen ein Programm, ein Code-Teil, eine Anweisung, eine Einrichtung, ein Computer, ein Computersystem oder eine Kombination davon, um die Client-Einrichtung 120 unabhängig oder kollektiv anzuweisen, wie hierin beschrieben zu interagieren und zu arbeiten. Der Client-Controller 125 kann permanent oder temporär in irgendeiner Art von Maschine, Komponente, Gerät, Speichermedium oder verbreitetem Signal verkörpert sein, die in der Lage sind, Anweisungen an die Client-Einrichtung 120 zu übergeben.
Die Kommunikationsstrecke 115 enthält in der Regel ein Übergabenetz 160, das eine direkte oder indirekte Kommunikation zwischen dem Client-System 105 und dem Host-System 110 unabhängig vom physischen Abstand herstellt. Zu Beispielen für ein Übergabenetz 160 zählen das Internet, das World Wide Web, WANs, LANs, analoge oder digitale verdrahtete oder drahtlose Telefonnetze (z. B. PSTN, ISDN oder xDSL), Radio, Fernsehen, Kabel, Satellit und/oder irgendein anderer Übergabemechanismus zum Tragen von Daten. Die Kommunikationsstrecke 115 kann Kommunikationswege 150, 155 enthalten, die eine Kommunikation durch das eine oder die mehreren oben beschriebenen Übergabenetze 160 ermöglichen. Jeder der Kommunikationswege 150, 155 kann beispielsweise einen verdrahteten, drahtlosen, Kabel- oder Satellitenkommunikationsweg enthalten.
Das Host-System 110 enthält eine Host-Einrichtung 135, die unter dem Befehl und der Anleitung eines Host-Controller 140 Anweisungen ausführen kann. Die Host-Einrichtung 135 ist durch einen verdrahteten oder drahtlosen Datenweg 145, der Daten führen und übergeben kann, an den Host-Controller 140 angeschlossen.
Das Host-System 110 enthält in der Regel eine oder mehrere Host-Einrichtungen 135 und/oder Host-Controller 140. Beispielsweise kann das Host-System 110 einen oder mehrere Allzweckcomputer (z. B. PCs), einen oder mehrere Spezialcomputer (z. B. Einrichtungen, die spezifisch programmiert sind, miteinander und/oder dem Client-System 105 zu kommunizieren) oder eine Kombination aus einem oder mehreren Allzweckcomputern und einem oder mehreren Spezialcomputern enthalten. Das Host-System 110 kann ausgelegt sein, innerhalb eines oder mehrerer anderer Systeme oder mit diesen zusammenzuarbeiten, wie beispielsweise einem oder mehreren LANs ("Local Area Networks") und/oder einem oder mehreren WANs ("Wide Area Networks").
Die Host-Einrichtung 135 und der Host-Controller 140 enthalten jeweils in der Regel eine oder mehrere Hardwarekomponenten und/oder Softwarekomponenten. Ein Beispiel für eine Host-Einrichtung 135 ist ein Allzweckcomputer (z. B. ein PC), der auf definierte Weise auf Anweisungen reagieren und sie ausführen kann. Zu anderen Beispielen zählen ein Spezialcomputer, eine Workstation, ein Server, eine Einrichtung, eine Komponente, andere Geräte oder eine gewisse Kombination davon, die auf Anweisungen reagieren und sie ausführen können. Ein Beispiel für einen Host-Controller 140 ist eine auf die Host-Einrichtung 135 geladene Softwareanwendung zum Befehlen und Anleiten von Kommunikation, die durch die Host-Einrichtung 135 ermöglicht wird. Zu weiteren Beispielen zählen ein Programm, ein Code-Teil, eine Anweisung, eine Einrichtung, ein Computer, ein Computersystem oder eine Kombination davon, um die Host-Einrichtung 135 unabhängig oder kollektiv anzuweisen, wie hierin beschrieben zu interagieren und zu arbeiten. Der Host-Controller 140 kann permanent oder temporär in irgendeiner Art von Maschine, Komponente, Gerät, Speichermedium oder verbreitetem Signal verkörpert sein, die in der Lage sind, Anweisungen an die Host-Einrichtung 135 zu übergeben.
2 veranschaulicht ein Kommunikationssystem 200, das ein Client-System 205 enthält, das mit einem Host-System 210 durch eine Kommunikationsstrecke 215 kommuniziert. Das Client-System 205 enthält in der Regel eine oder mehrere Client-Einrichtungen 220 und einen oder mehrere Client-Controller 225 zum Steuern der Client-Einrichtungen 220. Das Host-System 210 enthält in der Regel eine oder mehrere Host-Einrichtungen 235 und einen oder mehrere Host-Controller 240 zum Steuern der Host-Einrichtungen 235. Die Kommunikationsstrecke 215 kann Kommunikationswege 250, 255 enthalten, die eine Kommunikation durch das eine oder die mehreren Übergabenetze 260 ermöglichen.
Beispiele für jedes Element innerhalb des Kommunikationssystems von 2 sind oben unter Bezugnahme auf 1 allgemein beschrieben. Insbesondere besitzen das Host-System 210 und die Kommunikationsstrecke 215 in der Regel Attribute, die jenen vergleichbar sind, die unter Bezugnahme auf das Host-System 110 und die Kommunikationsstrecke 115 von 1 beschrieben sind. Gleichermaßen weist das Client-System 205 von 2 in der Regel Attribute auf, die vergleichbar sind mit einer möglichen Ausführungsform des Client-Systems 105 von 1 und veranschaulichen diese.
Die Client-Einrichtung 220 enthält in der Regel einen Allzweckcomputer 270 mit einem internen oder externen Speicher 272 zum Speichern von Daten und Programmen, wie etwa ein Betriebssystem 274 (z. B. DOS, Windows^TM, Windows 95^TM, Windows 98^TM, Windows 2000^TM, Windows NT^TM, OS/2 oder Linux) und ein oder mehrere Anwendungsprogramme. Zu Beispielen für Anwendungsprogramme zählen Authoring-Anwendungen 276 (z. B. Textverarbeitung, Datenbankprogramme, Tabellenkalkulationsprogramme oder Grafikprogramme), die in der Lage sind, Dokumente oder einen anderen elektronischen Inhalt zu generieren; Client-Anwendungen 278 (z. B. AOL-Client, CompuServe-Client, AIM-Client, AOL-TV-Client oder ISP-Client), die in der Lage sind, mit anderen Computerbenutzern zu kommunizieren, auf verschiedene andere Computerressourcen zuzugreifen und elektronischen Inhalt zu betrachten, herzustellen oder auf andere Weise zu manipulieren; und Browser-Anwendungen 280 (z. B. der Navigator von Netscape oder der Internet Explorer von Microsoft), die in der Lage sind, standardmäßigen Internetinhalt wiederzugeben.
Der Allzweckcomputer 270 enthält auch eine zentrale Verarbeitungseinheit 282 (CPU) zum Ausführen von Anweisungen als Reaktion auf Befehle von dem Client-Controller 225. Bei einer Implementierung enthält der Client-Controller 225 eines oder mehrere der auf dem internen oder externen Speicher 272 des Allzweckcomputers 270 installierte Anwendungsprogramme. Bei einer anderen Implementierung enthält der Client-Controller 225 Anwendungsprogramme, die extern in einer oder mehreren Einrichtungen außerhalb des Allzweckcomputers 270 gespeichert und ausgeführt werden.
Der Allzweckcomputer enthält in der Regel eine Kommunikationseinrichtung 284 zum Senden und Empfangen von Daten. Ein Beispiel für die Kommunikationseinrichtung 284 ist ein Modem. Zu anderen Beispielen zählen ein Sendeempfänger, eine Set-Top-Box, eine Kommunikationskarte, eine Satellitenschüssel, eine Antenne oder irgendein anderer Netzadapter, der Daten über die Kommunikationsstrecke 215 durch einen verdrahteten oder drahtlosen Datenweg 250 übertragen und empfangen kann. Der Allzweckcomputer 270 kann auch einen TV-("Television")-Tuner 286 zum Empfangen von Fernsehprogrammierung in Form von Rundsende-, Satelliten- und/oder Kabel-TV-Signalen enthalten. Folglich kann die Client-Einrichtung 220 von der Kommunikationseinrichtung 284 empfangenen Netzinhalt und von dem TV-Tuner 286 empfangenen Fernsehprogrammierinhalt selektiv und/oder simultan anzeigen.
Der Allzweckcomputer 270 enthält in der Regel eine Eingangs/Ausgangsschnittstelle 288 für eine verdrahtete oder drahtlose Verbindung mit verschiedenen Peripheriegeräten 290. Zu Beispielen für Peripheriegeräte 290 zählen unter anderem eine Maus 291, ein Mobiltelefon 292, ein PDA 293 (Personal Digital Assistant), eine Tastatur 294, ein Anzeigemonitor 295 mit oder ohne Touch-Screen-Eingabe, eine TV-Fernsteuerung 296 zum Empfangen von Informationen von und Wiedergeben von Informationen an Teilnehmer und eine Videoeingabeeinrichtung 298.
Wenngleich 2 Einrichtungen wie ein Mobiltelefon 292, einen PDA 293 und eine TV-Fernsteuerung 296 so darstellt, dass sie bezüglich des Allzweckcomputers 270 peripher sind, können bei einer anderen Implementierung solche Einrichtungen selbst die Funktionalität des Allzweckcomputers 270 enthalten und als die Client-Einrichtung 220 arbeiten. Beispielsweise kann das Mobiltelefon 292 oder der PDA 293 Rechen- und Netzfähigkeiten enthalten und als eine Client-Einrichtung 220 funktionieren durch Zugreifen auf das Übergabenetz 260 und Kommunizieren mit dem Host-System 210. Zudem kann das Client-System 205 eine, einige oder alle der oben beschriebenen Komponenten und Einrichtungen enthalten.
Unter Bezugnahme auf 3 ist ein Kommunikationssystem 300 in der Lage, Informationen zwischen einem Client-System 305 und einem Host-System 310 durch eine Kommunikationsstrecke 315 zu übergeben und auszutauschen. Das Client-System 305 enthält in der Regel eine oder mehrere Client-Einrichtungen 320 und einen oder mehrere Client-Controller 325 zum Steuern der Client-Einrichtungen 320. Das Host-System 310 enthält in der Regel eine oder mehrere Host-Einrichtungen 335 und einen oder mehrere Host-Controller 340 zum Steuern der Host-Einrichtungen 335. Die Kommunikationsstrecke 315 kann Kommunikationswege 350, 355 enthalten, wodurch eine Kommunikation durch das eine oder die mehreren Übergabenetze 360 ermöglicht wird.
Beispiele für jedes Element innerhalb des Kommunikationssystems von 3 sind oben unter Bezugnahme auf 1 und 2 allgemein beschrieben. Insbesondere besitzen das Client-System 305 und die Kommunikationsstrecke 315 in der Regel Attribute, die jenen vergleichbar sind, die unter Bezugnahme auf die Client-Systeme 105 und 205 und die Kommunikationsstrecken 115 und 215 der 1 und 2 beschrieben sind. Gleichermaßen kann das Host-System 310 von 3 in der Regel Attribute aufweisen, die vergleichbar sind mit einer möglichen Ausführungsform der Host-Systeme 110 und 210 der 1 bzw. 2, und veranschaulicht diese.
Das Host-System 310 enthält eine Host-Einrichtung 335 und einen Host-Controller 340. Der Host-Controller 340 ist im Allgemeinen in der Lage, Anweisungen an ein beliebiges oder alle der Elemente der Host-Einrichtung 335 zu übertragen. Beispielsweise enthält bei einer Implementierung der Host-Controller 340 eine oder mehrere, auf die Host-Einrichtung 335 geladene Softwareanwendungen. Bei anderen Implementierungen jedoch, wie oben beschrieben, kann der Host-Controller 340 eines von mehreren anderen Programmen, Maschinen und Einrichtungen enthalten, die unabhängig oder kollektiv arbeiten, um die Host-Einrichtung 335 zu steuern.
Die Host-Einrichtung 335 enthält einen Login-Server 370 zum Ermöglichen von Zugang durch Teilnehmer und Lenken von Kommunikation zwischen dem Client-System 305 und anderen Elementen der Host-Einrichtung 335. Die Host-Einrichtung 335 enthält auch verschiedene Host-Komplexe, wie etwa den dargestellten OSP-Host-Komplex 380 ("Online Service Provider") und den IM-Host-Komplex 390 ("Instant Messaging"). Um Zugang durch Teilnehmer zu diesen Host-Komplexen zu ermöglichen, enthält das Client-System 305 Kommunikationssoftware, beispielsweise eine OSP-Client-Anwendung und eine IM-Client-Anwendung. Die OSP- und IM-Kommunikationssoftwareanwendungen sind so ausgelegt, dass sie die Interaktionen des Teilnehmers mit den jeweiligen Diensten erleichtern und insbesondere Zugang zu allen innerhalb der jeweiligen Host-Komplexe verfügbaren Diensten bereitstellen können.
In der Regel unterstützt der OSP-Host-Komplex 380 verschiedene Dienste wie etwa E-Mail, Diskussionsgruppen, Chat, Nachrichtendienste und Internet-Zugang. Der OSP-Host-Komplex 380 ist im Allgemeinen mit einer Architektur ausgelegt, die es den Maschinen innerhalb des OSP-Host-Komplexes 380 ermöglicht, miteinander zu kommunizieren, und verwendet zum Transferieren von Daten bestimmte Protokolle (d. h. Normen, Formate, Konventionen, Regeln und Strukturen). Der OSP-Host-Komplex 380 verwendet gewöhnlicherweise ein oder mehrere OSP-Protokolle und kundenspezifische Dialing-Engines, um Zugang durch ausgewählte Client-Anwendungen zu ermöglichen. Der OSP-Host-Komplex 380 kann ein oder mehrere spezifische Protokolle für jeden Dienst auf der Basis eines gemeinsamen, zugrunde liegenden proprietären Protokolls definieren.
Der IM-Host-Komplex 390 ist im Allgemeinen von dem OSP-Host-Komplex 380 unabhängig und unterstützt Instant-Messaging-Dienste unabhängig von einem Teilnehmernetz oder Internetzugang. Somit gestattet der IM-Host-Komplex 390 Teilnehmern, Instant-Messages unabhängig davon zu senden und zu empfangen, ob sie Zugang zu einem bestimmten ISP besitzen oder nicht. Somit kann der IM-Host-Komplex 390 assoziierte Dienste wie etwa administrative Fragen, Werbung, Verzeichnisdienste, Chat und Interessengruppen, die sich auf Instant-Messaging beziehen, unterstützen. Der IM-Host-Komplex 390 besitzt eine Architektur, durch die alle Maschinen innerhalb des IM-Host-Komplexes miteinander kommunizieren können. Zum Transferieren von Daten verwendet der IM-Host-Komplex 390 ein oder mehrere standardmäßige oder exklusive IM-Protokolle.
Die Host-Einrichtung 335 kann ein oder mehrere Gateways enthalten, die Komplexe anschließen und deshalb verknüpfen, wie etwa das OSP-Host-Komplex-Gateway 385 und das IM-Host-Komplex-Gateway 395. Das OSP-Host-Komplex-Gateway 385 und das IM-Host-Komplex-Gateway 395 können den OSP-Host-Komplex 380 direkt oder indirekt durch einen verdrahteten oder drahtlosen Weg mit dem IM-Host-Komplex 390 verknüpfen. Das OSP-Host-Komplex-Gateway 385 und das IM-Host-Komplex-Gateway 395 sind gewöhnlich, wenn sie zum Ermöglichen einer Strecke zwischen Komplexen verwendet werden, in Informationen eingeweiht hinsichtlich des von dem Zielkomplex erwarteten Protokolltyps, wodurch eine etwaige erforderliche Protokollkonvertierung vor dem Transfer von Daten von einem Komplex zum anderen durchgeführt werden kann. Beispielsweise verwenden der OSP-Host-Komplex 380 und der IM-Host-Komplex 390 im Allgemeinen verschiedene Protokolle, so dass das Transferieren von Daten zwischen den Komplexen eine Protokollkonvertierung durch oder auf Anforderung durch das OSP-Host-Komplex-Gateway 385 und/oder das IM-Host-Komplex-Gateway 395 erfordert.
Unter Bezugnahme auf 4 ist ein Kommunikationssystem 400 in der Lage, Informationen über eine Kommunikationsstrecke 415 zwischen einem Client-System 405 und einem Host-System 410 zu übergeben und auszutauschen. Das Client-System 405 enthält in der Regel eine oder mehrere Client-Einrichtungen 420 und einen oder mehrere Client-Controller 425 zum Steuern der Client-Einrichtungen 420. Das Host-System 410 enthält in der Regel eine oder mehrere Host-Einrichtungen 435 und einen oder mehrere Host-Controller 440 zum Steuern der Host-Einrichtungen 435. Die Kommunikationsstrecke 415 kann Kommunikationswege 450, 455 enthalten, die eine Kommunikation durch das eine oder die mehreren Übergabenetze 460 ermöglichen. Wie gezeigt kann das Client-System 405 durch das Host-System 410 auf das Internet 465 zugreifen.
Beispiele jedes Elements innerhalb des Kommunikationssystems von 4 sind oben bezüglich 1–3 allgemein beschrieben. Insbesondere besitzen das Client-System 405 und die Kommunikationsstrecke 415 in der Regel Attribute, die denen vergleichbar sind, die bezüglich der Client-Systeme 105, 205 und 305 und Kommunikationsstrecken 115, 215 und 315 von 1–3 beschrieben sind. Gleichermaßen kann das Host-System 410 von 4 Attribute besitzen, die mit einer möglichen Ausführungsform der in 1–3 jeweils beschriebenen Host-Systeme 110, 210 und 310 vergleichbar sind, und veranschaulicht diese. 4 beschreibt jedoch eine Ausführungsform des Host-Systems 410, wobei in erster Linie auf eine bestimmte Implementierung des OSP-Host-Komplexes 480 fokussiert wird. Zu Zwecken der Kommunikation mit einem OSP-Host-Komplex 480 ist das Übergabenetz 460 im Allgemeinen ein Telefonnetz.
Das Client-System 405 enthält eine Client-Einrichtung 420 und einen Client-Controller 425. Der Client-Controller 425 ist im Allgemeinen zum Herstellen einer Verbindung zu dem Host-System 410 einschließlich dem OSP-Host-Komplex 480, dem IM-Host-Komplex 490 und/oder dem Internet 465 in der Lage. Bei einer Implementierung enthält der Client-Controller 425 eine OSP-Anwendung zum Kommunizieren mit Servern in dem OSP-Host-Komplex 480 unter Verwendung exklusiver OSP-Protokolle. Der Client-Controller 425 kann auch Anwendungen wie etwa eine IM-Client-Anwendung und/oder eine Internet-Browser-Anwendung zum Kommunizieren mit dem IM-Host-Komplex 490 und dem Internet 465 enthalten.
Das Host-System 410 enthält eine Host-Einrichtung 435 und einen Host-Controller 440. Der Host-Controller 440 ist im Allgemeinen zum Übertragen von Anweisungen an ein beliebiges oder alle der Elemente der Host-Einrichtung 435 in der Lage. Beispielsweise enthält bei einer Implementierung der Host-Controller 440 eine oder mehrere, auf ein oder mehrere Elemente der Host-Einrichtung 435 geladene Softwareanwendungen. Bei anderen Implementierungen jedoch, wie oben beschrieben, kann der Host-Controller 440 ein beliebiges von mehreren anderen Programmen, Maschinen und Einrichtungen enthalten, die unabhängig oder kollektiv arbeiten, um die Host-Einrichtung 435 zu steuern.
Das Host-System 410 enthält einen Login-Server 470, der zur Ermöglichung von Kommunikationen mit und Autorisieren von Zugang durch Client-Systeme 405 zu verschiedenen Elementen des Host-Systems 410 einschließlich einem OSP-Host-Komplex 480 und einem IM-Host-Komplex 490 in der Lage ist. Der Login-Server 470 kann eine oder mehrere Autorisierungsprozeduren implementieren, um gleichzeitigen Zugang zu dem OSP-Host-Komplex 480 und dem IM-Host-Komplex 490 zu ermöglichen. Der OSP-Host-Komplex 480 und der IM-Host-Komplex 490 sind durch ein oder mehrere OSP-Host-Komplex-Gateways 485 und ein oder mehrere IM-Host-Komplex-Gateways 495 verbunden. Jedes OSP-Host-Komplex-Gateway 485 und IM-Host-Komplex-Gateway 495 können alle Protokollkonvertierungen durchführen, die erforderlich sind, um eine Kommunikation zwischen dem OSP-Host-Komplex 480, dem IM-Host-Komplex 490 und dem Internet 465 zu ermöglichen.
Der OSP-Host-Komplex 480 unterstützt eine Menge von Diensten von einem oder mehreren innerhalb oder außerhalb des OSP-Host-Komplexes 480 angeordneten Servern. Server außerhalb des OSP-Host-Komplexes 480 können im Allgemeinen als im Internet 465 existierend angesehen werden. Server innerhalb des OSP-Komplexes 480 können in einer oder mehreren Konfigurationen angeordnet sein. Beispielsweise können Server in zentralisierten oder lokalisierten Clustern angeordnet sein, um Server und Teilnehmer innerhalb des OSP-Host-Komplexes 480 zu verteilen.
Bei der Implementierung von 4 enthält der OSP-Host-Komplex 480 einen Routing-Prozessor 4802. Im Allgemeinen untersucht der Routing-Prozessor 4802 ein Adressfeld einer Datenanforderung, verwendet eine Abbildungstabelle zum Bestimmen des entsprechenden Ziels für die Datenanforderung und lenkt die Datenanforderung zu dem entsprechenden Ziel. Bei einer paketbasierten Implementierung kann das Client-System 405 Informationsanforderungen erzeugen, die Anforderungen in Datenpakete konvertieren, die Datenpakete sequenzieren, Fehlerprüfungs- und andere Paketvermittlungstechniken durchführen und die Datenpakete zu dem Routing-Prozessor 4802 übertragen. Bei Empfang von Datenpaketen von dem Client-System 405 kann der Routing-Prozessor 4802 die Datenpakete entweder direkt oder indirekt zu einem spezifizierten Ziel innerhalb oder außerhalb des OSP-Host-Komplexes 480 leiten. Beispielsweise kann der Routing-Prozessor 4802 in dem Fall, dass eine Datenanforderung von dem Client-System 405 lokal erfüllt werden kann, die Datenanforderung an einen lokalen Server 4804 lenken. Falls die Datenanforderung nicht lokal erfüllt werden kann, kann der Routing-Prozessor 4802 die Datenanforderung extern durch das Gateway 485 an das Internet 465 oder den IM-Host-Komplex 490 leiten.
Der OSP-Host-Komplex 480 enthält auch einen Proxy-Server 4806 zum Lenken von Datenanforderungen und/oder anderweitigen Ermöglichen von Kommunikation zwischen dem Client-System 405 und dem Internet 465. Der Proxy-Server 4802 kann einen IP-Tunnel ("Internet Protocol") zum Konvertieren von Daten vom OSP-Protokoll in das Standard-Internet-Protokoll und Übertragen der Daten zum Internet 465 enthalten. Der IP-Tunnel konvertiert auch von dem Internet in dem Standard-Internet-Protokoll empfangene Daten zurück in das OSP-Protokoll und sendet die konvertierten Daten zum Routing-Prozessor 4802 zur Übergabe zurück an das Client-System 405.
Der Proxy-Server 4806 kann auch gestatten, dass das Client-System 405 Standard-Internet-Protokolle und -Formatierung zum Zugriff auf den OSP-Host-Komplex 480 und das Internet 465 verwendet. Beispielsweise kann der Teilnehmer eine OSP-TV-Client-Anwendung mit einer auf dem Client-System 405 installierten eingebetteten Browser-Anwendung verwenden, um eine Anforderung im Standard-Internet-Protokoll wie etwa HTTP ("HyperText Transport Protocol") zu erzeugen. Bei einer paketbasierten Implementierung können die Datenpakete innerhalb eines Standard-Internet-Tunnelungsprotokolls, wie etwa beispielsweise UDP ("User Datagram Protocol"), gekapselt werden und zu dem Proxy-Server 4806 gelenkt werden. Der Proxy-Server 4806 kann einen L2TP-Tunnel ("Layer Two Tunneling Protocol") enthalten, der eine PPP-Sitzung (point-to-point protocol) mit dem Client-System 405 herstellen kann.
Der Proxy-Server 4806 kann auch als ein Puffer zwischen dem Client-System 405 und dem Internet 465 dienen und kann Inhaltsfilterungs- und Zeitspartechniken implementieren. Beispielsweise kann der Proxy-Server 4806 Kindersicherungseinstellungen des Client-Systems 405 prüfen und Inhalt von dem Internet 465 gemäß den Kindersicherungseinstellungen anfordern und übertragen. Außerdem kann der Proxy-Server 4806 einen oder mehrere Caches zum Speichern von Informationen enthalten, auf die häufig zugegriffen wird. Wenn bestimmt wird, dass angeforderte Daten in den Caches gespeichert sind, kann der Proxy-Server 4806 die Informationen von den Caches an das Client-System 405 senden und die Notwendigkeit zum Zugriff auf das Internet 465 vermeiden.
Unter Bezugnahme auf 5 ist ein Kommunikationssystem 500 in der Lage, Informationen über eine Kommunikationsstrecke 515 zwischen einem Client-System 505 und einem Host-System 510 zu übergeben und auszutauschen. Das Client-System 505 enthält in der Regel eine oder mehrere Client-Einrichtungen 520 und einen oder mehrere Client-Controller 525 zum Steuern der Client-Einrichtungen 520. Das Host-System 510 enthält in der Regel eine oder mehrere Host-Einrichtungen 535 und einen oder mehrere Host-Controller 540 zum Steuern der Host-Einrichtungen 535. Die Kommunikationsstrecke 515 kann Kommunikationswege 550, 555 enthalten, die eine Kommunikation durch das eine oder die mehreren Übergabenetze 560 ermöglichen. Wie gezeigt kann das Client-System 505 durch das Host-System 510 auf das Internet 565 zugreifen.
Beispiele jedes Elements innerhalb des Kommunikationssystems von 5 sind oben bezüglich 1–4 allgemein beschrieben. Insbesondere besitzen das Client-System 505 und die Kommunikationsstrecke 515 in der Regel Attribute, die denen vergleichbar sind, die bezüglich der Client-Systeme 105, 205, 305 und 405 und Kommunikationsstrecken 115, 215, 315 und 415 von 1–4 beschrieben sind. Gleichermaßen kann das Host-System 510 von 5 Attribute besitzen, die mit einer möglichen Ausführungsform der in 1–4 jeweils beschriebenen Host-Systeme 110, 210, 310 und 410 vergleichbar sind, und veranschaulicht diese. 5 beschreibt jedoch eine Ausführungsform des Host-Systems 510, wobei in erster Linie auf eine bestimmte Implementierung des IM-Host-Komplexes 590 fokussiert wird. Zu Zwecken der Kommunikation mit dem IM-Host-Komplex 590 ist das Übergabenetz 560 im Allgemeinen ein Telefonnetz.
Das Client-System 505 enthält eine Client-Einrichtung 520 und einen Client-Controller 525. Der Client-Controller 525 ist im Allgemeinen zum Herstellen einer Verbindung zu dem Host-System 510 einschließlich dem OSP-Host-Komplex 580, dem IM-Host-Komplex 590 und/oder dem Internet 565 in der Lage. Bei einer Implementierung enthält der Client-Controller 525 eine IM-Anwendung zum Kommunizieren mit Servern in dem IM-Host-Komplex 590 unter Verwendung exklusiver IM-Protokolle. Der Client-Controller 525 kann auch Anwendungen wie etwa eine OSP-Client-Anwendung und/oder eine Internet-Browser-Anwendung zum Kommunizieren mit dem OSP-Host-Komplex 580 bzw. dem Internet 565 enthalten.
Das Host-System 510 enthält eine Host-Einrichtung 535 und einen Host-Controller 540. Der Host-Controller 540 ist im Allgemeinen zum Übertragen von Anweisungen an ein beliebiges oder alle der Elemente der Host-Einrichtung 535 in der Lage. Beispielsweise enthält bei einer Implementierung der Host-Controller 540 eine oder mehrere, auf ein oder mehrere Elemente der Host-Einrichtung 535 geladene Softwareanwendungen. Bei anderen Implementierungen jedoch, wie oben beschrieben, kann der Host-Controller 540 ein beliebiges von mehreren anderen Programmen, Maschinen und Einrichtungen enthalten, die unabhängig oder kollektiv arbeiten, um die Host-Einrichtung 535 zu steuern.
Das Host-System 510 enthält einen Login-Server 570, der zur Ermöglichung von Kommunikationen mit und Autorisieren von Zugang durch Client-Systeme 505 zu verschiedenen Elementen des Host-Systems 510 einschließlich einem OSP-Host-Komplex 580 und einem IM-Host-Komplex 590 in der Lage ist. Der Login-Server 570 kann eine oder mehrere Autorisierungsprozeduren implementieren, um gleichzeitigen Zugang zu dem OSP-Host-Komplex 580 und dem IM-Host-Komplex 590 zu ermöglichen. Der OSP-Host-Komplex 580 und der IM-Host-Komplex 590 sind durch ein oder mehrere OSP-Host-Komplex-Gateways 585 und ein oder mehrere IM-Host-Komplex-Gateways 595 verbunden. Jedes OSP-Host-Komplex-Gateway 585 und IM-Host-Komplex-Gateway 595 können alle Protokollkonvertierungen durchführen, die erforderlich sind, um eine Kommunikation zwischen dem OSP-Host-Komplex 580, dem IM-Host-Komplex 590 und dem Internet 565 zu ermöglichen.
Um zum Beginnen einer Instant-Messaging-Sitzung auf den IM-Host-Komplex 590 zuzugreifen, stellt das Client-System 505 eine Verbindung zu dem Login-Server 570 her. Der Login-Server 570 bestimmt in der Regel, ob der jeweilige Teilnehmer zum Zugriff auf den IM-Host-Komplex 590 autorisiert ist, indem er eine Identifikation und ein Passwort des Teilnehmers verifiziert. Wenn der Teilnehmer zum Zugriff auf den IM-Host-Komplex 590 autorisiert ist, verwendet der Login-Server 570 eine Hashing-Technik an dem Schirmnamen des Teilnehmers, um einen bestimmte IM-Server 5902 zur Verwendung während der Sitzung des Teilnehmers zu identifizieren. Der Login-Server 570 übergibt dem Client-System 505 die IP-Adresse des bestimmten IM-Servers 5902, gibt dem Client-System 505 einen verschlüsselten Schlüssel (d. h. ein Cookie) und unterbricht die Verbindung. Das Client-System 505 verwendet dann die IP-Adresse zum Herstellen einer Verbindung zu dem jeweiligen IM-Server 5902 durch die Kommunikationsstrecke 515 und erhält Zugang zu diesem IM-Server 5902 unter Verwendung des verschlüsselten Schlüssels. In der Regel wird das Client-System 505 mit einer Winsock-API ("Application Programming Interface") ausgestattet sein, die es dem Client-System 505 ermöglicht, eine offene TCP-Verbindung zu dem IM-Server 5902 herzustellen.
Nachdem eine Verbindung zu dem IM-Server 5902 hergestellt worden ist, kann das Client-System 505 Daten direkt oder indirekt zu dem IM-Server 5902 und einen oder mehreren assoziierten Domain-Servern 5904 übertragen oder auf Inhalt davon zugreifen. Der IM-Server 5902 unterstützt die fundamentalen Instant-Messaging-Dienste, und die Domain-Server 5904 können assoziierte Dienste unterstützen, wie etwa beispielsweise administrative Fragen, Verzeichnisdienste, Chat- und Interessengruppen. Der Zweck der Domain- Server 5904 besteht im Allgemeinen darin, die dem IM-Server 5902 auferlegte Last zu reduzieren durch Übernehmen von Verantwortung für einige der Dienste innerhalb des IM-Host-Komplexes 590. Durch Zugreifen auf den IM-Server 5902 und/oder den Domain-Server 5904 kann ein Teilnehmer die IM-Client-Anwendung verwenden, um zu sehen, ob bestimmte Teilnehmer ("Buddies") online sind, Instant-Messages mit bestimmten Teilnehmern austauschen, in Gruppen-Chat-Rooms teilnehmen, Dateien wie etwa Bilder, Einladungen oder Dokumente handeln, andere Teilnehmer mit ähnlichen Interessen herausfinden, kundenspezifische Nachrichten und Börsenkurse erhalten und das Web durchsuchen.
Bei der Implementierung von 5 ist der IM-Server 5902 direkt oder indirekt an ein Routing-Gateway 5906 angeschlossen. Das Routing-Gateway 5906 ermöglicht die Verbindung zwischen dem IM-Server 5902 und einem oder mehreren Rufmeldungs-Multiplexoren 5908, indem es beispielsweise als ein Streckenminimierungstool oder ein Hub dient zum Anschließen mehrerer IM-Server an mehrere Rufmeldungs-Multiplexoren. Im Allgemeinen pflegt ein Rufmeldungs-Multiplexor 5908 einen Datensatz von Rufmeldungen und Teilnehmern, die registriert sind, um die Rufmeldungen zu empfangen.
Nachdem das Client-System 505 an den Rufmeldungs-Multiplexor 5908 angeschlossen ist, kann ein Teilnehmer sich für eine oder mehrere Arten von Rufmeldungen registrieren und/oder sie empfangen. Der Verbindungsweg zwischen dem Client-System 505 und dem Rufmeldungs-Multiplexor 5908 wird durch Verwendung einer anderen Hashing-Technik an den IM-Server 5902 bestimmt, um den jeweiligen Rufmeldungs-Multiplexor 5908 zu identifizieren, der für die Sitzung des Teilnehmers verwendet werden soll. Nachdem der bestimmte Multiplexor 5908 identifiziert worden ist, übergibt der IM-Server 5902 dem Client-System 505 die IP-Adresse des jeweiligen Rufmeldungs-Multiplexors 5908 und gibt dem Client-System 505 einen verschlüsselten Schlüssel (d. h. ein Cookie). Das Client-System 505 verwendet dann die IP-Adresse zum Verbinden mit dem jeweiligen Rufmeldungs-Multiplexor 5908 durch die Kommunikationsstrecke 515 und erhält unter Verwendung des verschlüsselten Schlüssels Zugang zu dem Rufmeldungs-Multiplexor 5908.
Der Rufmeldungs-Multiplexor 5908 ist mit einem Rufmeldungs-Gate 5910 verbunden, das wie das IM-Host-Komplex-Gateway 595 in der Lage ist, die erforderlichen Protokollkonvertierungen durchzuführen, um eine Brücke zu dem OSP-Host-Komplex 580 zu bilden. Das Rufmeldungs-Gate 5910 ist die Schnittstelle zwischen dem IM-Host-Komplex 590 und den physischen Servern, wie etwa Servern im OSP-Host-Komplex 580, wo Zustandsänderungen auftreten. Im Allgemeinen werden die Informationen hinsichtlich Zustandsänderungen gesammelt und von dem IM-Host-Komplex 590 verwendet. Der Rufmeldungs-Multiplexor 5908 kann jedoch auch mit dem OSP-Host-Komplex 580 durch das IM-Gateway 595 kommunizieren, als Beispiel, um den Servern und Teilnehmern des OSP-Host-Komplexes 580 bestimmte Informationen, die vom Rufmeldungs-Gate 5910 gesammelt wurden, zu übergeben.
Das Rufmeldungs-Gate 5910 kann eine Rufmeldungseinspeisung entsprechend einer bestimmten Art von Rufmeldung detektieren. Das Rufmeldungs-Gate 5910 kann ein Code-Teil enthalten (Rufmeldungsempfangscode), das in der Lage ist, mit einem anderen Code-Teil (Rufmeldungsrundsendecode) auf dem physischen Server, wo eine Zustandsänderung auftritt, zu interagieren. Im Allgemeinen weist der auf dem Rufmeldungs-Gate 5910 installierte Rufmeldungsempfangscode den auf dem physischen Server installierten Rufmeldungsrundsendecode an, bei dem Auftreten einer bestimmten Zustandsänderung eine Rufmeldungseinspeisung an das Rufmeldungs-Gate 5910 zu senden. Nach dem Detektieren einer Rufmeldungseinspeisung kontaktiert das Rufmeldungs-Gate 5910 den Rufmeldungs-Multiplexor 5908, der wiederum das Client-System 505 über die detektierte Rufmeldungseinspeisung informiert.
In der Implementierung von 5 enthält der IM-Host-Komplex 590 auch einen an eine Datenbank 5914 angeschlossenen Teilnehmerprofil-Server 5912 zum Speichern großer Mengen von Teilnehmerprofildaten. Der Teilnehmerprofil-Server 5912 kann verwendet werden, um Teilnehmerprofildaten einzugeben, abzurufen, zu editieren, zu manipulieren oder anderweitig zu bearbeiten. Bei einer Implementierung zählen zu den Profildaten eines Teilnehmers beispielsweise die Buddy-Liste des Teilnehmers, Rufmeldungspräferenzen, bezeichnete Aktien, identifizierte Interessen und geografischer Ort. Der Teilnehmer kann Profildaten eingeben, editieren und/oder löschen, wobei er zum Interagieren mit dem Teilnehmerprofil-Server 5912 eine installierte IM-Client-Anwendung auf dem Client-System 505 verwendet.
Weil die Daten des Teilnehmers in dem IM-Host-Komplex 590 gespeichert sind, braucht der Teilnehmer solche Informationen für den Fall, dass der Teilnehmer unter Verwendung eines neuen oder anderen Client-Systems 505 auf den IM-Host-Komplex 590 zugreift, nicht erneut einzugeben oder zu aktualisieren. Wenn ein Teilnehmer auf den IM-Host-Komplex 590 zugreift, kann der IM-Server 5902 den Teilnehmerprofil-Server 5912 entsprechend anweisen, die Profildaten des Teilnehmers aus der Datenbank 5914 abzurufen und beispielsweise die Buddy-Liste des Teilnehmers an den IM-Server 5902 und die Rufmeldungspräferenzen des Teilnehmers an den Rufmeldungs-Multiplexor 5908 zu übergeben. Der Teilnehmerprofil-Server 5912 kann auch mit anderen Servern in dem OSP-Host-Komplex 590 kommunizieren, um Teilnehmerprofildaten mit anderen Diensten zu teilen. Alternativ können Benutzerprofildaten lokal auf der Client-Einrichtung 505 gesichert werden.
Unter Bezugnahme auf 6 interagieren ein Sender 602a, ein Empfänger 602b und ein Host 604 gemäß einer Prozedur 600, um Audiodaten zu transferieren. Die Prozedur 600 kann durch irgendeine geeignete Art von Hardware, Software, Einrichtung, Computer, Computersystem, Gerät, Komponente, Programm, Anwendung, Code, Speichermedium oder verbreitetes Signal implementiert werden.
Beispiele jedes Elements von 6 sind oben unter Bezugnahme auf 1-5 allgemein beschrieben. Insbesondere besitzen der Sender 602a und der Empfänger 602b in der Regel Attribute, die jenen vergleichbar sind, die bezüglich der Client-Einrichtungen 120, 220, 320, 420 und 520 und/oder Client-Controller 125, 225, 325, 425 und 525 beschrieben sind. Der Host 604 besitzt in der Regel Attribute, die jenen vergleichbar sind, die bezüglich der Host-Einrichtungen 135, 235, 335, 435 und 535 und/oder Host-Controller 140, 240, 340, 440 und 540 beschrieben sind. Der Sender 602a, der Empfänger 602b und/oder der Host 604 können durch ein bekanntes oder beschriebenes Übergabenetz direkt oder indirekt zusammengeschaltet sein.
Der Sender 602a und der Empfänger 602b sind jeweils mit einem Teilnehmer assoziiert. Um Dateitransfers zu gestatten, setzt jeder Teilnehmer gewisse Präferenzen für das Gestatten des Transfers von Dateien zu und von anderen Teilnehmern. Beispielsweise können der Sender und Empfänger Schirmnamen von Teilnehmern identifizieren, die die Erlaubnis besitzen, ihnen Dateien zu senden oder Dateien von ihnen abzurufen. Typischerweise wird jedem Teilnehmer eine grafische Benutzerschnittstelle vorgelegt, die eine Auswahl unter verschiedenen Transferpräferenzen gestattet. Die Transferpräferenzen eines Teilnehmers können lokal am Client oder entfernt am Host 604 gepflegt werden.
Im Allgemeinen kommunizieren der Sender 602a und der Empfänger 602b über eine offene Verbindung, wie etwa eine offene TCP-Verbindung, die durch den Host 604 hergestellt ist. In der Regel enthalten der Sender 602a und der Empfänger 602b jeweils eine Winsock-API zum Herstellen einer offen TCP-Verbindung zu dem Host 604 und eine Client-Anwendung zum Zugreifen auf den Host 604. Der Sender 602a und der Empfänger 602b werden an den Host 604 angeschlossen, um die Verbindung herzustellen.
Der Sender 602a und der Empfänger 602b kommunizieren über die Verbindung mit dem Host 604 und miteinander. Die Verbindung bleibt während der Zeit, in der der Sender 602a und der Empfänger 602b auf den Host 604 zugreifen, offen. Um auf den Host 604 zuzugreifen, senden der Sender 602a und der Empfänger 602b jeweils eine separate Anforderung an den Host 604. Die Anforderung identifiziert den assoziierten Teilnehmer unter Verwendung eines eindeutigen Schirmnamens gegenüber dem Host 604 und gegenüber anderen Teilnehmern. Der Host 604 verifiziert eine Teilnehmerinformation (z. B. Schirmnamen und Passwort) anhand von in einer Teilnehmerdatenbank gespeicherten Daten. Wenn die Teilnehmerinformation verifiziert ist, autorisiert der Host 604 den Zugang. Wenn die Teilnehmerinformation nicht verifiziert wird, verweigert der Host 604 den Zugang und sendet eine Fehlernachricht.
Bei Zugriff auf den Host 604 wird dem Teilnehmer eine "Buddy-Liste" angezeigt. Allgemein ist die Buddy-Liste eines Teilnehmers eine Benutzerschnittstelle, die den Online-Status und Fähigkeiten von gegenüber dem Teilnehmer identifizierten bestimmten Schirmnamen, d. h. "Buddies", auflistet. Insbesondere informiert der Host 604 den Sender, ob identifizierte Buddies online sind, d. h. gegenwärtig auf den Host 604 zugreifen. Der Host 604 informiert auch einen etwaigen Teilnehmer, der den Sender als einen Buddy identifiziert hat, dass der Sender gegenwärtig online ist. Die Buddy-Liste ermöglicht auch eine Instant-Messaging-Kommunikation zwischen Teilnehmern. Ein Teilnehmer kann eine an einen Buddy voradressierte Instant-Messaging-Benutzerschnittstelle einfach durch Anklicken des Schirmnamens eines Buddys auf der Buddy-Liste aktivieren. Wenn der Empfänger kein "Buddy" ist, muss der erste Teilnehmer eine leere Instant-Messaging-Benutzerschnittstelle aktivieren und dann die Instant-Message an den Schirmnamen des beabsichtigten Empfängers adressieren. Gegebenenfalls kann ein Teilnehmer den Schirmnamen eines beabsichtigten Empfängers unter Verwendung der E-Mail-Adresse des beabsichtigten Empfängers nachsehen.
Zusätzlich zu dem Austauschen von Instant-Messages mit Online-Buddies kann der Sender an Gruppen-Chat-Rooms teilnehmen, andere Teilnehmer mit ähnlichen Interessen finden, kundenspezifische Nachrichten und Aktienkurse erhalten, das Web durchsuchen und Dateien zu und von anderen Teilnehmern transferieren. Bei einer Implementierung interagieren ein Sender 602a, ein Empfänger 602b und ein Host 604 gemäß einer Prozedur 600, um Audiodaten zu transferieren.
Der Transfer von Audiodaten erweitert die Funktionalität des Instant-Messaging, indem der Sender 602a und der Empfänger 602b Partner-zu-Partner über Audio kommunizieren können, d. h. über Mikrofon und Lautsprecher. Bei einer Implementierung initiiert der Sender den Prozess 600 durch Bezeichnen eines oder mehrerer Empfänger zum Empfangen einer Instant-Message (z. B. einer Textnachricht). Wenn die beabsichtigten Empfänger "Buddies" des Senders 602a sind, kann der Sender 602a den Online-Status und Fähigkeiten jedes Empfängers vor dem Senden der Videonachricht durch Betrachten der "Buddy-Liste" bestätigen. Nachdem ein Teilnehmer eine Instant-Message verfasst hat und einen SEND-Knopf angeklickt hat, wird die Instant-Message von dem Sender 602a zu dem Host geschickt (Schritt 605).
Nach dem Empfangen der Instant-Message von dem Sender 602a authentisiert der Host 604 die Instant-Message (Schritt 610). Zusätzlich zu dem Textkörper kann die Instant- Message Kopfteilinformationen, die die Nachrichtenart, den Schirmnamen und/oder IP-Adresse des Senders und Empfängers identifizieren, und eine zufällig erzeugte Sicherheitszahl enthalten. Die Instant-Message kann beispielsweise durch eine umgekehrte Nachschlagetabelle authentisiert werden, um die Schirmnamen und/oder IP-Adressen mit jenen von gültigen Teilnehmern abzugleichen. Falls entweder der Sender 602a oder der Empfänger 602b nicht mit einem gültigen Teilnehmer assoziiert ist, meldet der Host 604 eine Fehlernachricht.
Nachdem die Instant-Message verifiziert ist, bestimmt der Host 604 die Fähigkeiten des Empfängers (Schritt 615). Beispielsweise kann der Host 604 den Online-Status, die Client-Version und die Einrichtungsart aller angeschlossenen Teilnehmer in Echtzeit überwachen und aktualisieren. Die Fähigkeit zum Empfangen von Audiodaten kann von Hardware (z. B. Einrichtungsart), Software (z. B. Client-Version) und/oder Transferpräferenzen (z. B. blockierten Schirmnamen) abhängen. Damit Sprechen ermöglicht ist, müssen sowohl die Sprechsoftware als auch das Audiogerät zur Verfügung stehen. Der Host 604 meldet dann die Fähigkeiten des Empfängers an den Sender (Schritt 620).
Bei Empfang des Berichts von dem Host 604 zeigt der Sender 602a eine UI gemäß den Fähigkeiten des Senders und/oder des Empfängers 702b an (Schritt 625). Wenn beim Sender 602a nicht das Sprechen ermöglicht ist, dann wird eine Standard-Instant-Messaging-Benutzerschnittstelle angezeigt. Wenn das Sprechen beim Sender 602a ermöglicht ist, aber das Sprechen nicht beim Empfänger 602b ermöglicht ist, wird eine START-TALK-UI mit einem abgeblendeten START-TALK-Knopf angezeigt. Wenn das Sprechen sowohl für den Sender 602a als auch den Empfänger 602b ermöglicht ist, wird eine START-TALK-UI mit einem funktionierenden START-TALK-Knopf angezeigt.
Der Prozess 600 geht damit weiter, dass der Host 604 die Instant-Message an den Empfänger 602b sendet (Schritt 630). Der Empfänger 602b akzeptiert die anfängliche Textnachricht von dem Host 604 (Schritt 635) und zeigt eine UI gemäß den Fähigkeiten des Senders 602a und/oder des Empfängers 602b an (Schritt 640). Wenn das Sprechen für den Empfänger 602b nicht ermöglicht ist, dann wird eine Standard-Instant-Messaging-UI angezeigt. Wenn das Sprechen für den Empfänger 602b ermöglicht ist, aber nicht für den Sender 602a, wird eine Instant-Messaging-UI mit einem abgeblendeten START-TALK-Knopf angezeigt. Wenn das Sprechen sowohl für den Empfänger 602b als auch den Sender 602a ermöglicht ist, wird eine Instant-Messaging-UI mit einem funktionierenden START-TALK-Knopf angezeigt.
Wenn das Sprechen für beide Seiten ermöglicht ist, wird sowohl bei dem Sender 602a als auch bei dem Empfänger 602b eine START-TALK-UI angezeigt. Wenn die START-TALK-UI angezeigt ist, kann ein Teilnehmer eine Sprechsitzung initiieren. Bei einer Implementierung initiiert der Sender 602a eine Sprechsitzung durch Senden einer Sprechanforderung an den Host 604 (Schritt 645). Die Sprechanforderung kann Informationen enthalten, die unter anderem die Nachrichtenart, den Schirmnamen und/oder die IP-Adresse des Senders und Empfängers und eine zufällig erzeugte Sicherheitszahl enthält. Wenn der Sender 602a die START-TALK-UI anklickt, geht die START-TALK-UI in eine END-TALK-UI über.
Bei Empfang der Sprechanforderung authentisiert der Host 604 die Sprechanforderung von dem Sender 602a (Schritt 650). Der Host 604 kann die Sprechanforderung authentisieren, indem beispielsweise eine umgekehrte Nachschlagetabelle verwendet wird, um die Schirmnamen und/oder IP-Adressen mit jenen von gültigen Teilnehmern abzugleichen. Falls entweder der Sender 602a oder der Empfänger 602b nicht mit einem gültigen Teilnehmer assoziiert ist, meldet der Host 604 eine Fehlernachricht.
Nach dem Verifizieren der Sprechanforderung sendet der Host 604 die Sprechanforderung an den Empfänger 602b (Schritt 655). Bei Empfang der Sprechanforderung geht der durch den Empfänger 602b angezeigte START-TALK-UI in einen CONNECT-UI über (Schritt 660). Der CONNECT-UI informiert den Empfänger 602b, dass der Sender 602a eine Sprechsitzung (ihren möchte. An diesem Punkt kann der Empfänger 602b die Sprechanforderung ignorieren, die Sprechanforderung akzeptieren oder die Instant-Message-Sitzung terminieren.
Wenn der Empfänger 602b die Sprechanforderung durch Anklicken der CONNECT-UI akzeptiert (Schritt 665), geht die CONNECT-UI in die END-TALK-UI über, und der Host 604 stellt eine Sprechsitzung her (Schritt 670). Wenn eine Sprechsitzung aktiv ist, können Benutzer miteinander sprechen. An diesem Punkt wird sowohl durch den Sender 602a als auch den Empfänger 602b END-TALK-UI angezeigt. Die Sprechsitzung (Schritte 675a–b) bleibt so lange aktiv, bis einer der Benutzer END-TALK-UI anklickt. Nachdem einer der Benutzer die END-TALK-UI anklickt, zeigen sowohl der Sender 602a als auch der Empfänger 602b die START-TALK-UI, wodurch beide Seiten eine weitere Sprechsitzung initiieren können.
Wenn der Sender 602a die Sprechsitzung abbricht, bevor sich der Empfänger anschließt, macht die CONNECT-UI an dem Empfänger 602b einen Übergang zurück zu START-TALK-UI. Wenn beide Benutzer gleichzeitig START-TALK-UI anklicken, ignoriert der Host einen der START-TALK-Klicks, so dass ein Benutzer die END-TALK-UI und der andere die CONNECT-UI anzeigt. Wenn der Sender die START-TALK-UI anklickt, bevor der Empfänger 602b die anfängliche Textnachricht akzeptiert, zeigt der Empfänger 602b nicht die START-TALK-UI an, sondern zeigt statt dessen sofort die CONNECT-UI an.
Bei einer Implementierung stellt ein Sprechtool eine aktive Sprechsitzung her, wobei es drei Kommunikationskanäle verwendet: einen GSI-Kanal (Generic Signaling Interface), einen Steuerkanal und einen Audiokanal. Das Sprechtool verwendet den GSI-Kanal zum Herstellen der anfänglichen Verbindung. Während dieser Verbindung werden die lokalen IP-Adressen ausgetauscht. Nachdem die anfängliche Verbindungsphase erfolgt ist, wird der GSI-Kanal nicht länger verwendet. Durch Verwendung des GSI-Kanals erfolgt der Austausch lokaler IP-Adressen nur, wenn beide Benutzer einen derartigen Austausch gestatten, d. h. durch Anklicken der CONNECT UI. Durch diese Aktionen werden Benutzer davor geschützt, dass ihre lokalen IP-Adressen automatisch ohne ihre Einwilligung erhalten werden.
Der Steuerkanal ist eine TCP/IP-Socket, für die die IP-Adresse und die Portnummer der entfernten Seite durch den GSI-Kanal erhalten werden. Der Steuerkanal wird verwendet, um Steuerattribute der Sprechsitzung zu senden/empfangen, während die Sitzung aktiv ist. Beispielsweise versucht das Sprechtool, weil einige Firewalls keinen externen Anschluss zu einer Socket auf der Innenseite der Firewall gestatten, eine Verbindung von beiden Seiten der Sitzung. Diese Aktion gestattet, dass eine Verbindung hergestellt wird, wenn innerhalb der Verbindung höchstens eine Firewall existiert. Wenn eine Firewall auf beiden Seiten existiert, ist die Wahrscheinlichkeit, dass keine Verbindung hergestellt werden kann und die Sprechsitzung erfolglos ist. Um über zwei Firewalls hinweg zu arbeiten, muss der Benutzer den durch das Sprechen verwendeten Portbereich erhalten, so dass eine der Firewalls modifiziert werden kann, damit der Bereich die Firewall passieren kann.
Der Audiokanal ist eine TCP/IP-Socket, die zum Transportieren von Audiopaketen verwendet wird. Dieser Kanal kann entweder UDP oder TCP sein. Im Allgemeinen wird UDP verwendet, da er die Latenzzeit auf ein Minimum reduziert. Weil einige Firewalls jedoch keine UDP-Pakete durchlassen, wird der Audiokanal möglicherweise TCP verwenden müssen. Das Sprechtool zeigt den Modus an (d. h. TCP, UDP) oder verwendet einen Automatikmodus, bei dem das Sprechtool einen UDP-Test versucht und bei Erfolglosigkeit von UDP auf TCP ausweicht.
Sprechsitzungen können entweder mit Voll- oder Halbduplex arbeiten. Vollduplex besteht darin, wenn beide Benutzer zur gleichen Zeit sprechen können. Halbduplex ist, wenn jeweils nur ein Benutzer sprechen kann. Es wird bestimmt, dass eine Client-Einrichtung nicht in der Lage ist, Vollduplex zu handhaben, als Beispiel, wenn die CPU zu langsam ist, um Audio simultan zu komprimieren/dekomprimieren und/oder das Mikrofon und die Lautsprecher nicht gleichzeitig offen sein können. Wenn eine Client-Einrichtung als Halbduplex markiert ist, dann wird jede von dieser Client-Einrichtung verwendete Sprechsitzung ungeachtet davon, ob eine andere Einrichtung den Duplexmodus handhaben kann, zu einer Halbduplexsitzung. Bei einer Implementierung unterstützt ein TALK/LISTEN-Knopf an der END-TALK-UI den Halbduplexbetrieb. Dieser Knopf besitzt zwei Zustände: LISTEN (Hören) oder TALK (Sprechen). Wenn die Sprechsitzung Vollduplex ist, ist dieser Knopf nicht gezeigt. Wenn sowohl an dem Sender 702a als auch dem Empfänger 702b auf dem Knopf TALK steht (anfängliches Halbduplex), darf der erste Benutzer, der TALK anklickt, sprechen, und der andere Benutzer ist gezwungen, zuzuhören. Der Benutzer, der zuhört, hat einen abgeblendeten TALK-Knopf (Halbduplex-Hören), und der Benutzer, der spricht, hat einen LISTEN-Knopf (Halbduplex-Sprechen). Wenn der LISTEN-Knopf angeklickt wird, gestattet der Benutzer, der spricht, dem zuhörenden Benutzer, zu sprechen.
Das Sprechtool, das die Audiotransferfunktionalität (Sprechen) ermöglicht, kann eine beliebige, auf eine Client-Einrichtung geladene Art von Client-Controller (z. B. Software, Anwendung, Programm) sein. Das Sprechtool unterstützt die Verwendung durch verschiedene OSP- und IM-Clients. Das Sprechtool ist für das Reagieren auf Benutzerschnittstellen und Übersetzen von Benutzerbefehlen in die entsprechenden Aktionen mit der Client-Einrichtung verantwortlich. Beispielsweise werden von dem Sprechtool die physischen Komponenten an den Client-Einrichtungen, die für Audio erforderlich sind, geöffnet, gelesen, geschrieben und geschlossen. Das Sprechtool steuert auch Audio- und Steuerkanäle, wobei Rückrufe ausgeführt werden, um eine Statusänderung anzuzeigen. Wenn das Sprechtool geladen ist, bestimmt das Sprechtool, ob die Client-Einrichtung zum Verarbeiten von Vollduplex in der Lage ist.
Das Sprechtool kann auch dem Benutzer gestatten, die Lautstärke für den Lautsprecher und das Mikrofon zu steuern. Bei einer Implementierung spricht der Benutzer in ein Mikrofon, und die Audiodaten werden im Speicher aufgezeichnet. Noch im Aufzeichnungsmodus wird der mittlere Pegel der Stimme des Sprechers auf einem auf einer Benutzerschnittstelle des Sprechtools angezeigten Pegelmessgerät angezeigt. Ein Schieberegler wird verwendet, um den Eingangspegel auf einen optimalen Wert zu justieren. Nachdem der Sprecher zu sprechen aufhört, wird die gespeicherte Stimme des Sprechers durch die Audioausgabeeinrichtung des Computers abgespielt. Der Lautsprecherpegel-Schieberegler kann verwendet werden, um den Ausgabepegel auf ein annehmbares Volumen zu justieren. Wenn der Benutzer wieder zu sprechen beginnt, kehrt das Sprechtool zu dem Aufzeichnungsmodus zurück, und der Zyklus wiederholt sich. Nachdem der Benutzer mit den Einstellungen zufrieden ist, kann der Benutzer die Einstellungen zur Verwendung in späteren Sprechsitzungen sichern.
Das Sprechtool kann zusätzliche Funktionalität unterstützen, einschließlich unter anderem Multi-Conferencing, Parken und Stummschaltung. Das Multi-Conferencing gestattet, dass mehr als zwei Benutzer an einer Sprechsitzung teilnehmen. Das Parken gestattet das Anhalten einer aktiven Sprechsitzung, um zu einer anderen Sprechsitzung zu verbinden. Die Stammschaltung schaltet das Mikrofon aus, um beim Vollduplexmodus Benutzerrückkopplung/-Echo zu verhindern.
Das Sprechtool kann auch Sicherheitsmerkmale enthalten, um die Integrität von transferierten Daten zu schützen. Beispielsweise kann das Sprechtool Daten unter Verwendung eines proprietären Algorithmus komprimieren oder kann die Daten in einem proprietären Protokoll senden. Zur weiteren Verbesserung der Sicherheit kann das Sprechtool die Portnummern zufällig aus einem großen Bereich auswählen.
Im Allgemeinen ist eine Instant-Messaging-Sprechsitzung ähnlich einer Telefonsitzung, weil sie die gleichen drei Zustände aufweist: nicht verbunden (aufgelegt), Verbinden (Klingeln) und verbunden (Sprechen). Diese Zustände und die Fähigkeit zum Umschalten unter ihnen werden wie oben beschrieben durch entsprechende UIs unterstützt, nämlich eine START-TALK-UI (nicht verbunden), eine CONNECT-UI (Klingeln) und eine END-TALK-UI (verbunden).
7 veranschaulicht ein Beispiel einer START-TALK-UI. Wie in 7 gezeigt, enthält eine START-UI 700 eine Instant-Message-Box 705 mit einem START-TALK-Knopf 710 zum Anfordern einer Sprechsitzung.
8 veranschaulicht ein Beispiel einer CONNECT-UI. Wie in 8 gezeigt, enthält eine UI 800 eine Instant-Message-Box 805 mit einem CONNECT-Knopf 810 zum Annehmen einer Anforderung zum Initiieren einer Sprechsitzung.
9 veranschaulicht ein Beispiel einer END-TALK-UI. Wie in 9 gezeigt, enthält eine UI 900 eine Instant-Message-Box 905 mit einem END-TALK-Knopf 910 zum Terminieren einer Sprechsitzung.
10 veranschaulicht ein Beispiel einer Halbduplex-Benutzerschnittstelle. Wie in 10 gezeigt, enthält eine UI 1000 eine Instant-Message-Box 1005 mit einem TALK- Knopf 1010. Der Knopf 1010 ist abgeblendet oder auf andere Weise deaktiviert, wenn die andere Partei spricht.
Andere Ausführungsformen liegen innerhalb des Schutzbereichs der folgenden Ansprüche.
Schlüssel zu den Figuren:

1

160: NETZ

2

294: TASTATUR
292: MOBILTELEFON
291: MAUS
295: ANZEIGE
296: TV-FERNSTEUERUNG
272: SPEICHER
274: BETRIEBSSYSTEM
276: AUTHORING-ANWENDUNG(EN)
278: CLIENT-ANWENDUNG(EN)
280: BROWSER-ANWENDUNG(EN)
288: EINGANG/AUSGANG
286: TV-TUNER
284: KOMMUNIKATIONSEINRICHTUNG
260: NETZ

3

360: NETZ
380: OSP-HOST-KOMPLEX
390: IM-HOST-KOMPLEX

4

460: NETZ
465: INTERNET
4802: ROUTING-PROZESSOR
4804: LOKALER SERVER
4806: PROXY-SERVER
490: IM-HOST-KOMPLEX

5

560: NETZ
5912: PROFIL-SERVER
5904: DOMAIN-SERVER
5906: ROUTING-GATEWAY
5902: IM-SERVER
5908: RUFMELDUNGS-MUX
5910: RUFMELDUNGS-GATE
585: OSP-HOST-KOMPLEX
565: INTERNET

6

602b: EMPFÄNGER
605: TEXTNACHRICHT AN HOST SENDEN
610: TEXTNACHRICHT AUTHENTISIEREN
615: FÄHIGKEITEN DES EMPFÄNGERS BESTIMMEN
620: FÄHIGKEITEN AN SENDER BERICHTEN
625: START-TALK-UI ANZEIGEN
630: TEXTNACHRICHT AN EMPFÄNGER SENDEN
635: TEXTNACHRICHT AKZEPTIEREN
640: START-TALK-UI ANZEIGEN
645: SPRECHANFORDERUNG AN HOST SENDEN
650: SPRECHANFORDERUNG AUTHENTISIEREN
655: SPRECHANFORDERUNG AN EMPFÄNGER SENDEN
660: CONNECT-UI ANZEIGEN
665: SPRECHANFORDERUNG AKZEPTIEREN
670: SPRECHSITZUNG HERSTELLEN
675a: END-TALK-UI ANZEIGEN
675b: END-TALK-UI ANZEIGEN

Claims

Kommunikationsverfahren, umfassend: Aufbauen einer Instanz-Messaging-Kommunikationssitzung zwischen einem Sender und einem Empfänger unter Verwendung eines Instant-Messaging-Host (390, 490, 590) und Ermöglichen, dass der Empfänger eine Sprachkommunikation zwischen dem Sender und dem Empfänger unter Verwendung des Instant-Messaging-Host (390, 490, 590) aufruft; DADURCH GEKENNZEICHNET, DASS: die Instant-Messaging-Kommunikationssitzung eine Text-Instant-Messaging-Kommunikationssitzung ist; UND DURCH: Erleichtern des Sendens einer Text-Instant-Message von dem Sender an den Empfänger während der Sitzung, wobei die Text-Instant-Message einen von dem Sender eingegebenen Textkörper enthält; und Ermöglichen einer Darstellung einer ersten Text-Instant-Messaging-Grafikbenutzerschnittstelle (800) für den Empfänger, die eine Anzeige des Textkörpers und einen Knopf enthält, wobei die Darstellung der ersten Text-Instant-Messaging-Grafikbenutzerschnittstelle (800) von der Kommunikation der Text-Instant-Message zwischen dem Sender und dem Empfänger abhängt; wobei das Ermöglichen, dass der Empfänger eine Sprachkommunikation zwischen dem Sender und dem Empfänger aufruft, das Ermöglichen umfasst, dass der Empfänger den Knopf auswählt, um die Sprachkommunikation zwischen dem Sender und dem Empfänger aufzurufen.
Verfahren nach Anspruch 1, weiterhin umfassend Empfangen und Authentisieren der Text-Instant-Message von dem Sender bei dem Instant-Messaging-Host (390, 490, 590).
Verfahren nach Anspruch 2, wobei das Authentisieren der Text-Instant-Message das Identifizieren eines Schirmnamens und/oder einer IP-Adresse, mit mindestens dem Sender und/oder dem Empfänger assoziiert, umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, weiterhin umfassend das Bestimmen von Sprachkommunikationsfähigkeiten des Empfängers bei dem Instant-Messaging-Host (390, 490, 590).
Verfahren nach Anspruch 4, wobei das Bestimmen von Sprachkommunikationsfähigkeiten das Identifizieren von Hardware und/oder Software umfasst, die mit dem Empfänger assoziiert sind.
Verfahren nach Anspruch 4, weiterhin umfassend das Melden der Sprachkommunikationsfähigkeiten des Empfängers an den Sender.
Verfahren nach Anspruch 6, weiterhin umfassend, dem Sender eine zweite Text-Instant-Messaging-Schnittstelle (700) darzustellen, die entsprechend den Fähigkeiten des Empfängers variiert.
Verfahren nach Anspruch 1, weiterhin umfassend, bei dem Instant-Messaging-Host (390, 490, 590) eine Anforderung zum Aufbauen einer Sprachkommunikation zu empfangen.
Verfahren nach Anspruch 8, wobei die Anforderung von dem Sender kommt.
Verfahren nach Anspruch 8, wobei die Anforderung von dem Empfänger kommt und als Reaktion auf die Auswahl des Knopfs durch den Empfänger empfangen wird.
Verfahren nach Anspruch 8, 9 oder 10, weiterhin umfassend das Authentisieren der Anforderung.
Verfahren nach Anspruch 11, wobei das Authentisieren der Anforderung das Identifizieren eines Schirmnamens und/oder einer IP-Adresse, mit mindestens dem Sender und/oder dem Empfänger assoziiert, umfasst.
Verfahren nach Anspruch 1, wobei das Ermöglichen einer Sprachkommunikation das Aufbauen eines generischen Zeichengebungsschnittstellenkanals, eines Steuerkanals und eines Audiokanals zwischen dem Sender und dem Empfänger umfasst.
Verfahren nach Anspruch 13, wobei der Steuerkanal einen TCP/IP-Socket umfasst.
Verfahren nach Anspruch 13, wobei der Audiokanal einen UDP-Kanal oder einen TCP-Kanal umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Sender und der Empfänger Benutzer sind.
Verfahren nach Anspruch 1, wobei das Ermöglichen, dass der Empfänger den Knopf auswählt, um eine Sprachkommunikation aufzurufen, umfasst zu ermöglichen, dass der Empfänger den Knopf zum Aufrufen einer Sprachkommunikation als Reaktion auf das Liefern der Text-Instant-Message an den Empfänger auswählt.
Verfahren nach Anspruch 1, wobei die Darstellung der ersten Text-Instant-Messaging-Grafikbenutzerschnittstelle (800), die eine Funktion der Kommunikation der Text-Instant-Message ist, umfasst, die erste Text-Instant-Messaging-Grafikbenutzerschnittstelle nicht darzustellen, wenn die Text-Instant-Message von dem Empfänger nicht empfangen wird.
Verfahren nach Anspruch 1, weiterhin umfassend: Empfangen der an einen Empfänger adressierten Text-Instant-Message bei dem Instant-Messaging-Host (390, 490, 590).
Verfahren nach einem der vorhergehenden Ansprüche, weiterhin umfassend: Liefern der Text-Instant-Message an den Empfänger.
Verfahren nach Anspruch 4, wobei die Darstellung der ersten Text-Instant-Messaging-Grafikbenutzerschnittstelle weiterhin eine Funktion davon ist, dass bestimmt wird, dass der Empfänger zum Annehmen von Sprachkommunikationen in der Lage ist.
Kommunikationsvorrichtung, umfassend einen Instant-Messaging-Host (390, 490, 590), konfiguriert zum: Aufbauen einer Instant-Messaging-Kommunikationssitzung zwischen einem Sender und einem Empfänger und Ermöglichen, dass der Empfänger eine Sprachkommunikation zwischen dem Sender und dem Empfänger unter Verwendung des Instant-Messaging-Host (390, 490, 590) aufruft; DADURCH GEKENNZEICHNET, DASS: die Instant-Messaging-Kommunikationssitzung eine Text-Instant-Messaging-Kommunikationssitzung ist; UND DADURCH, DASS: die Vorrichtung weiter konfiguriert ist zum: Erleichtern des Sendens einer Text-Instant-Message von dem Sender an den Empfänger während der Sitzung, wobei die Text-Instant-Message einen von dem Sender eingegebenen Textkörper enthält; und Ermöglichen einer Darstellung einer ersten Text-Instant-Messaging-Grafikbenutzerschnittstelle (800) für den Empfänger, die eine Anzeige des Textkörpers und einen Knopf enthält, wobei die Darstellung der ersten Text-Instant-Messaging-Grafikbenutzerschnittstelle (800) von der Kommunikation der Text-Instant-Message zwischen dem Sender und dem Empfänger abhängt; und Ermöglichen, dass der Empfänger eine Sprachkommunikation zwischen dem Sender und dem Empfänger aufruft, indem dem Empfänger ermöglicht wird, den Knopf auszuwählen.
Vorrichtung nach Anspruch 22, wobei der Instant-Message-Host (390, 490, 590) konfiguriert ist, dem Empfänger das Auswählen des Knopfs zum Aufrufen von Sprachkommunikation zu ermöglichen, indem dem Empfänger ermöglicht wird, den Knopf zum Aufrufen von Sprachkommunikation als Reaktion auf die Lieferung der Text-Instant-Message an den Empfänger auszuwählen.
Kommunikationsvorrichtung nach Anspruch 22, wobei die Darstellung der ersten Text-Instant-Messaging-Grafikbenutzerschnittstelle (800), die eine Funktion der Kommunikation der Text-Instant-Message ist, umfasst, die erste Text-Instant-Messaging-Grafikbenutzerschnittstelle (800) nicht darzustellen, wenn die Text-Instant-Message von dem Empfänger nicht empfangen wird.
Computerprogramm, auf einem computerlesbaren Medium gespeichert, umfassend Codemittel, die angepasst sind, um die folgenden Schritte auszuführen, wenn das Programm auf einem Datenverarbeitungssystem läuft: Aufbauen einer Instant-Messaging-Kommunikationssitzung zwischen einem Sender und einem Empfänger unter Verwendung eines Instant-Messaging-Host (390, 490, 590) und Ermöglichen, dass der Empfänger eine Sprachkommunikation zwischen dem Sender und dem Empfänger unter Verwendung des Instant-Messaging-Host (390, 490, 590) aufruft; DADURCH GEKENNZEICHNET, DASS: die Instant-Messaging-Kommunikationssitzung eine Text-Instant-Messaging-Kommunikationssitzung ist; UND DASS: das Programm weiterhin Codemittel umfasst, die angepasst sind, um die folgenden Schritte auszuführen, wenn das Programm auf einem Datenverarbeitungssystem lauft: Erleichtern des Sendens einer Text-Instant-Message von dem Sender an den Empfänger während der Sitzung, wobei die Text-Instant-Message einen von dem Sender eingegebenen Textkörper enthält; und Ermöglichen einer Darstellung einer ersten Text-Instant-Messaging-Grafikbenutzerschnittstelle (800) für den Empfänger, die eine Anzeige des Textkörpers und einen Knopf enthält, wobei die Darstellung der ersten Text-Instant-Messaging-Grafikbenutzerschnittstelle von der Kommunikation der Text-Instant-Message zwischen dem Sender und dem Empfänger abhängt; wobei das Codemittel, das dafür ausgelegt ist, wenn es auf einem Datenverarbeitungssystem läuft, dem Empfänger das Aufrufen einer Sprachkommunikation zwischen dem Sender und dem Empfänger zu ermöglichen, dafür ausgelegt ist, dem Empfänger zu ermöglichen, den Knopf zum Aufrufen der Sprachkommunikation zwischen dem Sender und dem Empfänger auszuwählen.
Computerprogramm nach Anspruch 25, wobei das computerlesbare Medium eine Disk ist.
Computerprogramm nach Anspruch 25, wobei das computerlesbare Medium eine Client-Einrichtung ist.
Computerprogramm nach Anspruch 25, wobei das computerlesbare Medium eine Host-Einrichtung ist.
Computerprogramm nach einem der Ansprüche 25 bis 28, wobei die Anweisungen zum Ermöglichen, dass der Empfänger den Knopf zum Aufrufen von Sprachkommunikationen auswählt, Anweisungen beinhalten, um zu ermöglichen, dass der Empfänger den Knopf zum Aufrufen von Sprachkommunikation als Reaktion auf die Lieferung der Text-Instant-Message an den Empfänger auswählt.
Computerprogramm nach einem der Ansprüche 25 bis 29, wobei die Darstellung der ersten Text-Instant-Messaging-Grafikbenutzerschnittstelle (800), die eine Funktion des Empfangs der Text-Instant-Message ist, umfasst, die erste Text-Instant-Messaging-Grafikbenutzerschnittstelle nicht darzustellen, wenn die Text-Instant-Message von dem Empfänger nicht empfangen wird.