JP2005507200A - バンド幅最オプティマイザを用いるグループ・ビデオ会議システムおよび方法 - Google Patents
バンド幅最オプティマイザを用いるグループ・ビデオ会議システムおよび方法 Download PDFInfo
- Publication number
- JP2005507200A JP2005507200A JP2003538920A JP2003538920A JP2005507200A JP 2005507200 A JP2005507200 A JP 2005507200A JP 2003538920 A JP2003538920 A JP 2003538920A JP 2003538920 A JP2003538920 A JP 2003538920A JP 2005507200 A JP2005507200 A JP 2005507200A
- Authority
- JP
- Japan
- Prior art keywords
- client
- communication speed
- video
- transmission
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims description 15
- 230000005540 biological transmission Effects 0.000 claims abstract description 73
- 238000004891 communication Methods 0.000 claims description 81
- 238000012544 monitoring process Methods 0.000 claims description 3
- 230000004044 response Effects 0.000 claims description 3
- 238000004590 computer program Methods 0.000 claims 4
- 238000010586 diagram Methods 0.000 description 22
- 239000012634 fragment Substances 0.000 description 16
- 230000033228 biological regulation Effects 0.000 description 13
- 239000003381 stabilizer Substances 0.000 description 12
- 230000006870 function Effects 0.000 description 8
- 238000012545 processing Methods 0.000 description 6
- 230000007423 decrease Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 230000001105 regulatory effect Effects 0.000 description 4
- 238000012546 transfer Methods 0.000 description 3
- 239000000872 buffer Substances 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000001747 exhibiting effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
- H04L12/1827—Network arrangements for conference optimisation or adaptation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0852—Delays
- H04L43/0864—Round trip delays
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/11—Identifying congestion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2416—Real-time traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
- H04L47/263—Rate modification at the source after receiving feedback
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/28—Flow control; Congestion control in relation to timing considerations
- H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
- H04L47/365—Dynamic adaptation of the packet size
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/403—Arrangements for multi-party communication, e.g. for conferences
- H04L65/4038—Arrangements for multi-party communication, e.g. for conferences with floor control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Environmental & Geological Engineering (AREA)
- Physics & Mathematics (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
ネットワーク上にマルチメディアの伝送を送受信するためのシステムは、２台以上のクライアントとサーバとを含む。各々のクライアントは、ネットワークに接続されており、オーディオおよびビデオデータを生成するとともにネットワークを介してそれらを受信する。サーバは、クライアントからオーディオおよびビデオデータを受信し、オーディオおよびビデオデータをクライアントに送信する。オーディオおよびビデオデータを伝送する間、クライアントとサーバは、オーディオおよびビデオデータを伝送すべき速度を動的に決定する。
【選択図】図１
【選択図】図１
Description
【発明の開示】
【０００１】
関連出願とのクロスリファレンス
この出願は、スペンサーらによる、「可変バンド幅を有するグループ・ビデオ会議システムおよび方法（System and Method for Group Video Teleconferencing with Variable Bandwidth）」、２００１年８月２４日に出願された米国特許出願番号０９／９３８，７２１号の一部継続出願である。出展明示により内容の全文をここに取り込む。
【０００２】
技術分野
本発明は、ビデオ会議に関し、特に、ビデオ会議中にバンド幅の有用性に基づいて通信速度を変化させることに関する。
【０００３】
背景技術
現在のビデオ会議技術では、比較的に、長い待ち時間、低い効率および劣ったスケーラビリティが問題となっている。この理由の１つは、現在の技術が、通信速度およびパケットサイズに対して、「最小の共通バンド幅」を用いることにある。したがって、複数のクライアントが同時に会議を行う場合、ビデオデータの伝送は、最小のバンド幅で可能なのと同じくらいだけ高速である。その結果、いくつかのクライアントが比較的低速のダイヤルアップ接続を用いる一方、他がＴ１，ＤＳＬまたは類似したブロードバンド接続を用いる会議では、ブロードバンド接続を用いるそれらのクライアントは、それらの能力を利用することで、ダイヤルアップ接続の速度でのみデータを受信することになる。
【０００４】
現在のビデオ会議技術は、ビデオフレーム伝送蓄積転送方法を用いる。ビデオフレームが開設される度に、それらは、開設しているコンピュータ上のそれら全てに格納される。これは、サーバ上に大容量の利用可能なメモリを必要とし、サーバの作業負荷を増加させることになる。その結果、従来のシステムは、劣ったスケーラビリティを有し、待ち時間を増加させた。
【０００５】
現在のビデオ会議技術は、ファイアウォールまたはプロキシサーバを通過させようとした場合、しばしば困難に遭遇する。ファイアウォールは、ビデオ会議技術で一般的であるプロトコル、ＵＤＰ（User Datagram Protocol）を用いて送信されたデータと互換性を持たない。プロキシサーバは、リクエストをフィルタリングするために用いられ、この結果、ビデオ会議トラヒックを多くの場合含むトラヒックの特定のタイプを除去することになる。
【０００６】
発明が解決しようとする課題
前述した限界を考慮すれば、ビデオ会議システムにとって、全てのクライアントのバンド幅能力のより良い利点を得て、待ち時間を短縮し、スケーラビリティを向上させ、ファイアウォールとプロキシサーバとの互換性を持つ必要性がある。
【０００７】
課題を解決するための手段
本発明は、層サーバ・アーキテクチャを含むデータを動的に伝送するためにシステムを提供することにより、待ち時間を短縮し、かつマルチメディア・グループ会議の効率を向上させる。マルチメディア・グループ会議のためにシステムを用いているクライアントは、ネットワークに接続されており、該ネットワークを介して、オーディオおよびビデオデータを送受信する。クライアントがシステムにアクセスすると、サーバの１つが、クライアントへの接続で利用可能な最大バンド幅を決定する。そして、サーバは、伝送されているデータの適当な通信速度およびパケットサイズを確立する。マルチメディアデータを伝送している間、バンド幅オプティマイザは、最も効率的な通信速度を決定するために、パケット損失の実際の上下通信時間および通信速度をモニタリングする一方、通信速度を調整する。バンド幅オプティマイザは、バックログが検出されると、データに対するパケットサイズおよび伝送間隔を減少させることにより、データ通信速度を低下させる。バンド幅オプティマイザは、バックログが検出されない場合、バックログが再び検出されるまで、データ通信速度を徐々に増加させる。
【０００８】
発明を実施するための最良の形態
図１は、本発明を含むシステムの典型的な実施形態の図である。システムは、ネットワーク１００、ルータ１１２、１つ以上のクライアント１０２、および１つ以上のサーバ１０４を含んでいる。典型的な実施形態では、２つ以上のクライアントは、ネットワーク１００を介して、互いにマルチメディアデータを送受信する。サーバ１０４は、クライアントからクライアントへのデータの正確な伝送のために必要とされる如何なるマルチメディア機能をも容易にする。ルータ１１２には、サーバ１０４への、あるいはサーバ１０４からのデータフローを容易にする、一般的な任意のルーティング機器が用いられる。典型的な実施形態では、層サーバ・アーキテクチャは、エントリサーバ１０６、ロビーサーバ１０８およびルームサーバ１１０（ひとまとめにしてサーバ１０４）のいくつか、または全てを含んでいる。ロビーおよびルームのメタファは、ロード・バランシングと場所重視の会議環境とを容易にする。個人との会議を選択する代わりに、各クライアント１０２は、ロビー、および該ロビー内のルームに入室することを選択する。オンライン・チャットルームと同様に、各クライアント１０２は、ルーム内の１つ以上の他のクライアントにオーディオ、ビデオおよびデータを送信することができる。
【０００９】
サーバ１０４は、ネットワーク１００を介してクライアント１０２に接続されている。典型的な実施形態では、ネットワーク１００は、インターネット、専用ネットワークまたはイントラネットであってもよいが、他のネットワークを用いることもでき、ネットワークの特定の形態に限定されない。あるいは、いくつかの実施形態では、サーバ１０４およびクライアント１０２は、ネットワーク１００を通過することなく、間接または直接、通信してもよい。クライアント１０２は、オーディオおよびビデオ信号を容易に送受信するために、多くのオーディオおよびビデオ機器構成を備えていてもよい。この機器は、ビデオ表示ユニット、スピーカ、マイクロフォン、カメラ、および、以下で説明する会議機能を実装するための適切なソフトウェアを実行する処理ユニットを含んでいてもよい。クライアント１０２の典型的な構成については、以下で、図４を参照してより詳細に説明する。
【００１０】
マルチメディアデータを送受信するためには、クライアント１０２は、サーバ１０４と情報を交換する。典型的な実施形態は、１つまたは２つのエントリサーバ１０６を含んでいるが、システムは、エントリサーバ１０６の数に制限されない。エントリサーバ１０６は、ログイン処理中にパスワード暗号化を提供することを含む、ログイン・クライアント１０２の管理機能を担う。エントリサーバ１０６は、利用可能なロビーのディレクトリを維持し、各クライアント１０２がロビーを選択することを可能とし、そのクライアント１０２がそのロビーに入るための許可を有することを確実にすることを担う。エントリサーバ１０６に含まれる唯一の状態情報は、利用可能なロビーのディレクトリであるので、エントリサーバ１０６は、容易に集められる。また、エントリサーバ１０６は、バンド幅、待ち時間およびプロトコル有用性のクライアントイニシエート分析で支援する。クライアントがログインすると、クライアント１０２およびエントリサーバは、クライアント１０２へ、またはクライアント１０２からの接続のバンド幅を確立し、ＵＤＰが伝送プロトコルとして機能するかどうかを判定するテスト伝送を他の要求された情報とともに交換する。ＵＤＰの使用がファイアウォールまたはプロキシサーバで制限されないならば、セッション間の以後の伝送は、ＵＤＰを用いて送信される。しかしながら、ＵＤＰの使用が制限されるならば、以後の伝送は、ＴＣＰ（transmission control protocol）を用いて送信される。
【００１１】
ロビーサーバ１０８は、エントリサーバ１０６に識別情報を送信する。この情報は、ロビーにアクセスしていないクライアントのリストを含んでいる。また、ロビーサーバ１０８は、ロード・バランシング機能も実行する。クライアント１０２が新しいルームの開設を要求すると、ロビーサーバ１０８は、最小の負荷を有するルームサーバ１１０にルームを開設する。典型的な実施形態では、ロビーにログインした如何なるクライアント１０２でも、新しいルームの開設を要求することができる。あるいは、新しいルームの開設は、予め設定されたクライアント１０２、または特定の基準を満たすクライアントに限定されてもよい。いずれかのクライアント１０２によるルームの使用は、開設しているクライアント１０２に課金されるので、例えば、新しいルームの開設をリクエストすることは、支払い請求情報を与えられているクライアント１０２に制限されてもよい。他の例として、クライアント１０２は、物議をかもしたり、公序良俗に反したり、それ以外でも何らかの制限事項を含むルームの開設を、規制してもよい。
【００１２】
典型的な実施形態では、新しいルームの開設を要求しているクライアント１０２、またはモデレータには、会議に関して特別な制御特権が与えられる。例えば、モデレータは、特定のクライアント１０２が、会議に参加し続けることを防止したり、クライアント１０２が情報の特定のタイプにアクセスすることを制御したり、ルームを閉じたりする。また、モデレータは、他のクライアント１０２へ特権を委任してもよい。典型的な実施形態では、ロビーサーバ１０８は、複数のルームサーバ１１０、例えば７つ以上のルームサーバ１１０を支援してもよい。クライアント１０２は、ロビーから、新しいルームの開設を要求する、あるいは既存のルームに入室する、というオプションを有する。
【００１３】
典型的な実施形態では、ルームサーバ１１０は、システムのマルチメディア機能を容易にする。ルームサーバ１１０は、以下で、図３を参照してより詳細に説明される。図１は、考えられるアーキテクチャの一例のみを示し、本発明は、図１に示す典型的なアーキテクチャに限定されない。例えば、エントリサーバ１０６、ロビーサーバ１０８またはルームサーバ１１０の数が変化するように、サーバ１０４の全数は、変化してもよい。また、システムに含まれるサーバには、他のタイプがあってもよい。代替の実施形態では、システムは、ルータ１１２なしで動作してもよい。また、クライアント１０２およびサーバ１０４は、中間のネットワーク接続なしで、直接接続されてもよい。
【００１４】
図２は、本発明の典型的な実施形態に従うマルチメディア・ストリーミング図である。クライアント１０２Ａ、１０２Ｂ、１０２Ｎ（ひとまとめにしてクライアント１０２）は、ルームサーバ１１０を介して、互いに、オーディオおよびビデオデータを交換する。各クライアント１０２は、送信機２０４および受信機２０２を含んでいてもよい。ルームサーバ１１０は、ルームサーバ１１０を通して送信している各クライアント１０２に対して、固有の受信機２１０および送信機２１２を設置する。クライアント１０２は、図２に示されていないネットワーク１００を介してルームサーバ１１０に接続されている。クライアント１０２およびルームサーバ１１０については、以下に、図３及び図４を参照して、より詳細に説明する。
【００１５】
オーディオデータ２１６およびビデオデータ２１４は、開設しているクライアント１０２の送信機２０４から、サーバ１１０のクライアント１０２に対する受信機２１０に送信される。典型的な実施形態では、各クライアント１０２は、見るため、聞くためにビデオおよびオーディオを選択する。これらの選択は、加入者リストおよび申込みリストの使用を通して容易に行われる。加入者リストは、ルームで他のクライアントにデータを再配布するために受信機２０２、２１０と連携して用いられる。受信機２０２、２１０の各々は、オーディオデータに対して１つの加入者リストに、ビデオデータに対して１つの加入者リストにグループ化されている。加入者リストは、与えられたオーディオ・ストリームまたはビデオストリームを申し込んだ、それらのクライアントを識別する。申込みリストは、データを多重送信することができるので、ビデオ・ストリームを特定のビデオチャネルに関連ビデオストリーム信機２０４、２１２と連携して用いられる。送信機２０４、２１２の各々は、オーディオに対して１つの申込みリストに、ビデオに対して１つの申込みリストにグループ化されている。申込みリストは、オーディオおよびビデオが送信される、加入者リスト上のクライアントを識別する。ゆえに、加入者リストのクライアントは、オーディオおよびビデオを受信し、申込みリストのクライアントは、オーディオおよびビデオを送信することになる。典型的な実施形態では、各クライアント１０２が一度に１つのオーディオ・ストリームだけを聞くことになるので、オーディオ申込みリストは、１つのエントリだけを含むことになる。代替の実施形態では、システムは、マルチ・チャネル・オーディオをサポートしてもよく、この場合、オーディオ・ストリームは、ビデオストリームと同様の方法で多重送信される。ビデオ申込みリストは、同時に表示される各ビデオ・ウインドウに対して１つ、最大８つのエントリを含んでもよい。
【００１６】
加入者リストと申込みリストとにおける情報に基づいて、ルームサーバ１１０の送信機２１０は、ビデオおよびオーディオ・ストリーム２１４、２１６を、ルームサーバ１１０内の受信するクライアント１０２の送信機２１２へ送信する。それから、送信機２１２は、ビデオおよびオーディオを、それぞれのクライアント１０２に送信する。マルチメディアデータの送信については、以下で、図３および図４を参照してより詳細に説明する。
【００１７】
図２に示される実施例において、クライアント１０２Ａは、ビデオデータ２１４Ａおよびオーディオデータ２１６Ａを送信している。図示の他の２つのクライアント、すなわちクライアント１０２Ｂ、１０２Ｎは、各々、ビデオデータ２１４Ｂ、２１４Ｎを送信している。クライアント１０２Ａは、それ自身のビデオ２１４Ａと、クライアント１０２Ｂからのビデオ２１４Ｂを受信している。この結果、送信機２１２Ａに対するビデオ申込みリストは、クライアント１０２Ａ、１０２Ｂを含み、受信機２０２Ａ、２０２Ｂの双方に対する加入者リストは、クライアント１０２Ａを含むことになる。図示する実施形態において、クライアント１０２Ａのビデオ２１４Ａは、ネットワーク１００を介して、ルームサーバ１１０に送信されて戻ることに注目する。代わりの実施形態では、クライアント１０２Ａは、ネットワークを介して送信されて戻るビデオ２１４Ａなしの直接フィードバックとして、ローカル・ビデオ・イメージを見ることになる。この直接フィードバックは、待ち時間を短縮し、スケーラビリティを向上させる。クライアント１０２Ｂは、クライアント１０２Ａからビデオ２１４Ａおよびオーディオ２１６Ａを受信し、クライアント１０２Ｎからビデオ２１４Ｎを受信している。クライアント１０２Ｎは、クライアント１０２Ａからビデオ２１４Ａおよびオーディオ２１６Ａを受信し、クライアント１０２Ｂからビデオ２１４Ｂを受信している。クライアント１０２Ｂ、１０２Ｎが最初にこのオーディオおよびビデオデータの見聞きを要求する時に、関連する申込みおよび加入者リストがアップデートされる。
【００１８】
クライアント１０２Ａの送信機２０４Ａは、クライアント１０２Ａで開設されたオーディオ・ストリーム２１６Ａとビデオストリーム２１４Ａを、ルームサーバ１１０の受信機２１０Ａに送信する。受信機２１０Ａは、クライアント１０２Ｂ、１０２Ｎへの伝送のために、オーディオ・ストリーム２１６Ａを、送信機２１２Ｂおよび送信機２１２Ｎの各々に送信する。受信機２１０Ａは、クライアント１０２Ａ、１０２Ｂ、１０２Ｎへの伝送のために、ビデオストリーム２１４Ａを、送信機２１２Ａ、２１２Ｂおよび２１２Ｎの各々に送信する。クライアント１０２Ｂの送信機２０４Ｂは、クライアント１０２Ｂで開設されたビデオストリーム２１４Ｂを、ルームサーバ１１０の受信機２１０Ｂに送信する。受信機２１０Ｂは、クライアント１０２Ａおよび１０２Ｎへの伝送のために、ビデオストリーム２１４Ｂを、送信機２１２Ａおよび２１２Ｎの各々に送信する。送信機２０４Ｎは、クライアント１０２Ｎで開設されたビデオストリーム２１４Ｎを、ルームサーバ１１０の受信機２１０Ｎへ送信する。受信機２１０Ｎは、クライアント１０２Ｂへの伝送のために、ビデオストリーム２１４Ｎを送信機２１２Ｂに送信する。
【００１９】
送信機２１２Ａは、ビデオ２１４Ａおよび２１４Ｂを、クライアント１０２Ａの受信機２０２Ａに送信する。送信機２１２Ｂは、ビデオ２１４Ａ、２１４Ｎおよびオーディオ２１６Ａを、クライアント１０２Ｂの受信機２１６Ａに送信する。送信機２１２Ｎは、ビデオ２１４Ａ、２１４Ｂおよびオーディオ２１６Ａを、クライアント１０２Ｎの受信機２０２Ｎへ送信する。送信機２１２Ａ、２１２Ｂ、２１２Ｎからのこれら送信は、これら送信に対するそれぞれの申込みリストによって管理される。
【００２０】
ビデオおよびオーディオ送信に加えて、クライアントは、スライドショー・プレゼンテーション、テキスト文書、写真画像、音楽ファイルなどのようなデータを送信してもよい。図２に示すビデオおよびオーディオ・ストリームにように、データストリームは、いずれかのクライアント１０２から１つ以上の受信クライアント１０２に送信されてもよい。図２には、３つのクライアント１０２が示されているが、各々に、ルームサーバ１１０の固有の送信機２１２および受信機２１０を有する、如何なる数のクライアント１０２があってもよい。
【００２１】
図３は、本発明の典型的な実施形態によるルームサーバのブロック図である。ルームサーバ１１０は、一対の受信機２１０と送信機２１２を、ゼロ、または１つ以上含んでいてもよい。典型的な実施形態において、受信機２１０および送信機２１２は、ソフトウェアで実装され、ルームサーバ１１０は、マルチメディアデータを送受信している各クライアント１０２に対して、固有の受信機２１０と送信機２１２とを開設する。受信機２１０は、シーケンサ３０６を含んでいてもよい。送信機２１２は、オーディオ再シーケンサ３０８、ビデオ再シーケンサ３１０、マルチメディア・オーディオ・キュー３１２、ビデオ・マルチプレクサ３１４およびパケット・エンコーダ３１６のいくつか、または全てを含んでもいてもよい。
【００２２】
各受信機２１０は、クライアント１０２からマルチメディアデータを受信するためにネットワーク１００に接続されている。また、受信機２１０は、１つ以上の送信機２１２に接続されている。受信機２１０は、クライアント１０２から受信したデータを送信機２１２に転送する。また、送信機２１２は、ネットワーク１００に接続されており、受信機２１０により送信機２１２に転送されたデータは、ネットワーク１００を介して受信クライアント１０２に送信される。
【００２３】
ルームサーバ１１０は、送信しているクライアント１０２からマルチメディア・ブロックの形態でデータを受信する。典型的な実施形態において、マルチメディア・ブロックは、シーケンス番号、オーディオフレーム、ビデオフラグメント、ビデオチャネル、レシート、ビデオパラメータ、オーディオパラメータ、ビデオ・エンド・フラグおよびオーディオ・エンド・フラグのいくつか、あるいは全てを含むデータパケットのタイプである。シーケンス番号は、マルチメディア・ブロックがオーディオまたはビデオデータを含んでいる場合、マルチメディア・ブロックを再オーダするために用いられる。マルチメディア・ブロックがオーディオデータを含んでいる場合には、このデータは、オーディオフレームの形態である。マルチメディア・ブロックがビデオデータを含んでいる場合には、このデータは、ビデオフラグメントの形態である。ビデオフラグメントは、ビデオフレームのスタート、ミドル、エンドを表すデータ構造である。また、ビデオフラグメントは、全ビデオフレームまたは前の伝送中にビデオフラグメントが失われたことを示す特別な値であってもよい。ビデオチャネルは、ビデオデータがある場合、ビデオフラグメントに割り当てられたチャネルである。受理証は、他のパーティにより受信されたマルチメディア・ブロックのシーケンス番号の最新のものである。受理証は、以下で、図６を参照して説明されるように、バンド幅の配分を決定する際に用いられる。ビデオおよびオーディオパラメータは、新しいビデオまたはオーディオデータを送信し始めるとき、マルチメディア・ブロックの一部として送信される。ビデオおよびオーディオ・エンド・フラグは、オーディオまたはビデオ送信の終わりを示す。ビデオデータに対する、パラメータおよびエンド・フラグは、新しいチャネルでデータを送信し始めることか、ビデオストリームの終端でチャネルを閉じることを含む。一実施形態において、オーディオデータは、ビデオデータより高い優先順位を有してもよく、ゆえに、データを送信できない場合、オーディオデータの精度を保証する。この場合、マルチメディア・ブロックは、全ての利用可能なオーディオデータを含む。典型的な実施形態では、シーケンサ３０６は、マルチメディア・ブロックを受信し、それらをオーディオ・メディア・ブロックおよびビデオ・メディア・ブロックに分離する。また、シーケンサ３０６は、マルチメディア・ブロックの適切な順序を保証するために、ネットワーク１００を介して受信したマルチメディア・ブロックに対するシーケンス番号を用いる。シーケンサ３０６は、次の予想されるマルチメディア・ブロックの受領まで、シーケンスから外れたマルチメディア・ブロックを一時的に格納する。見失ったマルチメディア・ブロックが、格納領域が使い果たされる前に受信されなくなると、シーケンサ３０６は、マルチメディア・ブロックが失われたと見なす。
【００２４】
オーディオ・メディア・ブロックは、シーケンサ３０６から送信機２１２のオーディオ再シーケンサ３０８にルームサーバ１１０によって転送される。シーケンサ３０６のように、オーディオ再シーケンサ３０８は、オーディオ・メディア・ブロックからのオーディオデータを、適切な順序で、すなわちそれらが生成された順序に配置する。典型的な実施形態では、オーディオ再シーケンサ３０８は、それがパケット損失を取り扱わないという点でシーケンサ３０６と異なる。その結果、シーケンスから外れて受信されたパケットに対してより一時的な格納を実現する。オーディオ再シーケンサ３０８からは、順番に配列されたオーディオ・メディア・ブロックが、マルチメディア・オーディオ・キュー３１２に送信される。マルチメディア・オーディオ・キュー３１２は、付加的なマルチメディアデータを受け入れるために受信クライアント１０２に利用可能なバンド幅があるまで、オーディオ・メディア・ブロックをバッファリングする。オーディオ・メディア・ブロックは、マルチメディア・ブロックを形成するために、ビデオ・メディア・ブロックに結合され、ネットワーク１００または如何なる確立された伝送接続を介して、受信クライアント１０２に送信される。
【００２５】
ルームサーバ１１０は、ビデオ・メディア・ブロックをビデオ再シーケンサ３１０に転送する。典型的な実施形態では、８つのビデオチャネルの各々に対して１つのビデオ再シーケンサがある。各チャンネルは、クライアント１０２のディスプレイ４０４上の固有の表示ウインドウに表示されるビデオデータを取り扱う。ゆえに、８つのビデオチャネルを有する典型的な実施形態では、８つ以上の同時に表示されたビデオストリームがあることになる。ビデオ・メディア・ブロックは、ビデオ・マルチプレクサ３１４に転送される。
【００２６】
ビデオ・マルチプレクサ３１４は、各ビデオチャネルに対してビデオ・キューを含んでいる。ビデオ・キューは、ＦＩＦＯ（first in first out）であり、ビデオフラグメントを格納する。ビデオフラグメントは、全ビデオフレーム、ビデオフレームのスタート、ビデオフレームのミドル、ビデオフレームのエンド、または失われたビデオフラグメントを表す特別な値であってもよい。典型的な実施形態では、ビデオフラグメントの特定のシーケンスだけがビデオ・キューに入力されてもよい。例えば、「スタート」の後に「ミドル」が続き、「ミドル」の後に「エンド」が続くことになるが、「スタート」は、他の「スタート」の後に続くことはない。ビデオ・キュー内のフラグメントを配列することは、フラグメントからビデオフレームの再構成を容易にする。全ビデオフレームまたはビデオフレームの特定のバイト数は、ビデオ・キューから出力されてもよい。例えば、ビデオ・キューが２００バイトの「スタート」フラグメントを格納していた場合、キューは、要求があれば、キュー内の次のフラグメントとして１００バイトの「ミドル」フラグメントを放置して、１００バイトの「スタート」フラグメントを出力することになる。
【００２７】
ビデオ・マルチプレクサ３１４内のビデオ・キューは、ビデオデータに対するバッファとして機能する。ビデオ・メディア・ブロックがビデオ・マルチプレクサ３１４による順序で受信されるように、それらは、ビデオ・キュー内の完全なビデオフレームに組み立てられる。一度、全ビデオフレームが組み立てられると、ビデオデータを受け入れるための受信クライアント１０２への接続に利用可能なバンド幅がない場合、ビデオ・キューは、フレームを落とすことになる。バンド幅が受信クライアント１０２への接続に利用可能になると、ビデオ・メディア・ブロックは、パケット・エンコーダ３１６に送信され、マルチメディア・ブロックを形成するためにオーディオ・メディア・ブロックに結合される。マルチメディア・ブロックは、ネットワーク１００または何らかの確立された伝送接続を介して受信クライアント１０２に送信される。
【００２８】
図４は、本発明の典型的な実施形態によるクライアント１０２のブロック図である。一実施形態において、クライアント１０２は、受信機２０２、送信機２０４、ディスプレイ４０４、スピーカ４０６、カメラ４０８およびマイクロフォン４１０を含んでいる。各クライアント１０２は、マルチメディアデータを送受信することができる。
【００２９】
送信側では、カメラ４０８は、ビデオ・イベントを生成し、マイクロフォン４１０は、オーディオ・イベントを生成する。ビデオ・イベントは、ビデオ・マルチプレクサ３１４に送信される。ルームサーバ１１０のビデオ・マルチプレクサ３１４のように、クライアントのビデオ・マルチプレクサ３１４は、多重ビデオ信号を取り扱うために多重チャネルを有する。ゆえに、クライアント１０２は、複数のビデオカメラを含んでいてもよい。また、ルームサーバ１１０のビデオ・マルチプレクサ３１４のように、クライアント１０２のビデオ・マルチプレクサ３１４は、バンド幅要求を減少するために、ビデオフレームを配列するため、およびドロップするために用いられる、各チャネルに対してビデオ・キューを含んでいる。
【００３０】
オーディオ・イベントは、マイクロフォン４１０からマルチメディア・オーディオ・キュー３１２に送信される。バンド幅がデータを送信するために利用可能になると、ビデオ・メディア・ブロックとオーディオ・メディア・ブロックは、パケット・エンコーダ３１６に送信され、マルチメディア・ブロックを形成するために結合される。マルチメディア・ブロックは、ネットワーク１００または何らかの確立された伝送接続を介して、ルームサーバ１１０へ送信される。
【００３１】
受信側では、受信機２０２は、ネットワーク１００を介して、ルームサーバ１１０からマルチメディア・ブロックを受信する。受信機２０２内のシーケンサ３０６は、適切な順序にマルチメディア・ブロックを順序付けて、それらをビデオ・メディア・ブロックとオーディオ・メディア・ブロックとに分離する。オーディオ・メディア・ブロックは、スピーカ４０６に送信され、サウンドに変換される。該サウンドは、特定の実施に従ってアナログまたはデジタルいずれの形式で生成されてもよい。ビデオ・メディア・ブロックは、ビデオ・デマルチプレクサ４０２へ送信され、別個のビデオフレームに分解される。ビデオ・マルチプレクサ３１４と同様に、ビデオ・デマルチプレクサ４０２は、ビデオフレームを組み立てるため、およびビデオフレームをドロップするために用いられる、ビデオ・キューを含む。ビデオフレームは、ビデオディスプレイ４０４へ送信され、従来の方法で表示される。
【００３２】
図５は、本発明の典型的な実施形態によるスレッディング・モデルのブロック図である。マルチメディア伝送に加えて、ルームサーバ１１０の受信機２１０および送信機２１２は、それらの各々のクライアント１０２へ要求を送信するとともに、クライアント１０２からリクエストを受信する。これらの事象には、オーディオまたはビデオを特定のクライアントに送信するというリクエスト、特定のクライアントのビデオを見るというリクエスト、見ているビデオからクライアントを遮断するというリクエストなどを含む。モデレータの地位を割り当てられたクライアントは、モデレータに制限されるリクエストを行うことになる。これらリクエストの例には、クライアントを退場させるというリクエスト、特定のデータタイプにアクセスするべく特定のクライアントに特権を与えるというリクエスト、ルームを閉じるというリクエスト、または他のクライアントにモデレータの任務を与えるというリクエストが含まれる。
【００３３】
図５に示すような典型的な実施形態では、リクエスト・プロセッサ５００は、入力イベント・スレッド・プール５０２、メイン・スレッド・プール５０４、出力イベント・スレッド・プール５０６およびリクエスト・キュー５０８を含んでいる。入力イベント・スレッド・プール５０２は、受信機２１０およびリクエスト・キュー５０８に接続されている。リクエスト・キュー５０８は、入力イベント・スレッド・プール５０２、メイン・スレッド・プール５０４および出力イベント・スレッド・プールに接続されている。メイン・スレッド・プール５０４は、リクエスト・キュー５０８に接続されている。出力イベント・スレッド・プール５０６は、リクエスト・キュー５０８および送信機２１２に接続されている。リクエスト・プロセッサ５００は、メモリに格納され、コンピュータ・プロセッサにより実行されるソフトウェアコードであってもよいが、本発明は、この実施形態に制限されない。典型的な実施形態では、メモリおよびコンピュータ・プロセッサは、ルームサーバ１１０の構成部品である。ソフトウェア命令は、フロッピーディスク（登録商標）、ＣＤ-ＲＯＭ、または何らかの他の適当な記憶媒体のようなコンピュータで可読な媒体に格納されていてもよい。リクエスト・プロセッサ５００内の構成部品の接続は、ソフトウェアコードにより定義される論理的な接続であってもよい。
【００３４】
受信機２１０は、入力リクエストをクライアント１０２からリクエスト・プロセッサ５００へ送信する。入力リクエストは、処理のために入力イベント・スレッド・プール５０２へ送信される。入力リクエストは、即時応答と長期動作を要求するリクエストを含んでいる。即時応答を要求する入力リクエストは、ＴＣＰを介して送信される入力ネットワーク・トラヒックを取り扱うために作られる。長期動作である入力リクエストは、接続が伝送プロトコルとしてＵＤＰを支持する場合、ＵＤＰを介して送信される入力ネットワーク・トラヒックを取り扱うために作られる。
【００３５】
出力リクエストは、処理のために出力イベント・スレッド・プール５０６に送信される。出力リクエストは、接続が伝送プロトコルとしてＵＤＰを支持する場合、ＵＤＰを介して送信される外へ向かうデータを取り扱うために作られる。出力リクエストを処理する際に、出力イベント・スレッド・プール５０６は、出力イベントを発生する。このイベントは、外へ向かうデータをクライアント１０２へ送信するために１つ以上の送信機２１２を呼び出す。
【００３６】
内部リクエストは、ルームサーバ１１０に内蔵されているタスクを実行するために用いられる。内部リクエストは、問題をロックしているか、遮断している潜在性のために入力または出力リクエストで取り扱うのに適切でない他のタスクと同様に、ルームサーバ１１０内でのオーディオおよびビデオの再送信からなる。内部リクエストは、リクエスト・キュー５０８に格納されており、スレッドが利用可能になると、メイン・スレッド・プール５０４に発送される。
【００３７】
図６は、本発明の典型的な実施形態によるダイナミックデータ伝送のフローチャートである。ダイナミックデータ伝送の処理は、伝送の最小待ち時間およびマルチメディアデータの受信を確実にするために、クライアント１０２およびルームサーバ１１０の双方によって容易にされる。クライアント１０２がエントリサーバ１０６を通してログインすることによって会議セッションを始めると、バンド幅調整器は、上下マルチメディア伝送に対する現在のバンド幅および待ち時間を決定６０２する。クライアント１０２およびルームサーバ１１０は、各々、典型的な実施形態では、ソフトウェアで実装されるバンド幅調整器を含んでいる。バンド幅および待ち時間情報に基づいて、バンド幅調整器は、各接続に対して最適なパケットサイズおよび最適なパケット間隔を決定６０４する。ルームサーバ１１０は、ジャーナル、テーブル、または他の同様なデータ構造に、送信機２１２によって送信される次のパケットに対する、パケットサイズおよび出発時間を記録６０６する。クライアント１０２は、次のパケットを送信し、ジャーナル、テーブル、または他の同様なデータ構造に、このパケットに対するパケットサイズおよび出発時間を記録６０６する。
【００３８】
一実施形態において、送信機（ルームサーバ１１０か、クライアント１０２のいずれか）は、受信機に送信すべきデータがさらにあるかどうかを判定６０８する。送信すべきデータがこれ以上ない場合には、処理を終了する。送信すべき更なるデータがある場合には、バンド幅調整器は、入ってくるマルチメディア・ストリームから受け取った各受理証に対して、ジャーナルから記録を取り除くことによりジャーナルを更新６１０する。ルームサーバ１１０では、は、受信機２１０で受理される。クライアント１０２では、受理証は、受信機２０２で受理される。また、バンド幅調整器は、失われたパケットに対してもジャーナルから記録を取り除く。そして、バンド幅調整器は、ジャーナルに残っているエントリの各々に対応している受理証に対する、予想到着時刻を決定６１２する。予想到着時刻は、パケットの出発時刻、待ち時間、出て行くパケットサイズならびに入ってくるパケットサイズ、およびバンド幅を用いることにより決定される。
【００３９】
クライアント１０２およびルームサーバ１１０でのバンド幅調整器は、いずれかのジャーナルに記録されたパケットの期限が過ぎているか否かを判断６１４するために、予想到着時刻を用いる。期限が過ぎたパケットがあった場合には、バンド幅調整器は、送信機２０４、２１２がオーディオデータのみを送信するためのモード６１６に入る。オーディオデータは、ビデオとオーディオデータが結合したものより、送信のために低いバンド幅を要求するので、データがオーディだけに限定される場合、送信の待ち時間は減少することになる。期限が過ぎているパケットがない場合には、バンド幅調整器は、送信機２０４，２１２がオーディオおよびビデオデータの双方を送信するモード６１８に入る。ビデオおよびオーディオデータを取り扱うのに十分利用可能なバンド幅が接続にある場合、期限切れのパケットはなく、バンド幅調整器は、オーディオおよびビデオデータの双方の送信を許可することになる。これらの２つのモードの間の切り替わりの結果、より小さいバンド幅接続に対して、オーディオデータは、ビデオデータの断続的な伝送とともに連続的に送信される。オーディオモード、またはオーディオおよびビデオモードのいずれかに一度入ると、クライアント１０２またはルームサーバ１１０は、次のパケットを送信６０６し、パケットサイズおよびこのパケットに対する出発時刻を記録する。
【００４０】
バンド幅オプティマイザ
図７は、バンド幅オプティマイザ７００の典型的な実施形態のブロック図である。バンド幅オプティマイザは、最も効率的な通信速度を決定するために、パケット損失の実際の上下通信時間と速度をモニタリングする一方、通信速度を調整する。典型的な実施形態では、この効率的な通信速度は、ネットワーク待ち時間またはパケット損失のいずれかのかなりの増加なしに、データを伝送することができる最大速度として定義される。典型的な実装例では、以下に述べるバンド幅オプティマイザ７００および該バンド幅オプティマイザ７００の構成部品は、ソフトウェアで実装される。ＵＤＰが伝送のために用いられたプロトコルである場合、このソフトウェアは、クライアント１０２およびルームサーバ１０６の双方に配置されてもよい。ＴＣＰが伝送のために用いられたプロトコルである場合、クライアント１０２のみに配置される。バンド幅オプティマイザ７００は、上下のマルチメディア・トラヒックのデータ内のバックログを継続してモニタする。バンド幅オプティマイザがバックログを検出した場合には、パケットサイズおよびデータに対する伝送間隔を減少させることによって、データの通信速度を低下させる。バンド幅オプティマイザがバックログを検出しない場合には、バックログが再び検出されるまで、データの通信速度を徐々に増加させる。この処理は、後でさらに詳細に説明される。
【００４１】
バンド幅オプティマイザ７００のこの実施形態は、接続アナライザ７０２、スタビライザ７０４、モニタ７０６、コントローラ７０８、規制モジュール７１０およびスロットル７１２を含んでいる。接続アナライザ７０２は、最大上下通信速度およびネットワーク待ち時間を決定する。クライアント１０２は、通信速度を手動で確立してもよいし、接続アナライザ７０２が上下通信速度およびネットワーク待ち時間を自動的に検出するように要求してもよい。典型的な配置において、それら３つの変数は、マルチメディアデータを送受信するのに先立って一度決定される。
【００４２】
スタビライザ７０４は、上下の「現在の上限」通信速度を調整する。現在の上限通信速度は、接続アナライザ７０２により決定された最大通信速度とは異なる。現在の上限通信速度は、まず、接続アナライザ７０２によって決定された最大通信速度にセットされる。スタビライザ７０４は、所定の期間にわたってバックログされるために現れた接続の時間のパーセンテージを決定することにより現在の上限通信速度を調整する。例えば、典型的な実施形態では、スタビライザ７０４は、過去２秒にわたってバックログされるために現れた接続の時間のパーセンテージを決定してもよい。この時間のパーセンテージがゼロで、かつ現在の上限通信速度が最大通信速度より小さい場合、現在の上限は、与えられたパーセンテージずつ増加する。例えば、この増加は２パーセントであってもよい。通信速度が増加すると、もうそれ以上、増加（または減少）は、増加後の与えられた期間、許可されない。一例として、増加（または減少）は、増加の後、７５０ｍｓの間許可されない。バックログされた時間のパーセンテージが２５を越える場合、現在の上限は、バックログされるために現れた接続の時間のパーセンテージずつ減少する。上限が減少すると、もうそれ以上、減少（または増加）は、与えられた期間、たとえば２秒間、許可されない。この調整は、接続アナライザ７０２からの入力および規制モジュール７１０からの入力に基づいている。典型的な実施形態では、規制モジュール７１０は、伝送の最後の２秒で検出されたバックログのパーセンテージのスタビライザ７０４に指標を送信する。スタビライザ７０４は、接続がバックログされた時間のパーセンテージを決定するために規制ジャーナルを見る。スタビライザ７０４は調整された上限を、規制モジュール７１０に送信する。
【００４３】
典型的な実施形態では、モニタは、ミリ秒でバックログ量を決定し、これをコントローラ７０８に送信する。モニタ７０６は、データパケットが遠くにある受信機に送信される時刻、送信されたデータパケットのサイズ、サーバ待ち時間に対する値と同様に、データパケットが実際に受信される時刻、および受理証を含んだ下りパケットのサイズを含む、それら遠隔地の受信機によって送信された受理証を、入力として受信する。モニタ７０６は、データパケットが受信されるべきとき、および該データパケットに対する受理証が受信されるべきときを計算するために、データパケットが送信される時刻と、既知の待ち時間情報とを用いる。待ち時間の決定については、図９を参照して以下で更に詳細に説明する。ミリ秒でバックログ量を決定するために、モニタ７０６は、データパケットおよび該データパケットに対する受理証の双方が受信されると予想される時刻の情報を取得し続け、それらの時刻を、それらが実際に受信される時刻と比較する。この情報から、モニタ７０６は、実際の通信速度を計算することができる。モニタ７０６は、実際の通信速度と予想した通信速度との間の差分を決定する。このバックログ時刻は、コントローラ７０８に送信される。
【００４４】
典型的な実施形態では、コントローラ７０８は、モニタ７０６から受信されたバックログが所定の閾値より上であるか否かを判定する。バックログが与えられた閾値より上である場合は、コントローラ７０８は、ポジティブな指標を規制モジュール７１０に送信する。そうでない場合は、コントローラ７０８は、ネガティブな指標を規制モジュール７１０に送信する。例えば、閾値が３０ミリ秒のバックログでセットされていると、コントローラ７０８は、バックログがこの閾値より上である場合、ポジティブな指標を送信することになる。
【００４５】
規制モジュール７１０は、スタビライザ７０４から現在の上限通信速度を受信し、コントローラ７０８から指標を受信する。指標がポジティブである場合、規制モジュールは、現在の通信速度を、所定の最小通信速度に制限する。指標がネガティブである場合、規制モジュールは、現在の通信速度として現在の上限通信速度を用いる。結果として生じる現在の通信速度は、スロットル７１２に送信される。また、規制モジュールは、規制履歴のジャーナルを保持する。ジャーナルは、テーブルまたは他の類似したデータ構造であってもよい。ジャーナルは、スタビライザ７０４に対するバックログのパーセンテージを決定するために調べられる。
【００４６】
典型的な実施形態では、スロットル７１２は、規制モジュール７１０から通信速度を受信する。スロットル７１２は、出入データに対する、最適なパケットサイズおよびパケット通信間隔を決定するために通信速度を用いる。入力間隔は、通信プロトコルとしてＴＣＰを用いる場合、出力間隔に常に等しい。通信プロトコルとしてＵＤＰが用いられる場合には、入力間隔は、遠隔地の送信機のスロットル７１２によって決定される。
【００４７】
図８は、バンド幅オプティマイザ処理の典型的な実施形態のフローチャートである。バンド幅オプティマイザ７００は、最大現行バンド幅を決定８０２する。バンド幅オプティマイザ７００内のモニタ７０６は、現行バックログを決定８０４する。コントローラ７０８は、ステップ８０６で、現行バックログが所定の閾値より大きいかを判定する。もしそうであるならば、規制モジュール７１０は、現在のバンド幅値を平均通信速度に制限する。もしそうでなければ、スタビライザ７０４は、ステップ８１０で、バックログがゼロより大きいかを判定する。バックログがゼロより大きい場合には、バンド幅オプティマイザは、現在のバンド幅値を保持する。バックログがない場合には、スタビライザ７０４は、所定の量ずつ現在のバンド幅値を増加８１４する。そして、スロットルは、現在のバンド幅値で示される通信速度に基づいて、現在のパケットサイズと通信速度とを調整する。
【００４８】
図９は、通信待ち時間を決定するために本発明により用いられるように、待ち時間タイムライン９００の典型的な実施形態を示す図である。バンド幅オプティマイザ７００は、データが発生時点からマルチメディア表示まで伝わるとき、データを追跡するためにタイムスタンプを用いる。各データパケットが伝送経路で特定のポイント９０２を通過するとき、データパケットはタイムスタンプと関連付けられる。タイムスタンプは、データパケット自体に追加されてもよいし、あるいは、データの識別子に関連付けてもよく、データパケットより異なる場所に送信される。典型的な実施形態では、データが送信機に取り込まれたとき、各データパケットは、ポイント９０２Ａでタイムスタンプと関連付けられる。送信機は、データパケットがどちらの方向に進行しているかに応じて、クライアント１０２またはサーバ１０４のいずれかになる。また、送信機がデータパケットを受信機に送信したとき、データパケットは、ポイント９０２Ｂでタイムスタンプと関連付けられる。送信機のように、この場合の受信機は、クライアント１０２またはサーバ１０４のいずれかになる。そして、データパケットは、受信機がデータを受信し、受理証を発生したときにポイント９０２Ｃで、受信機が受理証を送信機に送信したときにポイント９０２Ｄで、送信機が受理証を受信したときにポイント９０２Ｅで、送信機がデータパケットに対する待ち時間を決定するときにポイント９０２Ｆで、タイムスタンプと関連付けられる。
【００４９】
ポイント９０２Ａと９０２Ｂの間で生じる待ち時間、およびポイント９０２Ｅと９０２Ｆの間で生じる待ち時間は、送信機に起因している。ポイント９０２Ｂと９０２Ｃの間で生じる待ち時間、およびポイント９０２Ｄと９０２Ｅとの間で生じる待ち時間は、ネットワークに起因している。最後に、ポイント９０２Ｃと９０２Ｄとの間で生じる待ち時間は受信機に起因している。ゆえに、伝送ストリームを通してデータパケットを追跡することにより、全ての伝送に対する待ち時間を決定することができる。そして、モニタ７０６は、現在のバックログを決定するために待ち時間情報を用いる。
【００５０】
図１０は、本発明により用いられるようなバンド幅表示器の典型的な実施形態を示すブロック図である。バンド幅表示器は、ユーザインターフェースに必要とされる情報を得るためにバンド幅オプティマイザと入出力を行う。ユーザインターフェースについては、以下で、図１１を参照してより詳細に説明する。典型的な実施形態では、バンド幅表示器１０００は、ソフトウェアで実装され、表示器モジュール１００２およびバンド幅メータ１００４を含んでいる。表示器モジュール１００２は、バンド幅決定モジュール７０２、モニタ７０６および規制モジュール７１０から情報を受信し、バンド幅メータ１００４へ情報を出力する。バンド幅メータ１００４は、図１１で説明するユーザインターフェースを作るために、この情報を用いる。バンド幅決定モジュール７０２は、最大上下バンド幅の値を、表示器モジュール１００２へ送信する。モニタ７０６は、上下バックログ情報を表示器モジュール１００２へ送信する。バックログ情報は、実際に送信されたデータに対する通信速度およびバックログを防止するために要求される通信速度の双方を決定するために用いられる。規制モジュール７１０は、出力規制速度を表示器モジュール１００２へ送信する。送信機は、入力規制速度を表示器モジュール１００２へ提供する。いずれの速度も規制された場合、より小さい速度が、バンド幅メータ・ユーザインターフェースに対するスケールとして用いられる。速度が規制されなかった場合には、バンド幅決定モジュールから受信した最大バンド幅がユーザインターフェースに対するスケールとして用いられることになる。表示器モジュール１００２は、入出力値をバンド幅メータ１００４に提供するために速度情報を用いる。これらの値には、最大通信速度、現在の通信速度、およびバックログなしでデータフローを維持するために要求される速度が含まれる。
【００５１】
図１１は、バンド幅メータに対するユーザインターフェースの典型的な実施形態を示す図である。バンド幅メータ・ウインドウ１１００は、入力バンド幅スケール１１０２および出力バンド幅スケール１１０４を含んでいる。各スケール１１０２、１１０４は、水平ヒストグラムメータ１１０８およびパーセンテージ値１１０６を含んでいる。パーセンテージ値１１０６は、水平ヒストグラムメータ１１０８上にグラフィカルに表示される。各スケールは、マルチメディアデータに対する最大通信速度を表示し、３つの部分を含んでいる。第１の部分１１１０は、現在のデータ通信速度を示し、第２の部分１１１２は、利用可能なバンド幅量を示し、第３の部分１１１４は、バックログなしで、望ましいデータフローを保持するために要求される速度の増加を示す。
【００５２】
図１１ａは、上下通信速度が最大に近く、バックログがないことを示しているバンド幅メータを示す図である。図１１ｂは、バックログなしで上下通信速度が最大に近く、入力通信速度が所望するより遅く、わずかなバックログが生じていることを示しているバンド幅メータを示す図である。図１１ｃは、入力通信速度が所望するよりちょうどわずかに小さく、出力通信速度が所望するより非常に小さいことを示しているバンド幅メータを示す図である。この低い通信速度は、ヒストグラムメータ１１０８の第３の部分１１１４によって示されるように、大きなバックログを生じる。図１１ｄは、上下通信速度が利用可能な最大通信速度に比べて小さく、バックログがないことを示しているバンド幅メータを示す図である。
【００５３】
マイクロフォン・キュー
図２に示されるように、1度にたった１つのクライアント１０２だけがオーディオ２１６を送信する。図２において、クライアント１０２Ａは、クライアント１０２Ｂおよび１０２Ｎによって受信されたオーディオ２１６Ａを送信している。クライアントがオーディオを送信しているとき、クライアントは、マイクロフォンを占有する。マイクロフォン・キューは、マイクロフォンの仲裁を容易にするために、ルームサーバ１０６によって実装されたデータ構造である。キューの先頭のクライアント１０２は、マイクロフォンを占有し、ルーム内の他のクライアントによって聞かれることになるクライアントである。各クライアント１０２は、２つのリクエスト：話すリクエストおよび中断するリクエスト、を行うオプションを有する。これらリクエストは、上記図５を参照して説明したように、リクエスト・プロセッサ５００によって取り扱われる。クライアントが話すためにリクエストを行うと、クライアントは、マイクロフォン・キューの最後に置かれる。マイクロフォンを占有するクライアントがマイクロフォンを手放すと、クライアントは、キュー内の次のクライアントにマイクロフォンを占有させるのを許可するために、マイクロフォン・キューから取り除かれる。クライアント１０２が中断するためにリクエストを行うと、クライアントは、マイクロフォン・キューの先頭に置かれる。ゆえに、該クライアントは、マイクロフォンを占有し、マイクロフォンの以前の占有者を含む他のクライアントは、上記クライアントの後ろ側のキュー内のそれらの順序を保持する。
【００５４】
マイクロフォン・キューに対するユーザインターフェースの典型的な実施形態は、２つのアイコンを含んでいる。１つのアイコンは、マイクロフォンの占有１２０４を表し、マイクロフォンを占有しているクライアントの名前に隣接して表示される。第２のアイコンは、マイクロフォン・キューへの配置１２０６を表し、話すことを要求したクライアント１２０８の名前に隣接して表示される。マイクロフォン・キュー内の順序は、ユーザインターフェース内のクライアント・リストの順序によって表される。ゆえに、マイクロフォンを占有しているクライアントの名前は、リストの最上位にあることになり、その次に表示される第１のアイコンを有することになる。マイクロフォンの予定の次のクライアントの名前は、次のリストに載っているものであり、その次に表示される第２のアイコンを有することになる。
【００５５】
インスタント・メッセンジャ統合
一実施形態において、図１に示されるビデオ会議システムは、ルータ１１２に接続された、１つ以上のインスタント・メッセンジャ・サーバを含んでいる。インスタント・メッセンジャ・サーバは、インスタント・ミーティング機能を実装する。この機能は、図１３に示すように、現在利用可能なインスタント・メッセンジャ・プログラムと同様なユーザインターフェースを用いる。この実施形態では、各クライアントは、コンタクトリスト１３００を作ることができる。コンタクトリスト１３００は、クライアント１０２に固有であり、クライアントの画面名称１３０８によって識別される。コンタクトリスト１３００を作る際に、クライアント１０２は、如何なる数の他のクライアント１０２の画面名称を追加してもよい。これらの画面名称は、リスト１３０２に表示される。各名称の隣には、各クライアント１０２がインスタント・ミーティング・サービスにサインインしているか否かを示すアイコン１３０４がある。この実施形態において、クライアント１０２は、ミーティングへの参加のために１つ以上のクライアント１０２を選択することによって、間接的にルームの開設を要求する。参加に招待されたクライアントを選択するために、要請しているクライアントは、画面名称リスト１３０２で、招待されたクライアントのユーザ名をハイライト表示してもよい。要請しているクライアントは、新たなルームを設置し、全ての招待されたクライアントへのアクセスを許可するために、インスタント・メッセンジャ・サーバに指示を出すビデオ呼出ボタン１３０６を選択する。それから、要請しているクライアントは、何れかのポイントでビデオ呼出を始めるために選択してもよく、要請しているクライアントは、新たなルームに入室し、サーバは、招待したクライアントに招待状を送信する。招待されたクライアントも、招待状を受理すると、新たなルームに入室する。
【００５６】
ルーム内では、クライアント１０２は、ビデオ、オーディオおよびテキストを交換してもよい。時には、この情報の交換は、ミーティングに参加しているクライアント１０２の間で衝突を引き起こす可能性がある。これらのユーザは、衝突を解決することを希望して、ビデオ会議を運営する会社に苦情を届けてもよい。衝突を解決するために、会社は、広範囲な研究を実施することを要求されるかも知れず、衝突という結果になった出来事の後に続くクライアントの発言だけに頼らなければならなくなるかも知れない。証拠ジャーナル機能は、これが起こるのを防止する。クライアント１０２が他のクライアント１０２について不満を言いたい場合、不満を言っているクライアントは、証拠ジャーナルを起動させることができる。一旦起動したならば、証拠ジャーナルは、ごく最近のオーディオ、ビデオおよびテキストを記録する。例えば、ジャーナルは、５分のテキスト、５秒のオーディオ、および１０秒のビデオを取り込む。時間間隔は、予め決められており、会社の必要性に基づいて変更してもよい。
【００５７】
本発明の典型的な実施形態および様々な変形例を十分に説明したので、当業者は、ここに与えられた教えに基づき、本発明から逸脱しない数多くの変形例および同等物が存在することを理解されたであろう。すなわち、本発明は、前述の説明によって限定されることなく、添付の特許請求の範囲により制限されるものである。
【図面の簡単な説明】
【００５８】
【図１】本発明の典型的な実施形態を含むネットワーク図である。
【図２】本発明の典型的な実施形態によるマルチメディアのストリーミング図である。
【図３】本発明の典型的な実施形態によるルームサーバのブロック図である。
【図４】本発明の典型的な実施形態によるクライアントのブロック図である。
【図５】本発明の典型的な実施形態によるスレッディング・モデルの図である。
【図６】本発明の典型的な実施形態による動的データ伝送のフローチャートである。
【図７】バンド幅オプティマイザの典型的な実施形態のブロック図である。
【図８】バンド幅オプティマイザ処理の典型的な実施形態のフローチャートである。
【図９】伝送待ち時間を決定するために本発明によって用いられる、待ち時間タイムラインの典型的な実施形態を示す概念図である。
【図１０】本発明によって用いられる、バンド幅インジケータの典型的な実施形態を表すブロック図である。
【図１１】バンド幅メータのためのユーザインターフェースの典型的な実施形態を示す図である。
【図１２】マイクロフォン・キューを含むユーザインターフェースの典型的な実施形態の表示画面を示す模式図である。
【図１３】インスタント・ミーティング機能で用いられる、コンタクトリストの典型的な実施形態の表示画面を示す模式図である。
【符号の説明】
【００５９】
１００ ネットワーク
１０２ クライアント
１０２Ａ，１０２Ｂ，１０２Ｎ クライアント
１０４ サーバ
１０６ エントリサーバ
１０８ ロビーサーバ
１１０ ルームサーバ
１１２ ルータ
２０２，２１０ 受信機
２０４，２１２ 送信機
２１４ ビデオデータ
２１４Ａ，２１４Ｂ，２１４Ｎ ビデオストリーム
２１６ オーディオデータ
２１６Ａ オーディオストリーム
３０６ シーケンサ
３０８ オーディオ再シーケンサ
３１０ ビデオ再シーケンサ
３１２ マルチメディア・オーディオ・キュー
３１４ ビデオ・マルチプレクサ
３１６ パケット・エンコーダ
４０２ ビデオ・デマルチプレクサ
４０４ ディスプレイ
４０６ スピーカ
４０８ カメラ
４１０ マイクロフォン
５００ リクエスト・プロセッサ
５０２ 入力イベント・スレッド・プール
５０４ メイン・スレッド・プール
５０６ 出力イベント・スレッド・プール
５０８ リクエスト・キュー
７００ バンド幅オプティマイザー
７０２ バンド幅決定モジュール
７０２ 接続アナライザ
７０４ スタビライザ
７０６ モニタ
７０８ コントローラ
７１０ 規制モジュール
７１２ スロットル
【０００１】
関連出願とのクロスリファレンス
この出願は、スペンサーらによる、「可変バンド幅を有するグループ・ビデオ会議システムおよび方法（System and Method for Group Video Teleconferencing with Variable Bandwidth）」、２００１年８月２４日に出願された米国特許出願番号０９／９３８，７２１号の一部継続出願である。出展明示により内容の全文をここに取り込む。
【０００２】
技術分野
本発明は、ビデオ会議に関し、特に、ビデオ会議中にバンド幅の有用性に基づいて通信速度を変化させることに関する。
【０００３】
背景技術
現在のビデオ会議技術では、比較的に、長い待ち時間、低い効率および劣ったスケーラビリティが問題となっている。この理由の１つは、現在の技術が、通信速度およびパケットサイズに対して、「最小の共通バンド幅」を用いることにある。したがって、複数のクライアントが同時に会議を行う場合、ビデオデータの伝送は、最小のバンド幅で可能なのと同じくらいだけ高速である。その結果、いくつかのクライアントが比較的低速のダイヤルアップ接続を用いる一方、他がＴ１，ＤＳＬまたは類似したブロードバンド接続を用いる会議では、ブロードバンド接続を用いるそれらのクライアントは、それらの能力を利用することで、ダイヤルアップ接続の速度でのみデータを受信することになる。
【０００４】
現在のビデオ会議技術は、ビデオフレーム伝送蓄積転送方法を用いる。ビデオフレームが開設される度に、それらは、開設しているコンピュータ上のそれら全てに格納される。これは、サーバ上に大容量の利用可能なメモリを必要とし、サーバの作業負荷を増加させることになる。その結果、従来のシステムは、劣ったスケーラビリティを有し、待ち時間を増加させた。
【０００５】
現在のビデオ会議技術は、ファイアウォールまたはプロキシサーバを通過させようとした場合、しばしば困難に遭遇する。ファイアウォールは、ビデオ会議技術で一般的であるプロトコル、ＵＤＰ（User Datagram Protocol）を用いて送信されたデータと互換性を持たない。プロキシサーバは、リクエストをフィルタリングするために用いられ、この結果、ビデオ会議トラヒックを多くの場合含むトラヒックの特定のタイプを除去することになる。
【０００６】
発明が解決しようとする課題
前述した限界を考慮すれば、ビデオ会議システムにとって、全てのクライアントのバンド幅能力のより良い利点を得て、待ち時間を短縮し、スケーラビリティを向上させ、ファイアウォールとプロキシサーバとの互換性を持つ必要性がある。
【０００７】
課題を解決するための手段
本発明は、層サーバ・アーキテクチャを含むデータを動的に伝送するためにシステムを提供することにより、待ち時間を短縮し、かつマルチメディア・グループ会議の効率を向上させる。マルチメディア・グループ会議のためにシステムを用いているクライアントは、ネットワークに接続されており、該ネットワークを介して、オーディオおよびビデオデータを送受信する。クライアントがシステムにアクセスすると、サーバの１つが、クライアントへの接続で利用可能な最大バンド幅を決定する。そして、サーバは、伝送されているデータの適当な通信速度およびパケットサイズを確立する。マルチメディアデータを伝送している間、バンド幅オプティマイザは、最も効率的な通信速度を決定するために、パケット損失の実際の上下通信時間および通信速度をモニタリングする一方、通信速度を調整する。バンド幅オプティマイザは、バックログが検出されると、データに対するパケットサイズおよび伝送間隔を減少させることにより、データ通信速度を低下させる。バンド幅オプティマイザは、バックログが検出されない場合、バックログが再び検出されるまで、データ通信速度を徐々に増加させる。
【０００８】
発明を実施するための最良の形態
図１は、本発明を含むシステムの典型的な実施形態の図である。システムは、ネットワーク１００、ルータ１１２、１つ以上のクライアント１０２、および１つ以上のサーバ１０４を含んでいる。典型的な実施形態では、２つ以上のクライアントは、ネットワーク１００を介して、互いにマルチメディアデータを送受信する。サーバ１０４は、クライアントからクライアントへのデータの正確な伝送のために必要とされる如何なるマルチメディア機能をも容易にする。ルータ１１２には、サーバ１０４への、あるいはサーバ１０４からのデータフローを容易にする、一般的な任意のルーティング機器が用いられる。典型的な実施形態では、層サーバ・アーキテクチャは、エントリサーバ１０６、ロビーサーバ１０８およびルームサーバ１１０（ひとまとめにしてサーバ１０４）のいくつか、または全てを含んでいる。ロビーおよびルームのメタファは、ロード・バランシングと場所重視の会議環境とを容易にする。個人との会議を選択する代わりに、各クライアント１０２は、ロビー、および該ロビー内のルームに入室することを選択する。オンライン・チャットルームと同様に、各クライアント１０２は、ルーム内の１つ以上の他のクライアントにオーディオ、ビデオおよびデータを送信することができる。
【０００９】
サーバ１０４は、ネットワーク１００を介してクライアント１０２に接続されている。典型的な実施形態では、ネットワーク１００は、インターネット、専用ネットワークまたはイントラネットであってもよいが、他のネットワークを用いることもでき、ネットワークの特定の形態に限定されない。あるいは、いくつかの実施形態では、サーバ１０４およびクライアント１０２は、ネットワーク１００を通過することなく、間接または直接、通信してもよい。クライアント１０２は、オーディオおよびビデオ信号を容易に送受信するために、多くのオーディオおよびビデオ機器構成を備えていてもよい。この機器は、ビデオ表示ユニット、スピーカ、マイクロフォン、カメラ、および、以下で説明する会議機能を実装するための適切なソフトウェアを実行する処理ユニットを含んでいてもよい。クライアント１０２の典型的な構成については、以下で、図４を参照してより詳細に説明する。
【００１０】
マルチメディアデータを送受信するためには、クライアント１０２は、サーバ１０４と情報を交換する。典型的な実施形態は、１つまたは２つのエントリサーバ１０６を含んでいるが、システムは、エントリサーバ１０６の数に制限されない。エントリサーバ１０６は、ログイン処理中にパスワード暗号化を提供することを含む、ログイン・クライアント１０２の管理機能を担う。エントリサーバ１０６は、利用可能なロビーのディレクトリを維持し、各クライアント１０２がロビーを選択することを可能とし、そのクライアント１０２がそのロビーに入るための許可を有することを確実にすることを担う。エントリサーバ１０６に含まれる唯一の状態情報は、利用可能なロビーのディレクトリであるので、エントリサーバ１０６は、容易に集められる。また、エントリサーバ１０６は、バンド幅、待ち時間およびプロトコル有用性のクライアントイニシエート分析で支援する。クライアントがログインすると、クライアント１０２およびエントリサーバは、クライアント１０２へ、またはクライアント１０２からの接続のバンド幅を確立し、ＵＤＰが伝送プロトコルとして機能するかどうかを判定するテスト伝送を他の要求された情報とともに交換する。ＵＤＰの使用がファイアウォールまたはプロキシサーバで制限されないならば、セッション間の以後の伝送は、ＵＤＰを用いて送信される。しかしながら、ＵＤＰの使用が制限されるならば、以後の伝送は、ＴＣＰ（transmission control protocol）を用いて送信される。
【００１１】
ロビーサーバ１０８は、エントリサーバ１０６に識別情報を送信する。この情報は、ロビーにアクセスしていないクライアントのリストを含んでいる。また、ロビーサーバ１０８は、ロード・バランシング機能も実行する。クライアント１０２が新しいルームの開設を要求すると、ロビーサーバ１０８は、最小の負荷を有するルームサーバ１１０にルームを開設する。典型的な実施形態では、ロビーにログインした如何なるクライアント１０２でも、新しいルームの開設を要求することができる。あるいは、新しいルームの開設は、予め設定されたクライアント１０２、または特定の基準を満たすクライアントに限定されてもよい。いずれかのクライアント１０２によるルームの使用は、開設しているクライアント１０２に課金されるので、例えば、新しいルームの開設をリクエストすることは、支払い請求情報を与えられているクライアント１０２に制限されてもよい。他の例として、クライアント１０２は、物議をかもしたり、公序良俗に反したり、それ以外でも何らかの制限事項を含むルームの開設を、規制してもよい。
【００１２】
典型的な実施形態では、新しいルームの開設を要求しているクライアント１０２、またはモデレータには、会議に関して特別な制御特権が与えられる。例えば、モデレータは、特定のクライアント１０２が、会議に参加し続けることを防止したり、クライアント１０２が情報の特定のタイプにアクセスすることを制御したり、ルームを閉じたりする。また、モデレータは、他のクライアント１０２へ特権を委任してもよい。典型的な実施形態では、ロビーサーバ１０８は、複数のルームサーバ１１０、例えば７つ以上のルームサーバ１１０を支援してもよい。クライアント１０２は、ロビーから、新しいルームの開設を要求する、あるいは既存のルームに入室する、というオプションを有する。
【００１３】
典型的な実施形態では、ルームサーバ１１０は、システムのマルチメディア機能を容易にする。ルームサーバ１１０は、以下で、図３を参照してより詳細に説明される。図１は、考えられるアーキテクチャの一例のみを示し、本発明は、図１に示す典型的なアーキテクチャに限定されない。例えば、エントリサーバ１０６、ロビーサーバ１０８またはルームサーバ１１０の数が変化するように、サーバ１０４の全数は、変化してもよい。また、システムに含まれるサーバには、他のタイプがあってもよい。代替の実施形態では、システムは、ルータ１１２なしで動作してもよい。また、クライアント１０２およびサーバ１０４は、中間のネットワーク接続なしで、直接接続されてもよい。
【００１４】
図２は、本発明の典型的な実施形態に従うマルチメディア・ストリーミング図である。クライアント１０２Ａ、１０２Ｂ、１０２Ｎ（ひとまとめにしてクライアント１０２）は、ルームサーバ１１０を介して、互いに、オーディオおよびビデオデータを交換する。各クライアント１０２は、送信機２０４および受信機２０２を含んでいてもよい。ルームサーバ１１０は、ルームサーバ１１０を通して送信している各クライアント１０２に対して、固有の受信機２１０および送信機２１２を設置する。クライアント１０２は、図２に示されていないネットワーク１００を介してルームサーバ１１０に接続されている。クライアント１０２およびルームサーバ１１０については、以下に、図３及び図４を参照して、より詳細に説明する。
【００１５】
オーディオデータ２１６およびビデオデータ２１４は、開設しているクライアント１０２の送信機２０４から、サーバ１１０のクライアント１０２に対する受信機２１０に送信される。典型的な実施形態では、各クライアント１０２は、見るため、聞くためにビデオおよびオーディオを選択する。これらの選択は、加入者リストおよび申込みリストの使用を通して容易に行われる。加入者リストは、ルームで他のクライアントにデータを再配布するために受信機２０２、２１０と連携して用いられる。受信機２０２、２１０の各々は、オーディオデータに対して１つの加入者リストに、ビデオデータに対して１つの加入者リストにグループ化されている。加入者リストは、与えられたオーディオ・ストリームまたはビデオストリームを申し込んだ、それらのクライアントを識別する。申込みリストは、データを多重送信することができるので、ビデオ・ストリームを特定のビデオチャネルに関連ビデオストリーム信機２０４、２１２と連携して用いられる。送信機２０４、２１２の各々は、オーディオに対して１つの申込みリストに、ビデオに対して１つの申込みリストにグループ化されている。申込みリストは、オーディオおよびビデオが送信される、加入者リスト上のクライアントを識別する。ゆえに、加入者リストのクライアントは、オーディオおよびビデオを受信し、申込みリストのクライアントは、オーディオおよびビデオを送信することになる。典型的な実施形態では、各クライアント１０２が一度に１つのオーディオ・ストリームだけを聞くことになるので、オーディオ申込みリストは、１つのエントリだけを含むことになる。代替の実施形態では、システムは、マルチ・チャネル・オーディオをサポートしてもよく、この場合、オーディオ・ストリームは、ビデオストリームと同様の方法で多重送信される。ビデオ申込みリストは、同時に表示される各ビデオ・ウインドウに対して１つ、最大８つのエントリを含んでもよい。
【００１６】
加入者リストと申込みリストとにおける情報に基づいて、ルームサーバ１１０の送信機２１０は、ビデオおよびオーディオ・ストリーム２１４、２１６を、ルームサーバ１１０内の受信するクライアント１０２の送信機２１２へ送信する。それから、送信機２１２は、ビデオおよびオーディオを、それぞれのクライアント１０２に送信する。マルチメディアデータの送信については、以下で、図３および図４を参照してより詳細に説明する。
【００１７】
図２に示される実施例において、クライアント１０２Ａは、ビデオデータ２１４Ａおよびオーディオデータ２１６Ａを送信している。図示の他の２つのクライアント、すなわちクライアント１０２Ｂ、１０２Ｎは、各々、ビデオデータ２１４Ｂ、２１４Ｎを送信している。クライアント１０２Ａは、それ自身のビデオ２１４Ａと、クライアント１０２Ｂからのビデオ２１４Ｂを受信している。この結果、送信機２１２Ａに対するビデオ申込みリストは、クライアント１０２Ａ、１０２Ｂを含み、受信機２０２Ａ、２０２Ｂの双方に対する加入者リストは、クライアント１０２Ａを含むことになる。図示する実施形態において、クライアント１０２Ａのビデオ２１４Ａは、ネットワーク１００を介して、ルームサーバ１１０に送信されて戻ることに注目する。代わりの実施形態では、クライアント１０２Ａは、ネットワークを介して送信されて戻るビデオ２１４Ａなしの直接フィードバックとして、ローカル・ビデオ・イメージを見ることになる。この直接フィードバックは、待ち時間を短縮し、スケーラビリティを向上させる。クライアント１０２Ｂは、クライアント１０２Ａからビデオ２１４Ａおよびオーディオ２１６Ａを受信し、クライアント１０２Ｎからビデオ２１４Ｎを受信している。クライアント１０２Ｎは、クライアント１０２Ａからビデオ２１４Ａおよびオーディオ２１６Ａを受信し、クライアント１０２Ｂからビデオ２１４Ｂを受信している。クライアント１０２Ｂ、１０２Ｎが最初にこのオーディオおよびビデオデータの見聞きを要求する時に、関連する申込みおよび加入者リストがアップデートされる。
【００１８】
クライアント１０２Ａの送信機２０４Ａは、クライアント１０２Ａで開設されたオーディオ・ストリーム２１６Ａとビデオストリーム２１４Ａを、ルームサーバ１１０の受信機２１０Ａに送信する。受信機２１０Ａは、クライアント１０２Ｂ、１０２Ｎへの伝送のために、オーディオ・ストリーム２１６Ａを、送信機２１２Ｂおよび送信機２１２Ｎの各々に送信する。受信機２１０Ａは、クライアント１０２Ａ、１０２Ｂ、１０２Ｎへの伝送のために、ビデオストリーム２１４Ａを、送信機２１２Ａ、２１２Ｂおよび２１２Ｎの各々に送信する。クライアント１０２Ｂの送信機２０４Ｂは、クライアント１０２Ｂで開設されたビデオストリーム２１４Ｂを、ルームサーバ１１０の受信機２１０Ｂに送信する。受信機２１０Ｂは、クライアント１０２Ａおよび１０２Ｎへの伝送のために、ビデオストリーム２１４Ｂを、送信機２１２Ａおよび２１２Ｎの各々に送信する。送信機２０４Ｎは、クライアント１０２Ｎで開設されたビデオストリーム２１４Ｎを、ルームサーバ１１０の受信機２１０Ｎへ送信する。受信機２１０Ｎは、クライアント１０２Ｂへの伝送のために、ビデオストリーム２１４Ｎを送信機２１２Ｂに送信する。
【００１９】
送信機２１２Ａは、ビデオ２１４Ａおよび２１４Ｂを、クライアント１０２Ａの受信機２０２Ａに送信する。送信機２１２Ｂは、ビデオ２１４Ａ、２１４Ｎおよびオーディオ２１６Ａを、クライアント１０２Ｂの受信機２１６Ａに送信する。送信機２１２Ｎは、ビデオ２１４Ａ、２１４Ｂおよびオーディオ２１６Ａを、クライアント１０２Ｎの受信機２０２Ｎへ送信する。送信機２１２Ａ、２１２Ｂ、２１２Ｎからのこれら送信は、これら送信に対するそれぞれの申込みリストによって管理される。
【００２０】
ビデオおよびオーディオ送信に加えて、クライアントは、スライドショー・プレゼンテーション、テキスト文書、写真画像、音楽ファイルなどのようなデータを送信してもよい。図２に示すビデオおよびオーディオ・ストリームにように、データストリームは、いずれかのクライアント１０２から１つ以上の受信クライアント１０２に送信されてもよい。図２には、３つのクライアント１０２が示されているが、各々に、ルームサーバ１１０の固有の送信機２１２および受信機２１０を有する、如何なる数のクライアント１０２があってもよい。
【００２１】
図３は、本発明の典型的な実施形態によるルームサーバのブロック図である。ルームサーバ１１０は、一対の受信機２１０と送信機２１２を、ゼロ、または１つ以上含んでいてもよい。典型的な実施形態において、受信機２１０および送信機２１２は、ソフトウェアで実装され、ルームサーバ１１０は、マルチメディアデータを送受信している各クライアント１０２に対して、固有の受信機２１０と送信機２１２とを開設する。受信機２１０は、シーケンサ３０６を含んでいてもよい。送信機２１２は、オーディオ再シーケンサ３０８、ビデオ再シーケンサ３１０、マルチメディア・オーディオ・キュー３１２、ビデオ・マルチプレクサ３１４およびパケット・エンコーダ３１６のいくつか、または全てを含んでもいてもよい。
【００２２】
各受信機２１０は、クライアント１０２からマルチメディアデータを受信するためにネットワーク１００に接続されている。また、受信機２１０は、１つ以上の送信機２１２に接続されている。受信機２１０は、クライアント１０２から受信したデータを送信機２１２に転送する。また、送信機２１２は、ネットワーク１００に接続されており、受信機２１０により送信機２１２に転送されたデータは、ネットワーク１００を介して受信クライアント１０２に送信される。
【００２３】
ルームサーバ１１０は、送信しているクライアント１０２からマルチメディア・ブロックの形態でデータを受信する。典型的な実施形態において、マルチメディア・ブロックは、シーケンス番号、オーディオフレーム、ビデオフラグメント、ビデオチャネル、レシート、ビデオパラメータ、オーディオパラメータ、ビデオ・エンド・フラグおよびオーディオ・エンド・フラグのいくつか、あるいは全てを含むデータパケットのタイプである。シーケンス番号は、マルチメディア・ブロックがオーディオまたはビデオデータを含んでいる場合、マルチメディア・ブロックを再オーダするために用いられる。マルチメディア・ブロックがオーディオデータを含んでいる場合には、このデータは、オーディオフレームの形態である。マルチメディア・ブロックがビデオデータを含んでいる場合には、このデータは、ビデオフラグメントの形態である。ビデオフラグメントは、ビデオフレームのスタート、ミドル、エンドを表すデータ構造である。また、ビデオフラグメントは、全ビデオフレームまたは前の伝送中にビデオフラグメントが失われたことを示す特別な値であってもよい。ビデオチャネルは、ビデオデータがある場合、ビデオフラグメントに割り当てられたチャネルである。受理証は、他のパーティにより受信されたマルチメディア・ブロックのシーケンス番号の最新のものである。受理証は、以下で、図６を参照して説明されるように、バンド幅の配分を決定する際に用いられる。ビデオおよびオーディオパラメータは、新しいビデオまたはオーディオデータを送信し始めるとき、マルチメディア・ブロックの一部として送信される。ビデオおよびオーディオ・エンド・フラグは、オーディオまたはビデオ送信の終わりを示す。ビデオデータに対する、パラメータおよびエンド・フラグは、新しいチャネルでデータを送信し始めることか、ビデオストリームの終端でチャネルを閉じることを含む。一実施形態において、オーディオデータは、ビデオデータより高い優先順位を有してもよく、ゆえに、データを送信できない場合、オーディオデータの精度を保証する。この場合、マルチメディア・ブロックは、全ての利用可能なオーディオデータを含む。典型的な実施形態では、シーケンサ３０６は、マルチメディア・ブロックを受信し、それらをオーディオ・メディア・ブロックおよびビデオ・メディア・ブロックに分離する。また、シーケンサ３０６は、マルチメディア・ブロックの適切な順序を保証するために、ネットワーク１００を介して受信したマルチメディア・ブロックに対するシーケンス番号を用いる。シーケンサ３０６は、次の予想されるマルチメディア・ブロックの受領まで、シーケンスから外れたマルチメディア・ブロックを一時的に格納する。見失ったマルチメディア・ブロックが、格納領域が使い果たされる前に受信されなくなると、シーケンサ３０６は、マルチメディア・ブロックが失われたと見なす。
【００２４】
オーディオ・メディア・ブロックは、シーケンサ３０６から送信機２１２のオーディオ再シーケンサ３０８にルームサーバ１１０によって転送される。シーケンサ３０６のように、オーディオ再シーケンサ３０８は、オーディオ・メディア・ブロックからのオーディオデータを、適切な順序で、すなわちそれらが生成された順序に配置する。典型的な実施形態では、オーディオ再シーケンサ３０８は、それがパケット損失を取り扱わないという点でシーケンサ３０６と異なる。その結果、シーケンスから外れて受信されたパケットに対してより一時的な格納を実現する。オーディオ再シーケンサ３０８からは、順番に配列されたオーディオ・メディア・ブロックが、マルチメディア・オーディオ・キュー３１２に送信される。マルチメディア・オーディオ・キュー３１２は、付加的なマルチメディアデータを受け入れるために受信クライアント１０２に利用可能なバンド幅があるまで、オーディオ・メディア・ブロックをバッファリングする。オーディオ・メディア・ブロックは、マルチメディア・ブロックを形成するために、ビデオ・メディア・ブロックに結合され、ネットワーク１００または如何なる確立された伝送接続を介して、受信クライアント１０２に送信される。
【００２５】
ルームサーバ１１０は、ビデオ・メディア・ブロックをビデオ再シーケンサ３１０に転送する。典型的な実施形態では、８つのビデオチャネルの各々に対して１つのビデオ再シーケンサがある。各チャンネルは、クライアント１０２のディスプレイ４０４上の固有の表示ウインドウに表示されるビデオデータを取り扱う。ゆえに、８つのビデオチャネルを有する典型的な実施形態では、８つ以上の同時に表示されたビデオストリームがあることになる。ビデオ・メディア・ブロックは、ビデオ・マルチプレクサ３１４に転送される。
【００２６】
ビデオ・マルチプレクサ３１４は、各ビデオチャネルに対してビデオ・キューを含んでいる。ビデオ・キューは、ＦＩＦＯ（first in first out）であり、ビデオフラグメントを格納する。ビデオフラグメントは、全ビデオフレーム、ビデオフレームのスタート、ビデオフレームのミドル、ビデオフレームのエンド、または失われたビデオフラグメントを表す特別な値であってもよい。典型的な実施形態では、ビデオフラグメントの特定のシーケンスだけがビデオ・キューに入力されてもよい。例えば、「スタート」の後に「ミドル」が続き、「ミドル」の後に「エンド」が続くことになるが、「スタート」は、他の「スタート」の後に続くことはない。ビデオ・キュー内のフラグメントを配列することは、フラグメントからビデオフレームの再構成を容易にする。全ビデオフレームまたはビデオフレームの特定のバイト数は、ビデオ・キューから出力されてもよい。例えば、ビデオ・キューが２００バイトの「スタート」フラグメントを格納していた場合、キューは、要求があれば、キュー内の次のフラグメントとして１００バイトの「ミドル」フラグメントを放置して、１００バイトの「スタート」フラグメントを出力することになる。
【００２７】
ビデオ・マルチプレクサ３１４内のビデオ・キューは、ビデオデータに対するバッファとして機能する。ビデオ・メディア・ブロックがビデオ・マルチプレクサ３１４による順序で受信されるように、それらは、ビデオ・キュー内の完全なビデオフレームに組み立てられる。一度、全ビデオフレームが組み立てられると、ビデオデータを受け入れるための受信クライアント１０２への接続に利用可能なバンド幅がない場合、ビデオ・キューは、フレームを落とすことになる。バンド幅が受信クライアント１０２への接続に利用可能になると、ビデオ・メディア・ブロックは、パケット・エンコーダ３１６に送信され、マルチメディア・ブロックを形成するためにオーディオ・メディア・ブロックに結合される。マルチメディア・ブロックは、ネットワーク１００または何らかの確立された伝送接続を介して受信クライアント１０２に送信される。
【００２８】
図４は、本発明の典型的な実施形態によるクライアント１０２のブロック図である。一実施形態において、クライアント１０２は、受信機２０２、送信機２０４、ディスプレイ４０４、スピーカ４０６、カメラ４０８およびマイクロフォン４１０を含んでいる。各クライアント１０２は、マルチメディアデータを送受信することができる。
【００２９】
送信側では、カメラ４０８は、ビデオ・イベントを生成し、マイクロフォン４１０は、オーディオ・イベントを生成する。ビデオ・イベントは、ビデオ・マルチプレクサ３１４に送信される。ルームサーバ１１０のビデオ・マルチプレクサ３１４のように、クライアントのビデオ・マルチプレクサ３１４は、多重ビデオ信号を取り扱うために多重チャネルを有する。ゆえに、クライアント１０２は、複数のビデオカメラを含んでいてもよい。また、ルームサーバ１１０のビデオ・マルチプレクサ３１４のように、クライアント１０２のビデオ・マルチプレクサ３１４は、バンド幅要求を減少するために、ビデオフレームを配列するため、およびドロップするために用いられる、各チャネルに対してビデオ・キューを含んでいる。
【００３０】
オーディオ・イベントは、マイクロフォン４１０からマルチメディア・オーディオ・キュー３１２に送信される。バンド幅がデータを送信するために利用可能になると、ビデオ・メディア・ブロックとオーディオ・メディア・ブロックは、パケット・エンコーダ３１６に送信され、マルチメディア・ブロックを形成するために結合される。マルチメディア・ブロックは、ネットワーク１００または何らかの確立された伝送接続を介して、ルームサーバ１１０へ送信される。
【００３１】
受信側では、受信機２０２は、ネットワーク１００を介して、ルームサーバ１１０からマルチメディア・ブロックを受信する。受信機２０２内のシーケンサ３０６は、適切な順序にマルチメディア・ブロックを順序付けて、それらをビデオ・メディア・ブロックとオーディオ・メディア・ブロックとに分離する。オーディオ・メディア・ブロックは、スピーカ４０６に送信され、サウンドに変換される。該サウンドは、特定の実施に従ってアナログまたはデジタルいずれの形式で生成されてもよい。ビデオ・メディア・ブロックは、ビデオ・デマルチプレクサ４０２へ送信され、別個のビデオフレームに分解される。ビデオ・マルチプレクサ３１４と同様に、ビデオ・デマルチプレクサ４０２は、ビデオフレームを組み立てるため、およびビデオフレームをドロップするために用いられる、ビデオ・キューを含む。ビデオフレームは、ビデオディスプレイ４０４へ送信され、従来の方法で表示される。
【００３２】
図５は、本発明の典型的な実施形態によるスレッディング・モデルのブロック図である。マルチメディア伝送に加えて、ルームサーバ１１０の受信機２１０および送信機２１２は、それらの各々のクライアント１０２へ要求を送信するとともに、クライアント１０２からリクエストを受信する。これらの事象には、オーディオまたはビデオを特定のクライアントに送信するというリクエスト、特定のクライアントのビデオを見るというリクエスト、見ているビデオからクライアントを遮断するというリクエストなどを含む。モデレータの地位を割り当てられたクライアントは、モデレータに制限されるリクエストを行うことになる。これらリクエストの例には、クライアントを退場させるというリクエスト、特定のデータタイプにアクセスするべく特定のクライアントに特権を与えるというリクエスト、ルームを閉じるというリクエスト、または他のクライアントにモデレータの任務を与えるというリクエストが含まれる。
【００３３】
図５に示すような典型的な実施形態では、リクエスト・プロセッサ５００は、入力イベント・スレッド・プール５０２、メイン・スレッド・プール５０４、出力イベント・スレッド・プール５０６およびリクエスト・キュー５０８を含んでいる。入力イベント・スレッド・プール５０２は、受信機２１０およびリクエスト・キュー５０８に接続されている。リクエスト・キュー５０８は、入力イベント・スレッド・プール５０２、メイン・スレッド・プール５０４および出力イベント・スレッド・プールに接続されている。メイン・スレッド・プール５０４は、リクエスト・キュー５０８に接続されている。出力イベント・スレッド・プール５０６は、リクエスト・キュー５０８および送信機２１２に接続されている。リクエスト・プロセッサ５００は、メモリに格納され、コンピュータ・プロセッサにより実行されるソフトウェアコードであってもよいが、本発明は、この実施形態に制限されない。典型的な実施形態では、メモリおよびコンピュータ・プロセッサは、ルームサーバ１１０の構成部品である。ソフトウェア命令は、フロッピーディスク（登録商標）、ＣＤ-ＲＯＭ、または何らかの他の適当な記憶媒体のようなコンピュータで可読な媒体に格納されていてもよい。リクエスト・プロセッサ５００内の構成部品の接続は、ソフトウェアコードにより定義される論理的な接続であってもよい。
【００３４】
受信機２１０は、入力リクエストをクライアント１０２からリクエスト・プロセッサ５００へ送信する。入力リクエストは、処理のために入力イベント・スレッド・プール５０２へ送信される。入力リクエストは、即時応答と長期動作を要求するリクエストを含んでいる。即時応答を要求する入力リクエストは、ＴＣＰを介して送信される入力ネットワーク・トラヒックを取り扱うために作られる。長期動作である入力リクエストは、接続が伝送プロトコルとしてＵＤＰを支持する場合、ＵＤＰを介して送信される入力ネットワーク・トラヒックを取り扱うために作られる。
【００３５】
出力リクエストは、処理のために出力イベント・スレッド・プール５０６に送信される。出力リクエストは、接続が伝送プロトコルとしてＵＤＰを支持する場合、ＵＤＰを介して送信される外へ向かうデータを取り扱うために作られる。出力リクエストを処理する際に、出力イベント・スレッド・プール５０６は、出力イベントを発生する。このイベントは、外へ向かうデータをクライアント１０２へ送信するために１つ以上の送信機２１２を呼び出す。
【００３６】
内部リクエストは、ルームサーバ１１０に内蔵されているタスクを実行するために用いられる。内部リクエストは、問題をロックしているか、遮断している潜在性のために入力または出力リクエストで取り扱うのに適切でない他のタスクと同様に、ルームサーバ１１０内でのオーディオおよびビデオの再送信からなる。内部リクエストは、リクエスト・キュー５０８に格納されており、スレッドが利用可能になると、メイン・スレッド・プール５０４に発送される。
【００３７】
図６は、本発明の典型的な実施形態によるダイナミックデータ伝送のフローチャートである。ダイナミックデータ伝送の処理は、伝送の最小待ち時間およびマルチメディアデータの受信を確実にするために、クライアント１０２およびルームサーバ１１０の双方によって容易にされる。クライアント１０２がエントリサーバ１０６を通してログインすることによって会議セッションを始めると、バンド幅調整器は、上下マルチメディア伝送に対する現在のバンド幅および待ち時間を決定６０２する。クライアント１０２およびルームサーバ１１０は、各々、典型的な実施形態では、ソフトウェアで実装されるバンド幅調整器を含んでいる。バンド幅および待ち時間情報に基づいて、バンド幅調整器は、各接続に対して最適なパケットサイズおよび最適なパケット間隔を決定６０４する。ルームサーバ１１０は、ジャーナル、テーブル、または他の同様なデータ構造に、送信機２１２によって送信される次のパケットに対する、パケットサイズおよび出発時間を記録６０６する。クライアント１０２は、次のパケットを送信し、ジャーナル、テーブル、または他の同様なデータ構造に、このパケットに対するパケットサイズおよび出発時間を記録６０６する。
【００３８】
一実施形態において、送信機（ルームサーバ１１０か、クライアント１０２のいずれか）は、受信機に送信すべきデータがさらにあるかどうかを判定６０８する。送信すべきデータがこれ以上ない場合には、処理を終了する。送信すべき更なるデータがある場合には、バンド幅調整器は、入ってくるマルチメディア・ストリームから受け取った各受理証に対して、ジャーナルから記録を取り除くことによりジャーナルを更新６１０する。ルームサーバ１１０では、は、受信機２１０で受理される。クライアント１０２では、受理証は、受信機２０２で受理される。また、バンド幅調整器は、失われたパケットに対してもジャーナルから記録を取り除く。そして、バンド幅調整器は、ジャーナルに残っているエントリの各々に対応している受理証に対する、予想到着時刻を決定６１２する。予想到着時刻は、パケットの出発時刻、待ち時間、出て行くパケットサイズならびに入ってくるパケットサイズ、およびバンド幅を用いることにより決定される。
【００３９】
クライアント１０２およびルームサーバ１１０でのバンド幅調整器は、いずれかのジャーナルに記録されたパケットの期限が過ぎているか否かを判断６１４するために、予想到着時刻を用いる。期限が過ぎたパケットがあった場合には、バンド幅調整器は、送信機２０４、２１２がオーディオデータのみを送信するためのモード６１６に入る。オーディオデータは、ビデオとオーディオデータが結合したものより、送信のために低いバンド幅を要求するので、データがオーディだけに限定される場合、送信の待ち時間は減少することになる。期限が過ぎているパケットがない場合には、バンド幅調整器は、送信機２０４，２１２がオーディオおよびビデオデータの双方を送信するモード６１８に入る。ビデオおよびオーディオデータを取り扱うのに十分利用可能なバンド幅が接続にある場合、期限切れのパケットはなく、バンド幅調整器は、オーディオおよびビデオデータの双方の送信を許可することになる。これらの２つのモードの間の切り替わりの結果、より小さいバンド幅接続に対して、オーディオデータは、ビデオデータの断続的な伝送とともに連続的に送信される。オーディオモード、またはオーディオおよびビデオモードのいずれかに一度入ると、クライアント１０２またはルームサーバ１１０は、次のパケットを送信６０６し、パケットサイズおよびこのパケットに対する出発時刻を記録する。
【００４０】
バンド幅オプティマイザ
図７は、バンド幅オプティマイザ７００の典型的な実施形態のブロック図である。バンド幅オプティマイザは、最も効率的な通信速度を決定するために、パケット損失の実際の上下通信時間と速度をモニタリングする一方、通信速度を調整する。典型的な実施形態では、この効率的な通信速度は、ネットワーク待ち時間またはパケット損失のいずれかのかなりの増加なしに、データを伝送することができる最大速度として定義される。典型的な実装例では、以下に述べるバンド幅オプティマイザ７００および該バンド幅オプティマイザ７００の構成部品は、ソフトウェアで実装される。ＵＤＰが伝送のために用いられたプロトコルである場合、このソフトウェアは、クライアント１０２およびルームサーバ１０６の双方に配置されてもよい。ＴＣＰが伝送のために用いられたプロトコルである場合、クライアント１０２のみに配置される。バンド幅オプティマイザ７００は、上下のマルチメディア・トラヒックのデータ内のバックログを継続してモニタする。バンド幅オプティマイザがバックログを検出した場合には、パケットサイズおよびデータに対する伝送間隔を減少させることによって、データの通信速度を低下させる。バンド幅オプティマイザがバックログを検出しない場合には、バックログが再び検出されるまで、データの通信速度を徐々に増加させる。この処理は、後でさらに詳細に説明される。
【００４１】
バンド幅オプティマイザ７００のこの実施形態は、接続アナライザ７０２、スタビライザ７０４、モニタ７０６、コントローラ７０８、規制モジュール７１０およびスロットル７１２を含んでいる。接続アナライザ７０２は、最大上下通信速度およびネットワーク待ち時間を決定する。クライアント１０２は、通信速度を手動で確立してもよいし、接続アナライザ７０２が上下通信速度およびネットワーク待ち時間を自動的に検出するように要求してもよい。典型的な配置において、それら３つの変数は、マルチメディアデータを送受信するのに先立って一度決定される。
【００４２】
スタビライザ７０４は、上下の「現在の上限」通信速度を調整する。現在の上限通信速度は、接続アナライザ７０２により決定された最大通信速度とは異なる。現在の上限通信速度は、まず、接続アナライザ７０２によって決定された最大通信速度にセットされる。スタビライザ７０４は、所定の期間にわたってバックログされるために現れた接続の時間のパーセンテージを決定することにより現在の上限通信速度を調整する。例えば、典型的な実施形態では、スタビライザ７０４は、過去２秒にわたってバックログされるために現れた接続の時間のパーセンテージを決定してもよい。この時間のパーセンテージがゼロで、かつ現在の上限通信速度が最大通信速度より小さい場合、現在の上限は、与えられたパーセンテージずつ増加する。例えば、この増加は２パーセントであってもよい。通信速度が増加すると、もうそれ以上、増加（または減少）は、増加後の与えられた期間、許可されない。一例として、増加（または減少）は、増加の後、７５０ｍｓの間許可されない。バックログされた時間のパーセンテージが２５を越える場合、現在の上限は、バックログされるために現れた接続の時間のパーセンテージずつ減少する。上限が減少すると、もうそれ以上、減少（または増加）は、与えられた期間、たとえば２秒間、許可されない。この調整は、接続アナライザ７０２からの入力および規制モジュール７１０からの入力に基づいている。典型的な実施形態では、規制モジュール７１０は、伝送の最後の２秒で検出されたバックログのパーセンテージのスタビライザ７０４に指標を送信する。スタビライザ７０４は、接続がバックログされた時間のパーセンテージを決定するために規制ジャーナルを見る。スタビライザ７０４は調整された上限を、規制モジュール７１０に送信する。
【００４３】
典型的な実施形態では、モニタは、ミリ秒でバックログ量を決定し、これをコントローラ７０８に送信する。モニタ７０６は、データパケットが遠くにある受信機に送信される時刻、送信されたデータパケットのサイズ、サーバ待ち時間に対する値と同様に、データパケットが実際に受信される時刻、および受理証を含んだ下りパケットのサイズを含む、それら遠隔地の受信機によって送信された受理証を、入力として受信する。モニタ７０６は、データパケットが受信されるべきとき、および該データパケットに対する受理証が受信されるべきときを計算するために、データパケットが送信される時刻と、既知の待ち時間情報とを用いる。待ち時間の決定については、図９を参照して以下で更に詳細に説明する。ミリ秒でバックログ量を決定するために、モニタ７０６は、データパケットおよび該データパケットに対する受理証の双方が受信されると予想される時刻の情報を取得し続け、それらの時刻を、それらが実際に受信される時刻と比較する。この情報から、モニタ７０６は、実際の通信速度を計算することができる。モニタ７０６は、実際の通信速度と予想した通信速度との間の差分を決定する。このバックログ時刻は、コントローラ７０８に送信される。
【００４４】
典型的な実施形態では、コントローラ７０８は、モニタ７０６から受信されたバックログが所定の閾値より上であるか否かを判定する。バックログが与えられた閾値より上である場合は、コントローラ７０８は、ポジティブな指標を規制モジュール７１０に送信する。そうでない場合は、コントローラ７０８は、ネガティブな指標を規制モジュール７１０に送信する。例えば、閾値が３０ミリ秒のバックログでセットされていると、コントローラ７０８は、バックログがこの閾値より上である場合、ポジティブな指標を送信することになる。
【００４５】
規制モジュール７１０は、スタビライザ７０４から現在の上限通信速度を受信し、コントローラ７０８から指標を受信する。指標がポジティブである場合、規制モジュールは、現在の通信速度を、所定の最小通信速度に制限する。指標がネガティブである場合、規制モジュールは、現在の通信速度として現在の上限通信速度を用いる。結果として生じる現在の通信速度は、スロットル７１２に送信される。また、規制モジュールは、規制履歴のジャーナルを保持する。ジャーナルは、テーブルまたは他の類似したデータ構造であってもよい。ジャーナルは、スタビライザ７０４に対するバックログのパーセンテージを決定するために調べられる。
【００４６】
典型的な実施形態では、スロットル７１２は、規制モジュール７１０から通信速度を受信する。スロットル７１２は、出入データに対する、最適なパケットサイズおよびパケット通信間隔を決定するために通信速度を用いる。入力間隔は、通信プロトコルとしてＴＣＰを用いる場合、出力間隔に常に等しい。通信プロトコルとしてＵＤＰが用いられる場合には、入力間隔は、遠隔地の送信機のスロットル７１２によって決定される。
【００４７】
図８は、バンド幅オプティマイザ処理の典型的な実施形態のフローチャートである。バンド幅オプティマイザ７００は、最大現行バンド幅を決定８０２する。バンド幅オプティマイザ７００内のモニタ７０６は、現行バックログを決定８０４する。コントローラ７０８は、ステップ８０６で、現行バックログが所定の閾値より大きいかを判定する。もしそうであるならば、規制モジュール７１０は、現在のバンド幅値を平均通信速度に制限する。もしそうでなければ、スタビライザ７０４は、ステップ８１０で、バックログがゼロより大きいかを判定する。バックログがゼロより大きい場合には、バンド幅オプティマイザは、現在のバンド幅値を保持する。バックログがない場合には、スタビライザ７０４は、所定の量ずつ現在のバンド幅値を増加８１４する。そして、スロットルは、現在のバンド幅値で示される通信速度に基づいて、現在のパケットサイズと通信速度とを調整する。
【００４８】
図９は、通信待ち時間を決定するために本発明により用いられるように、待ち時間タイムライン９００の典型的な実施形態を示す図である。バンド幅オプティマイザ７００は、データが発生時点からマルチメディア表示まで伝わるとき、データを追跡するためにタイムスタンプを用いる。各データパケットが伝送経路で特定のポイント９０２を通過するとき、データパケットはタイムスタンプと関連付けられる。タイムスタンプは、データパケット自体に追加されてもよいし、あるいは、データの識別子に関連付けてもよく、データパケットより異なる場所に送信される。典型的な実施形態では、データが送信機に取り込まれたとき、各データパケットは、ポイント９０２Ａでタイムスタンプと関連付けられる。送信機は、データパケットがどちらの方向に進行しているかに応じて、クライアント１０２またはサーバ１０４のいずれかになる。また、送信機がデータパケットを受信機に送信したとき、データパケットは、ポイント９０２Ｂでタイムスタンプと関連付けられる。送信機のように、この場合の受信機は、クライアント１０２またはサーバ１０４のいずれかになる。そして、データパケットは、受信機がデータを受信し、受理証を発生したときにポイント９０２Ｃで、受信機が受理証を送信機に送信したときにポイント９０２Ｄで、送信機が受理証を受信したときにポイント９０２Ｅで、送信機がデータパケットに対する待ち時間を決定するときにポイント９０２Ｆで、タイムスタンプと関連付けられる。
【００４９】
ポイント９０２Ａと９０２Ｂの間で生じる待ち時間、およびポイント９０２Ｅと９０２Ｆの間で生じる待ち時間は、送信機に起因している。ポイント９０２Ｂと９０２Ｃの間で生じる待ち時間、およびポイント９０２Ｄと９０２Ｅとの間で生じる待ち時間は、ネットワークに起因している。最後に、ポイント９０２Ｃと９０２Ｄとの間で生じる待ち時間は受信機に起因している。ゆえに、伝送ストリームを通してデータパケットを追跡することにより、全ての伝送に対する待ち時間を決定することができる。そして、モニタ７０６は、現在のバックログを決定するために待ち時間情報を用いる。
【００５０】
図１０は、本発明により用いられるようなバンド幅表示器の典型的な実施形態を示すブロック図である。バンド幅表示器は、ユーザインターフェースに必要とされる情報を得るためにバンド幅オプティマイザと入出力を行う。ユーザインターフェースについては、以下で、図１１を参照してより詳細に説明する。典型的な実施形態では、バンド幅表示器１０００は、ソフトウェアで実装され、表示器モジュール１００２およびバンド幅メータ１００４を含んでいる。表示器モジュール１００２は、バンド幅決定モジュール７０２、モニタ７０６および規制モジュール７１０から情報を受信し、バンド幅メータ１００４へ情報を出力する。バンド幅メータ１００４は、図１１で説明するユーザインターフェースを作るために、この情報を用いる。バンド幅決定モジュール７０２は、最大上下バンド幅の値を、表示器モジュール１００２へ送信する。モニタ７０６は、上下バックログ情報を表示器モジュール１００２へ送信する。バックログ情報は、実際に送信されたデータに対する通信速度およびバックログを防止するために要求される通信速度の双方を決定するために用いられる。規制モジュール７１０は、出力規制速度を表示器モジュール１００２へ送信する。送信機は、入力規制速度を表示器モジュール１００２へ提供する。いずれの速度も規制された場合、より小さい速度が、バンド幅メータ・ユーザインターフェースに対するスケールとして用いられる。速度が規制されなかった場合には、バンド幅決定モジュールから受信した最大バンド幅がユーザインターフェースに対するスケールとして用いられることになる。表示器モジュール１００２は、入出力値をバンド幅メータ１００４に提供するために速度情報を用いる。これらの値には、最大通信速度、現在の通信速度、およびバックログなしでデータフローを維持するために要求される速度が含まれる。
【００５１】
図１１は、バンド幅メータに対するユーザインターフェースの典型的な実施形態を示す図である。バンド幅メータ・ウインドウ１１００は、入力バンド幅スケール１１０２および出力バンド幅スケール１１０４を含んでいる。各スケール１１０２、１１０４は、水平ヒストグラムメータ１１０８およびパーセンテージ値１１０６を含んでいる。パーセンテージ値１１０６は、水平ヒストグラムメータ１１０８上にグラフィカルに表示される。各スケールは、マルチメディアデータに対する最大通信速度を表示し、３つの部分を含んでいる。第１の部分１１１０は、現在のデータ通信速度を示し、第２の部分１１１２は、利用可能なバンド幅量を示し、第３の部分１１１４は、バックログなしで、望ましいデータフローを保持するために要求される速度の増加を示す。
【００５２】
図１１ａは、上下通信速度が最大に近く、バックログがないことを示しているバンド幅メータを示す図である。図１１ｂは、バックログなしで上下通信速度が最大に近く、入力通信速度が所望するより遅く、わずかなバックログが生じていることを示しているバンド幅メータを示す図である。図１１ｃは、入力通信速度が所望するよりちょうどわずかに小さく、出力通信速度が所望するより非常に小さいことを示しているバンド幅メータを示す図である。この低い通信速度は、ヒストグラムメータ１１０８の第３の部分１１１４によって示されるように、大きなバックログを生じる。図１１ｄは、上下通信速度が利用可能な最大通信速度に比べて小さく、バックログがないことを示しているバンド幅メータを示す図である。
【００５３】
マイクロフォン・キュー
図２に示されるように、1度にたった１つのクライアント１０２だけがオーディオ２１６を送信する。図２において、クライアント１０２Ａは、クライアント１０２Ｂおよび１０２Ｎによって受信されたオーディオ２１６Ａを送信している。クライアントがオーディオを送信しているとき、クライアントは、マイクロフォンを占有する。マイクロフォン・キューは、マイクロフォンの仲裁を容易にするために、ルームサーバ１０６によって実装されたデータ構造である。キューの先頭のクライアント１０２は、マイクロフォンを占有し、ルーム内の他のクライアントによって聞かれることになるクライアントである。各クライアント１０２は、２つのリクエスト：話すリクエストおよび中断するリクエスト、を行うオプションを有する。これらリクエストは、上記図５を参照して説明したように、リクエスト・プロセッサ５００によって取り扱われる。クライアントが話すためにリクエストを行うと、クライアントは、マイクロフォン・キューの最後に置かれる。マイクロフォンを占有するクライアントがマイクロフォンを手放すと、クライアントは、キュー内の次のクライアントにマイクロフォンを占有させるのを許可するために、マイクロフォン・キューから取り除かれる。クライアント１０２が中断するためにリクエストを行うと、クライアントは、マイクロフォン・キューの先頭に置かれる。ゆえに、該クライアントは、マイクロフォンを占有し、マイクロフォンの以前の占有者を含む他のクライアントは、上記クライアントの後ろ側のキュー内のそれらの順序を保持する。
【００５４】
マイクロフォン・キューに対するユーザインターフェースの典型的な実施形態は、２つのアイコンを含んでいる。１つのアイコンは、マイクロフォンの占有１２０４を表し、マイクロフォンを占有しているクライアントの名前に隣接して表示される。第２のアイコンは、マイクロフォン・キューへの配置１２０６を表し、話すことを要求したクライアント１２０８の名前に隣接して表示される。マイクロフォン・キュー内の順序は、ユーザインターフェース内のクライアント・リストの順序によって表される。ゆえに、マイクロフォンを占有しているクライアントの名前は、リストの最上位にあることになり、その次に表示される第１のアイコンを有することになる。マイクロフォンの予定の次のクライアントの名前は、次のリストに載っているものであり、その次に表示される第２のアイコンを有することになる。
【００５５】
インスタント・メッセンジャ統合
一実施形態において、図１に示されるビデオ会議システムは、ルータ１１２に接続された、１つ以上のインスタント・メッセンジャ・サーバを含んでいる。インスタント・メッセンジャ・サーバは、インスタント・ミーティング機能を実装する。この機能は、図１３に示すように、現在利用可能なインスタント・メッセンジャ・プログラムと同様なユーザインターフェースを用いる。この実施形態では、各クライアントは、コンタクトリスト１３００を作ることができる。コンタクトリスト１３００は、クライアント１０２に固有であり、クライアントの画面名称１３０８によって識別される。コンタクトリスト１３００を作る際に、クライアント１０２は、如何なる数の他のクライアント１０２の画面名称を追加してもよい。これらの画面名称は、リスト１３０２に表示される。各名称の隣には、各クライアント１０２がインスタント・ミーティング・サービスにサインインしているか否かを示すアイコン１３０４がある。この実施形態において、クライアント１０２は、ミーティングへの参加のために１つ以上のクライアント１０２を選択することによって、間接的にルームの開設を要求する。参加に招待されたクライアントを選択するために、要請しているクライアントは、画面名称リスト１３０２で、招待されたクライアントのユーザ名をハイライト表示してもよい。要請しているクライアントは、新たなルームを設置し、全ての招待されたクライアントへのアクセスを許可するために、インスタント・メッセンジャ・サーバに指示を出すビデオ呼出ボタン１３０６を選択する。それから、要請しているクライアントは、何れかのポイントでビデオ呼出を始めるために選択してもよく、要請しているクライアントは、新たなルームに入室し、サーバは、招待したクライアントに招待状を送信する。招待されたクライアントも、招待状を受理すると、新たなルームに入室する。
【００５６】
ルーム内では、クライアント１０２は、ビデオ、オーディオおよびテキストを交換してもよい。時には、この情報の交換は、ミーティングに参加しているクライアント１０２の間で衝突を引き起こす可能性がある。これらのユーザは、衝突を解決することを希望して、ビデオ会議を運営する会社に苦情を届けてもよい。衝突を解決するために、会社は、広範囲な研究を実施することを要求されるかも知れず、衝突という結果になった出来事の後に続くクライアントの発言だけに頼らなければならなくなるかも知れない。証拠ジャーナル機能は、これが起こるのを防止する。クライアント１０２が他のクライアント１０２について不満を言いたい場合、不満を言っているクライアントは、証拠ジャーナルを起動させることができる。一旦起動したならば、証拠ジャーナルは、ごく最近のオーディオ、ビデオおよびテキストを記録する。例えば、ジャーナルは、５分のテキスト、５秒のオーディオ、および１０秒のビデオを取り込む。時間間隔は、予め決められており、会社の必要性に基づいて変更してもよい。
【００５７】
本発明の典型的な実施形態および様々な変形例を十分に説明したので、当業者は、ここに与えられた教えに基づき、本発明から逸脱しない数多くの変形例および同等物が存在することを理解されたであろう。すなわち、本発明は、前述の説明によって限定されることなく、添付の特許請求の範囲により制限されるものである。
【図面の簡単な説明】
【００５８】
【図１】本発明の典型的な実施形態を含むネットワーク図である。
【図２】本発明の典型的な実施形態によるマルチメディアのストリーミング図である。
【図３】本発明の典型的な実施形態によるルームサーバのブロック図である。
【図４】本発明の典型的な実施形態によるクライアントのブロック図である。
【図５】本発明の典型的な実施形態によるスレッディング・モデルの図である。
【図６】本発明の典型的な実施形態による動的データ伝送のフローチャートである。
【図７】バンド幅オプティマイザの典型的な実施形態のブロック図である。
【図８】バンド幅オプティマイザ処理の典型的な実施形態のフローチャートである。
【図９】伝送待ち時間を決定するために本発明によって用いられる、待ち時間タイムラインの典型的な実施形態を示す概念図である。
【図１０】本発明によって用いられる、バンド幅インジケータの典型的な実施形態を表すブロック図である。
【図１１】バンド幅メータのためのユーザインターフェースの典型的な実施形態を示す図である。
【図１２】マイクロフォン・キューを含むユーザインターフェースの典型的な実施形態の表示画面を示す模式図である。
【図１３】インスタント・ミーティング機能で用いられる、コンタクトリストの典型的な実施形態の表示画面を示す模式図である。
【符号の説明】
【００５９】
１００ ネットワーク
１０２ クライアント
１０２Ａ，１０２Ｂ，１０２Ｎ クライアント
１０４ サーバ
１０６ エントリサーバ
１０８ ロビーサーバ
１１０ ルームサーバ
１１２ ルータ
２０２，２１０ 受信機
２０４，２１２ 送信機
２１４ ビデオデータ
２１４Ａ，２１４Ｂ，２１４Ｎ ビデオストリーム
２１６ オーディオデータ
２１６Ａ オーディオストリーム
３０６ シーケンサ
３０８ オーディオ再シーケンサ
３１０ ビデオ再シーケンサ
３１２ マルチメディア・オーディオ・キュー
３１４ ビデオ・マルチプレクサ
３１６ パケット・エンコーダ
４０２ ビデオ・デマルチプレクサ
４０４ ディスプレイ
４０６ スピーカ
４０８ カメラ
４１０ マイクロフォン
５００ リクエスト・プロセッサ
５０２ 入力イベント・スレッド・プール
５０４ メイン・スレッド・プール
５０６ 出力イベント・スレッド・プール
５０８ リクエスト・キュー
７００ バンド幅オプティマイザー
７０２ バンド幅決定モジュール
７０２ 接続アナライザ
７０４ スタビライザ
７０６ モニタ
７０８ コントローラ
７１０ 規制モジュール
７１２ スロットル
Claims (15)
- ２つ以上のクライアント間でマルチメディア伝送を送受信するコンピュータにより実行される方法であって、
クライアントとサーバとの間の接続に対する最大上下通信速度を決定するステップと、
前記接続を介しての伝送に対する待ち時間値を決定するステップと、
前記接続を介しての伝送に対するバックログ値を決定するステップと、
前記バックログ値および前記待ち時間値に応じて前記接続を介しての上下通信速度を変化させるステップと
を具備することを特徴とするコンピュータにより実行される方法。 - 前記マルチメディア伝送は、データパケットからなり、
前記通信速度を変化させる際に、
前記データパケットのサイズを変化させ、
各データパケットの伝送間の時間間隔を変化させること
をさらに含むことを特徴とする、請求項１に記載のコンピュータにより実行される方法。 - 前記通信速度を変化させるステップは、
バックログがなく、かつ通信速度が最大通信速度より小さい場合には、通信速度を増加させるステップと、
バックログが所定の閾値を越える場合には、通信速度を減少させるステップと
をさらに含むことを特徴とする、請求項１に記載のコンピュータにより実行される方法。 - 前記伝送は、クライアントで始まり、サーバで終わることを特徴とする、請求項１に記載のコンピュータにより実行される方法。
- 前記伝送は、サーバで始まり、クライアントで終わることを特徴とする請求項１に記載のコンピュータにより実行される方法。
- ２つ以上のクライアント間でマルチメディアデータ伝送を送受信するシステムであって、
マルチメディア伝送を受信するための受信機と、
可変通信速度で前記マルチメディア伝送を送信するための送信機と、
前記送信機に結合され、最大上下通信速度を決定し、前記マルチメディアデータ伝送におけるバックログをモニタリングし、前記バックログに応じて通信速度を変化させるバンド幅オプティマイザと
を具備することを特徴とするマルチメディアデータ送受信システム。 - 前記マルチメディア伝送は、データパケットからなり、
前記通信速度を変化させる際に、
前記データパケットのサイズを変化させ、
各データパケットの伝送間の時間間隔を変化させることを特徴とする請求項６記載のマルチメディアデータ送受信システム。 - 前記通信速度を変化させる際に、
バックログがなく、かつ通信速度が最大通信速度より小さい場合には、通信速度を増加させ、
バックログが所定の閾値を越える場合には、通信速度を減少させることを特徴とする請求項６記載のマルチメディアデータ送受信システム。 - 前記伝送は、クライアントで始まり、サーバで終わることを特徴とする請求項６記載のマルチメディアデータ送受信システム。
- 前記伝送は、サーバで始まり、クライアントで終わることを特徴とする請求項６記載のマルチメディアデータ送受信システム。
- ２つ以上のクライアント間でマルチメディア伝送を送受信するコンピュータで読み込み可能な媒体に格納されたコンピュータプログラム製品であって、
クライアントとサーバとの間の接続に対する最大上下通信速度を決定するステップと、
前記接続を介しての伝送に対する待ち時間値を決定するステップと、
前記接続を介しての伝送に対するバックログ値を決定するステップと、
前記バックログ値および前記待ち時間値に応じて前記接続を介しての上下通信速度を変化させるステップと
を実行させるべく前記媒体に接続されたプロセッサを制御することを特徴とするコンピュータプログラム製品。 - 前記マルチメディア伝送は、データパケットからなり、
前記通信速度を変化させるステップは、
前記データパケットのサイズを変化させるステップと、
各データパケットの伝送間の時間間隔を変化させるステップと
をさらに含むことを特徴とする請求項１１記載のコンピュータプログラム製品。 - 前記通信速度を変化させるステップは、
バックログがなく、かつ通信速度が最大通信速度より小さい場合には、通信速度を増加させるステップと、
バックログが所定の閾値を越える場合には、通信速度を減少させるステップと
をさらに含むことを特徴とする請求項１１記載のコンピュータプログラム製品。 - 前記伝送は、クライアントで始まり、サーバで終わることを特徴とする請求項１１記載の方法。
- 前記伝送は、サーバで始まり、クライアントで終わることを特徴とする請求項１１記載の方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/045,133 US20030041165A1 (en) | 2001-08-24 | 2001-10-23 | System and method for group video teleconferencing using a bandwidth optimizer |
| PCT/US2002/034024 WO2003036499A1 (en) | 2001-10-23 | 2002-10-23 | System and method for group video teleconferencing using a bandwidth optimizer |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2005507200A true JP2005507200A (ja) | 2005-03-10 |
Family
ID=21936163
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003538920A Pending JP2005507200A (ja) | 2001-10-23 | 2002-10-23 | バンド幅最オプティマイザを用いるグループ・ビデオ会議システムおよび方法 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US20030041165A1 (ja) |
| EP (1) | EP1444594A1 (ja) |
| JP (1) | JP2005507200A (ja) |
| KR (1) | KR20040084892A (ja) |
| CA (1) | CA2464505A1 (ja) |
| WO (1) | WO2003036499A1 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007202129A (ja) * | 2006-01-25 | 2007-08-09 | Seiko Epson Corp | データ中継サーバの通信方法、ファイヤウォールで保護されたビデオ会議サーバの通信方法、およびビデオ会議クライアントの通信方法 |
| JP2012133792A (ja) * | 2005-04-07 | 2012-07-12 | Opanga Networks Inc | 適応型ファイル配信システムおよび方法 |
Families Citing this family (54)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7058817B1 (en) | 1999-07-02 | 2006-06-06 | The Chase Manhattan Bank | System and method for single sign on process for websites with multiple applications and services |
| US8571975B1 (en) | 1999-11-24 | 2013-10-29 | Jpmorgan Chase Bank, N.A. | System and method for sending money via E-mail over the internet |
| US10185936B2 (en) | 2000-06-22 | 2019-01-22 | Jpmorgan Chase Bank, N.A. | Method and system for processing internet payments |
| US8335855B2 (en) * | 2001-09-19 | 2012-12-18 | Jpmorgan Chase Bank, N.A. | System and method for portal infrastructure tracking |
| US7103556B2 (en) * | 2000-11-02 | 2006-09-05 | Jpmorgan Chase Bank, N.A. | System and method for aggregate portfolio client support |
| US8849716B1 (en) | 2001-04-20 | 2014-09-30 | Jpmorgan Chase Bank, N.A. | System and method for preventing identity theft or misuse by restricting access |
| WO2002099598A2 (en) | 2001-06-07 | 2002-12-12 | First Usa Bank, N.A. | System and method for rapid updating of credit information |
| US7266839B2 (en) | 2001-07-12 | 2007-09-04 | J P Morgan Chase Bank | System and method for providing discriminated content to network users |
| US7103576B2 (en) * | 2001-09-21 | 2006-09-05 | First Usa Bank, Na | System for providing cardless payment |
| US7574597B1 (en) | 2001-10-19 | 2009-08-11 | Bbn Technologies Corp. | Encoding of signals to facilitate traffic analysis |
| EP1444568A4 (en) * | 2001-11-01 | 2005-11-09 | Bank One Delaware Nat Ass | SYSTEM AND METHOD FOR ESTABLISHING OR AMENDING AN ACCOUNT WITH USER SELECTABLE TERMS |
| US7987501B2 (en) | 2001-12-04 | 2011-07-26 | Jpmorgan Chase Bank, N.A. | System and method for single session sign-on |
| US20180165441A1 (en) | 2002-03-25 | 2018-06-14 | Glenn Cobourn Everhart | Systems and methods for multifactor authentication |
| US7376235B2 (en) * | 2002-04-30 | 2008-05-20 | Microsoft Corporation | Methods and systems for frustrating statistical attacks by injecting pseudo data into a data system |
| KR20030095995A (ko) * | 2002-06-14 | 2003-12-24 | 마츠시타 덴끼 산교 가부시키가이샤 | 미디어 전송방법 및 그 송신장치 및 수신장치 |
| US7058660B2 (en) * | 2002-10-02 | 2006-06-06 | Bank One Corporation | System and method for network-based project management |
| US7353253B1 (en) * | 2002-10-07 | 2008-04-01 | Webex Communicatons, Inc. | Peer-to-peer messaging system |
| US8301493B2 (en) | 2002-11-05 | 2012-10-30 | Jpmorgan Chase Bank, N.A. | System and method for providing incentives to consumers to share information |
| US7873706B2 (en) * | 2003-03-19 | 2011-01-18 | Cgi Communications, Inc. | System and method for seamlessly providing video content to client systems over a network |
| US9432463B2 (en) * | 2003-03-25 | 2016-08-30 | Sandvine Incorporated Ulc | System and method for diverting established communication sessions on the basis of content |
| US7580976B2 (en) * | 2003-04-18 | 2009-08-25 | Microsoft Corporation | Identifying an appropriate connection point for connecting to an application layer session |
| JP4183586B2 (ja) * | 2003-09-12 | 2008-11-19 | 三洋電機株式会社 | 映像表示装置 |
| US20050091395A1 (en) * | 2003-10-08 | 2005-04-28 | Jason Harris | Method and system for transferring data files |
| US8359349B2 (en) * | 2004-03-18 | 2013-01-22 | Nokia Corporation | System and associated terminal, method and computer program product for uploading content |
| US7720983B2 (en) * | 2004-05-03 | 2010-05-18 | Microsoft Corporation | Fast startup for streaming media |
| US20060055771A1 (en) * | 2004-08-24 | 2006-03-16 | Kies Jonathan K | System and method for optimizing audio and video data transmission in a wireless system |
| US20060190723A1 (en) * | 2005-02-18 | 2006-08-24 | Jp Morgan Chase Bank | Payload layer security for file transfer |
| US8583926B1 (en) | 2005-09-19 | 2013-11-12 | Jpmorgan Chase Bank, N.A. | System and method for anti-phishing authentication |
| US20070127521A1 (en) * | 2005-12-02 | 2007-06-07 | The Boeing Company | Interface between network data bus application and avionics data bus |
| US8140618B2 (en) | 2006-05-04 | 2012-03-20 | Citrix Online Llc | Methods and systems for bandwidth adaptive N-to-N communication in a distributed system |
| WO2008000289A1 (en) * | 2006-06-29 | 2008-01-03 | Telecom Italia S.P.A. | Method and apparatus for improving bandwith exploitation in real-time audio/video communications |
| US8793490B1 (en) | 2006-07-14 | 2014-07-29 | Jpmorgan Chase Bank, N.A. | Systems and methods for multifactor authentication |
| US9275372B2 (en) * | 2006-10-03 | 2016-03-01 | International Business Machines Corporation | Controlling active and passive participation in a thread of conversation |
| US8473735B1 (en) | 2007-05-17 | 2013-06-25 | Jpmorgan Chase | Systems and methods for managing digital certificates |
| US8180029B2 (en) * | 2007-06-28 | 2012-05-15 | Voxer Ip Llc | Telecommunication and multimedia management method and apparatus |
| US9154333B2 (en) * | 2007-12-26 | 2015-10-06 | International Business Machines Corporation | Balanced management of scalability and server loadability for internet protocol (IP) audio conferencing based upon monitored resource consumption |
| US8321682B1 (en) | 2008-01-24 | 2012-11-27 | Jpmorgan Chase Bank, N.A. | System and method for generating and managing administrator passwords |
| DE102008013349B4 (de) * | 2008-03-10 | 2017-07-06 | Hytera Mobilfunk Gmbh | Kommunikationsverfahren und Kommunikationssystem mit Paketabstands- und Paketlängen-Regelung |
| US8516121B1 (en) * | 2008-06-30 | 2013-08-20 | Symantec Corporation | Method and apparatus for optimizing computer network usage to prevent congestion |
| US9608826B2 (en) | 2009-06-29 | 2017-03-28 | Jpmorgan Chase Bank, N.A. | System and method for partner key management |
| WO2011100582A1 (en) * | 2010-02-12 | 2011-08-18 | Lightspeed Vt Llc | System and method for remote presentation provision |
| US9043509B2 (en) * | 2011-01-14 | 2015-05-26 | Broadcom Corporation | Method and system for low-latency networking |
| US9179169B2 (en) | 2012-03-14 | 2015-11-03 | Imagine Communications Corp. | Adaptive media delivery |
| US9515942B2 (en) * | 2012-03-15 | 2016-12-06 | Intel Corporation | Method and system for access point congestion detection and reduction |
| US9419957B1 (en) | 2013-03-15 | 2016-08-16 | Jpmorgan Chase Bank, N.A. | Confidence-based authentication |
| CA2920122A1 (en) * | 2013-08-08 | 2015-02-12 | Ricoh Company, Limited | Program, communication quality estimation method, information processing apparatus, communication quality estimation system, and storage medium |
| US9344218B1 (en) | 2013-08-19 | 2016-05-17 | Zoom Video Communications, Inc. | Error resilience for interactive real-time multimedia applications |
| US9621636B1 (en) | 2013-09-10 | 2017-04-11 | Google Inc. | Distributed processing system throttling |
| US10148726B1 (en) | 2014-01-24 | 2018-12-04 | Jpmorgan Chase Bank, N.A. | Initiating operating system commands based on browser cookies |
| US9794078B2 (en) * | 2014-03-05 | 2017-10-17 | Ricoh Company, Ltd. | Fairly adding documents to a collaborative session |
| DE102014115188A1 (de) * | 2014-10-17 | 2016-04-21 | Visocon Gmbh | Verfahren zur Anpassung eines zu übertragenden Datenstroms an eine Ressourcenauslastung |
| FR3079704A1 (fr) * | 2018-03-29 | 2019-10-04 | Orange | Communication par video conference |
| US10917323B2 (en) * | 2018-10-31 | 2021-02-09 | Nutanix, Inc. | System and method for managing a remote office branch office location in a virtualized environment |
| KR102279356B1 (ko) * | 2020-10-16 | 2021-07-20 | (주)아크로비젼 | 케이블 기반 개폐식 지붕의 모니터링을 위한 영상 전송 방법 및 장치 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5905729A (en) * | 1995-07-19 | 1999-05-18 | Fujitsu Network Communications, Inc. | Mapping a data cell in a communication switch |
| US6185121B1 (en) * | 1998-02-26 | 2001-02-06 | Lucent Technologies Inc. | Access structure for high density read only memory |
| DE19809385A1 (de) * | 1998-03-05 | 1999-09-09 | Bosch Gmbh Robert | Schaltregler |
| US6590885B1 (en) * | 1998-07-10 | 2003-07-08 | Malibu Networks, Inc. | IP-flow characterization in a wireless point to multi-point (PTMP) transmission system |
-
2001
- 2001-10-23 US US10/045,133 patent/US20030041165A1/en not_active Abandoned
-
2002
- 2002-10-23 EP EP02802206A patent/EP1444594A1/en not_active Withdrawn
- 2002-10-23 CA CA002464505A patent/CA2464505A1/en not_active Abandoned
- 2002-10-23 WO PCT/US2002/034024 patent/WO2003036499A1/en not_active Application Discontinuation
- 2002-10-23 KR KR10-2004-7005895A patent/KR20040084892A/ko not_active Application Discontinuation
- 2002-10-23 JP JP2003538920A patent/JP2005507200A/ja active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012133792A (ja) * | 2005-04-07 | 2012-07-12 | Opanga Networks Inc | 適応型ファイル配信システムおよび方法 |
| JP2007202129A (ja) * | 2006-01-25 | 2007-08-09 | Seiko Epson Corp | データ中継サーバの通信方法、ファイヤウォールで保護されたビデオ会議サーバの通信方法、およびビデオ会議クライアントの通信方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2003036499A1 (en) | 2003-05-01 |
| CA2464505A1 (en) | 2003-05-01 |
| KR20040084892A (ko) | 2004-10-06 |
| EP1444594A1 (en) | 2004-08-11 |
| US20030041165A1 (en) | 2003-02-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2005507200A (ja) | バンド幅最オプティマイザを用いるグループ・ビデオ会議システムおよび方法 | |
| KR101392122B1 (ko) | 멀티캐스트 배신 시스템 및 멀티캐스트 배신 방법 | |
| US7257641B1 (en) | Multipoint processing unit | |
| EP1454281B1 (en) | Quality of service setup on a time reservation basis | |
| KR101432303B1 (ko) | 대역 요구 장치, 클라이언트 기기, 대역 요구 방법 및 기록 매체 | |
| KR100964983B1 (ko) | 네트워크에 걸쳐서 화상회의 세션을 자동으로 개시하는 방법 및 시스템, 네트워크에 걸쳐서 화상회의 세션에 참가하기 위한 방법 및 네트워크에 걸쳐서 멀티캐스트 세션에 참가하기 위한 방법 | |
| US9154395B2 (en) | Method and system for optimizing a jitter buffer | |
| US20020064136A1 (en) | Conferencing network resource optimization for multi-point conferences | |
| US9948889B2 (en) | Priority of uplink streams in video switching | |
| WO2008039077A1 (en) | Method and device for providing scalability in streaming/archiving systems for conference calls | |
| WO2007126652A2 (en) | Network resource optimization in a video conference | |
| US20090193481A1 (en) | Method, device and system for providing a broadcast tv | |
| US20100091687A1 (en) | Status of events | |
| CN110445723A (zh) | 一种网络数据调度方法及边缘节点 | |
| US9942161B1 (en) | Methods and systems for configuring and updating session-based quality of service for multimedia traffic in a local area network | |
| US20020034164A1 (en) | Method and device for controlling a telecommunication conference | |
| JP2004350227A (ja) | ビデオ会議システムにおける会議クライアント装置及びそのプログラム | |
| AU2002363069A1 (en) | System and method for group video teleconferencing using a bandwidth optimizer | |
| CN114567747A (zh) | 一种会议数据传输方法及会议系统 | |
| EP1461708A1 (en) | System and method for group video teleconferencing with variable bandwidth | |
| JP2009194495A (ja) | マルチキャスト通信システム及びマルチキャスト通信方法 | |
| WO2008092250A1 (en) | Cooperative system and method for duplicating and delivering media streams in a distributed manner. | |
| Smith et al. | Quality of Service Management within a Middleware for Large Scale Multicast Applications | |
| JP2004349824A (ja) | 映像配信システムおよび映像配信方法 | |
| JP2004048153A (ja) | 通信制御装置、通信制御方法、通信制御プログラムおよび通信制御プログラムを記録したコンピュータ読み取り可能な記録媒体 |