JP4546739B2 - ジャストインタイムのリソース提供、自動化された信号取得及びストリーミング、並びに完全自動化されたイベントアーカイブによるウェブキャスティング - Google Patents

Description

本発明は、一般的にウェブキャスティングに係り、詳細には、視聴会員（audience member）が、例えばストリーミングメディアプレーヤを備えたウェブブラウザを実行するコンピュータを使用することにより、コンピュータネットワークを介して音声会議通話にアクセスするネットワークベースの会議通話に関する。

従来技術において、音声映像の会議を統合されたストリーミング音声映像によって双方向の会議キャストに変換するマルチメディアビジネス通信プラットフォームを提供することは知られている。エンドユーザは、標準ウェブブラウザだけを使用してインターネット上の任意の場所から会議キャストに参加し、通話が参加者に「ストリーミング」される。ストリーミングメディアは、既知のように、ダウンロードしている最中でも再生することができるという重要な特性を有するインターネットコンテンツの一種である。クライアント装置は、音声又は映像ストリームの第１のパケットを再生し、第２のパケットを復元しながら、第３のパケットを受け取ることができる。従って、エンドユーザは、伝送終了まで待つことなくマルチメディアを視聴し始めることができる。ストリーミングメディアの品質は、配信されるメディアの種類、ユーザのインターネット接続の速度、ネットワークの状態、コンテンツをエンコードするビットレート、及び使用されるフォーマットによって大きく変わる。非ストリーミングコンテンツは、Ａｐａｃｈｅ ｓｅｒｖｅｒ、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ等の様々なベンダによって開発されたサーバ及びクライアントソフトウエアが一般に一緒にうまく動作するという意味で標準的である。しかしながら、ストリーミングメディアは、通常、独自開発のサーバ及びクライアントソフトウエアに依存する。ストリーミングソフトウェアベンダによって開発されたサーバツール、クライアントツール、作成ツール及びエンコーディングツールは、ひとまとめにフォーマットと呼ばれる。特定のフォーマットでエンコードされたストリーミングメディアは、そのフォーマットのメディアサーバから供給され、そのフォーマットのクライアントによって再生されなければならない。ストリーミングメディアクライアントは、プレーヤと呼ばれることがあり、一般に、これはウェブブラウザのプラグインとして存在する。最も一般的なストリーミングフォーマットは、Ｗｉｎｄｏｗｓ Ｍｅｄｉａ（ＷＭＳ）、Ｒｅａｌ、及びＡｐｐｌｅ ＱｕｉｃｋＴｉｍｅである。

会議通話イベントは、一般に、図１に示し後で説明するようにセットアップされる。主催者１００は、会議イベントの予定をたてるためにサービスビューロ１０２に連絡をとる。サービスビューロは、一般に、イベント登録システム１０４を操作する。段階（１）で、主催者１００は、ウェブ予約担当者に電話する。段階（２）で、予約担当者は、顧客アカウントがまだ存在しない場合はそれを作成し、会議イベントの予定を立てる。段階（３）で、担当者は、イベント登録システム１０４にイベント情報を入力する。次に、段階（４）で、担当者は、情報を確認し、主催者１００に、聴取者ウェブサイトのアドレス、主催者ウェブサイトのアドレス、イベントの識別名、並びにユーザ名、及びパスワードを送る。段階（５）で、主催者１００は、主催者ウェブサイトのアドレスを入力し、主催者のログインページを表示させる。主催者は、サービスビューロの予約担当者から提供されたイベントＩＤ、ユーザ名（必要に応じて）、及びパスワード（必要に応じて）を入力する。段階（６）で、主催者１００は、管理ページにアクセスする。そのページから、主催者１００は、視聴会員への案内の作成と送付、イベントの監視、可能な場合にはイベントのアーカイブへのアクセス、アーカイブの編集、使用報告書へのアクセス、イベント情報へのアクセス、イベント情報の編集等の幾つかの提供及び管理タスクを実行することができる。段階（７）で、主催者は、視聴会員に案内を送る。メッセージは、一般に、視聴者ウェブサイトへのリンクだけでなくイベントＩＤを含む。段階（８）で、見込み視聴会員が、主催者から通知を受け取る。イベントにアクセスするために、視聴会員は、リンクをクリックし（又は、ＵＲＬを手動で入力し）、自分のブラウザのメディアプレーヤで視聴者ウェブサイトを表示させる。イベントに接続するために、エンドユーザ視聴会員は、ビデオカード（全てのコンピュータに標準）、サウンドカード及びインターネット接続機能を備えたコンピュータ、インターネットブラウザ（Ｉｎｔｅｒｎｅｔ ＥｘｐｌｏｒｅｒやＮｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ等）、ストリーミングメディアプレーヤ（例えば、Ｗｉｎｄｏｗｓ Ｍｅｄｉａ ＰｌａｙｅｒやＲｅａｌＰｌａｙｅｒ等）、並びにイベントのウェブサイトアドレスを有する必要がある。視聴会員は、視聴者ウェブサイトから、イベントＩＤ、ユーザ名（必要に応じて）、及びパスワード（必要に応じて）を入力してイベントにアクセスする。当然ながら、前述の段階の１以上を自動的に及び／又はオンラインで実行することができる。

従来のインターネット会議キャスティングシステムには、幾つかの欠点がある。このアプリケーションは、一般に、予約情報を生成し、イベントを開始し、主催者又は参加者を認証するためにデータベースを使用している。データベースが使用できない場合はイベントを実行できないので、データベースへの依存は、単一障害箇所（single point of failure）を作り出す可能性がある。同様に、典型的なアプリケーションは、単一サーバからイベントストリームを実行し、これがやはり、単一障害箇所に相当し、拡張性即ち会議に出席可能な参加者の数を制限する。更に、従来技術のシステムは、ストリームの高度なセットアップを必要とし、これが、イベントを予約した時間とイベント自体の発生の間のブラックアウト期間を決定する。従って、イベントの予定を立てた後で、サービス提供者は、通常、前もって様々なシステムや他のリソースを提供したり割り振ったりしなければならない。そのようなリソースには、メディアエンコーダ、記憶域、ネットワーク接続、ストリーミングサーバポート又はパブリッシングポイント等があるが、これらに限定されない。これらの他に、予約を処理し管理機能を提供するための人的リソースも必要である。その結果、従来技術の会議キャスティングシステムには、イベントを予約して直ちに実行し、生じたストリームを視聴会員がすぐに利用可能にする能力がない。従来技術のシステムにおいて、ストリーム冗長性は、一般に、特別な取り扱いを必要としコストを高める。また、従来技術の会議キャスティングシステムには、イベントを自動的にアーカイブし及び／又はイベントの終了前に特定のストリームをいつ中断するかを管理する能力がない。

本発明は、従来技術の上記及びその他の問題に取り組む。

本発明によると、コンピュータネットワークを介してウェブキャスティングするための装置であって、ウェブキャスティングされるイベントは話し手のスピーチをコンピュータネットワークを介して一人以上の視聴会員へキャスティングするウェブベースの音声会議イベントであり、コンピュータネットワークを介してアクセス可能であり、エンティティが、ウェブキャスティングされるイベントを予約し、イベント識別名、アクセスコード及び参加者ＵＲＬを取得し、ウェブキャスティングされるイベントと関連したイベント情報ファイルの記憶を開始することを可能にするコードを含む第１のサブシステムと、電話網に接続可能であり、エンティティが、イベント情報ファイルにアクセスすることなく、エンティティが入力したイベント識別名と、共有キーとの一方向ハッシュから導出する値がエンティティが入力したアクセスコードと一致することを検証することによってウェブキャスティングされるイベントを開始することを可能にするコードと、電話網を介して受信可能な話し手のスピーチから得られた音声信号からデータストリームを生成するコードとを含む第２のサブシステムと、コンピュータネットワークを介してアクセス可能であり、視聴会員である聞き手と関連したクライアントブラウザが参加者ＵＲＬを要求するのに応答して、ストリームＵＲＬを含むデータ構造をクライアントブラウザに返すコードを含む第３のサブシステムとより成り、ストリームＵＲＬがストリーミングメディアプレーヤによるデータストリームの取得を可能にすることにより、ウェブキャスティングされるイベント中に聞き手が視聴会員でない話し手のスピーチを聞くことができるウェブキャスティング装置が提供される。
また、本発明によると、会議システムによりコンピュータネットワークを介して会議をウェブキャスティングする方法であって、（ａ）会議システムがエンティティにイベント識別名、アクセスコード、及び参加者ＵＲＬを提供し、（ｂ）イベント情報ファイルを生
成し、（ｃ）音声会議キャスティングイベントであるウェブキャスティングされるイベントと関連した、イベント情報ファイルを記憶するディレクトリを作成することによって、ウェブキャスティングされるイベントのエンティティによる予約を可能にする段階と、（ｄ）会議システムがエンティティが入力したイベント識別名と共有キーとの一方向ハッシュから導出する値がエンティティが入力したアクセスコードと一致することを検証し、（ｅ）検証できたときに、話し手のスピーチデータをデータストリームにエンコードすることによって、ウェブキャスティングされるイベントを開始する段階と、（ｆ）会議システムが参加者ＵＲＬを開いたクライアントブラウザに、データストリームを取得することができるストリームＵＲＬを含むデータ構造を返すことによって、視聴会員である聞き手がデータストリームにアクセスするのを可能にすることにより、ウェブキャスティングされるイベント中に聞き手が視聴会員でない話し手のスピーチを聞くことができるようにする段階と、会議システムがウェブキャスティングされるイベントの終了時にアーカイブを生成する段階と、会議システムが、参加者ＵＲＬに対してクライアントブラウザを開くことにより、後でエンドユーザをアーカイブへアクセスさせる段階とを含むウェブキャスティングの方法をも提供される。
さらに、本発明によると、ウェブキャスティングされるイベントにイベント識別名、アクセスコード及び参加者ＵＲＬを関連させることによってウェブキャスティングされる所定のイベントが予約された会議システムにより会議をウェブキャスティングする方法であって、（ａ）会議システムがエンティティが入力したイベント識別名と共有キーとの一方向ハッシュから導出する値がエンティティが入力したアクセスコードと一致することを検証し、（ｂ）検証できたときに、話し手のスピーチから得られたスピーチデータをデータストリームにエンコードすることによって、ウェブキャスティングされるイベントを１つ以上の場所で開始させる段階と、（ｃ）会議システムが参加者ＵＲＬを開いたクライアントブラウザに、データストリームを取得することができる１以上のストリームＵＲＬを含むデータ構造を返すことによって、視聴会員である聞き手がデータストリームにアクセスするのを可能にし、ウェブキャスティングされるイベント中に聞き手が視聴会員でない話し手のスピーチを聞くことができるようにする段階と、会議システムが、ウェブキャスティングされるイベントが進行するにつれて、ローカルデータ記憶機構に各データストリームのコピーを記憶する段階と、会議システムが、スピーチデータの中断時に、記憶されたデータストリームのコピーを中央データ記憶機構に転送する段階と、会議システムが、ウェブキャスティングされるイベントの終了時に、アーカイブを自動的に生成する段階と、会議システムが、後で、エンドユーザが参加者ＵＲＬを用いてアーカイブへアクセスするのを可能にする段階とを含む、会議をウェブキャスティングする方法をも提供される。
従って、本発明は、双方向通信サービスのための総合的な機能群を提供しかつ拡張性と信頼性を最大するように設計されたネットワークベースの会議通話システムを実現する。このシステムは、「ジャストインタイム」又はオンデマンドのリソース提供並びに自動化された電話信号取得及びストリーミングを提供する。エンティティは、イベントの予約をし、イベント識別名と、アクセスコード又はＰＩＮとを受け取る。イベントに関する情報（望ましいストリームフォーマット、アーカイブ期間等）が、コンテンツ記憶サブシステムに記憶され、また従来のリレーショナルデータベースに非同期に記憶されることが好ましい。次に、ユーザ（主催者又は主催者の代わりをするエンティティ）が、電話番号を入力することによって通話（又は、冗長のための２重通話）を開始するとき、通話は、好ましくはコンテンツ配信ネットワークを介して、使用可能なボイスセンターにルーティングされ、１つ以上のストリームフォーマットで自動的にストリーミングされる。ボイスサーバは、好ましくはコンテンツ記憶サブシステムやデータベースにアクセスすることなくイベントＰＩＮを確認する。使用可能なリソースへの通話の遅い結合と、外部サブシステムを使用せずにイベントＰＩＮを確認するボイスサーバの機能とにより、極めて信頼性が高くかつ拡張性の高いシステムが提供される。視聴会員は、この場合もコンテンツ記憶サブシステムやデータベースに依存することなく、ストリームにアクセスするために必要な全ての情報を自ら含むことが好ましいリンク（参加者ＵＲＬ）を提供される。視聴会員は、
ウェブブラウザ及び関連したメディアプレーヤを使用してストリームライブを聞く。通話が切断された後、通話中にボイスサーバからコンテンツ記憶サブシステムにアップロードされたデータストリームファイルコピーからアーカイブが生成される。このアーカイブは、予約時に指定された時間の長さだけ視聴会員に使用可能にされることが好ましい。

本発明の会議通話システムは、物理リソースの事前提供を必要としない。より正確に言うと、実質的に全てのリソースが、ユーザの参加時にイベントに自動的に結合される。これらのリソースは、データセンター、ボイスサーバ、及びエンコーダを含む。音声リソースのこの「ジャストインタイム」又はオンデマンドの割り振りによって、システムの耐障害性が高くなる。信号取得前にどれかのリソース又はアセットに障害が起きた場合は、その装置が、使用可能リソースプールから除去される。これにより、システムは、使用可能なアセットの中から正常に機能する状態で選択することができる。そのようなアセットの状態が適正であることを確実にするために、システムは、リソースアセットの自動的な監視と検査を実施する。ダイアルインにより、会議は、正常に機能しているリソースだけを使用することになり、これにより耐障害性が最大になる。ユーザがログインし、ボイスサーバに接続された後も、システムは、アクセスを認証しイベントを開始するためにデータベースに依存しない。システムのデータベースインタフェースは、非同期的であることが好ましく、それにより、イベント予約の要求が出されたときにデータベースが使用不能な場合、予約は要求に応じて完了する。その後で、データベースは、報告のために予約情報で更新される。データベースがまだ更新されていない場合や使用不能な場合でもイベントを実行することができる。

１つの特定の実施形態において、本発明は、ネットワークを介した会議キャスティングを可能にするマルチメディアビジネス通信プラットフォームを実現する。エンドユーザ又は所謂「視聴会員」は、ストリーミングメディアプレーヤを実行する標準のウェブブラウザを使用して、インターネット上の任意の場所又は企業ファイアウォールの後ろから会議キャストに参加する。会議プラットフォームは、一般に、ウェブ予約サブシステム、ボイスサーバサブシステム、コンテンツ記憶サブシステム、データ監視サブシステム、参加者アクセスサブシステム、及びアーカイブサブシステムの幾つかのサブシステムを含む。ウェブ予約サブシステムは、エンティティがイベント予約をすることを可能にする機構を提供する。ウェブ予約サブシステムは、一般に、データベース及び関連したデータベース管理システムを含む。ボイスサーバサブシステムは、ユーザを確認し、入ってきた電話信号（即ち、会議通話）を出力データストリームに変換する。参加者アクセスサブシステムは、参加者の要求に応答して、会議キャストに参加する方法を参加者のストリーミングメディアプレーヤに指示する情報（例えば、ストリームメタファイル等のデータ構造）を返す。コンテンツ記憶サブシステムは、イベント情報を管理するために使用され、アーカイブサブシステムの管理下で、イベントファイルをアーカイブする。データ監視サブシステムは、ネットワーク全体にわたって分散された１組の監視エージェントを含む。これらの構成要素を活用することによって、システムは、ジャストインタイムのリソース提供、自動化された信号取得及びストリーミング、及びイベント完了時の自動化されたアーカイビングを実施する。

以上は、本発明のより適切な目的及び機能の幾つかを概略的に説明した。このような目的は、単に本発明のより卓越した特長とアプリケーションのうちの一部の例示であると解釈されるべきである。

本発明及びその利点をより完全に理解するために、添付図面と関連して行われる以下の詳細な説明を参照されたい。

本発明は、公けにルーティング可能なインターネット、企業イントラネット、専用ネットワーク又はこれらの任意の組み合わせを含むネットワークを介した会議キャスティングを可能にするマルチメディアビジネス通信プラットフォームを実現する。エンドユーザ又は所謂「視聴会員（audience member）」は、ストリーミングメディアプレーヤを実行する標準のウェブブラウザを使用して、インターネット上の任意の場所又は企業ファイアウォールの後ろから会議キャストに参加する。本明細書に示した会議プラットフォームは、任意のウェブアプリケーションに容易に組み込むことができるサービスの迅速な開発を可能にする。図２で分かるように、プラットフォーム２００は、ウェブ予約サブシステム２０２、ボイスサーバサブシステム２０４、コンテンツ記憶サブシステム２０６、データ監視サブシステム２０８、参加者アクセスサブシステム２１０、アーカイブサブシステム２１２等の多くのサブシステムを提供し、及び／又はこれらのサブシステムとのインタフェースを提供する。一般に、各サブシステムは、コンピュータソフトウェア或いはコンピュータハードウェア上で実行されるソフトウェアの組み合わせとして実現される。ウェブ予約サブシステム２０２は、一般に好ましくはＨＴＴＰＳやＶＰＮ等のセキュアリンク２１４を介してウェブ予約サブシステム２０２に接続することによって、エンティティがイベント予約を行なうことを可能にする機構を提供する。ウェブ予約サブシステム２０２は、一般に、予約データを管理し更新するためのデータベース２０３及び関連したデータベース管理システム２０５（例えば、Ｏｒａｃｌｅ、ＩＢＭ ＤＢ／２等）を含む。ボイスサーバサブシステム２０４は、ユーザを確認し、入ってくる電話信号（即ち、会議通話）を出力データストリームに変換する。参加者アクセスサブシステム２１０は、参加者の要求に応じて、会議キャストへの参加の仕方を参加者のストリーミングメディアプレーヤに指示する情報（例えば、ストリームメタファイル等のデータ構造）を返す。コンテンツ記憶サブシステム２０８は、イベント情報を管理するために使用され、アーカイブサブシステム２１２の管理下でイベントファイルをアーカイブする。データ監視サブシステムは、ネットワーク全体に分散された装置上で実行されるソフトウェアにおいて実現された監視エージェントを含むことが好ましい。後で説明するように、各ボイスサーバサブシステム（複数のでもよい）は、後で更に詳しく説明するように１組のボイスサーバを有する。監視エージェントは、ボイスサーバサブシステム内のサーバからデータを収集し、詳細には、どのストリームがアクティブでどのポート又はパブリッシングポイントでアクティブかについてのデータを収集する。

エンティティは、一般に、単なる例として、ｈｔｔｐｓ：／／ｗｅｂ．ｓｅｒｖｉｃｅｂｕｒｅａｕ．ｎｅｔ／ｍａｋｅ＿ｒｅｓｅｒｖａｔｉｏｎ．ｊｓｐと示された所定のＵＲＬをウェブブラウザで開くことによってウェブ予約サブシステム２０２にアクセスする。ウェブ予約サブシステム、参加者アクセスサブシステム、及びアーカイブサブシステムは、ミラーサイトで入手可能であることが好ましい。そのようなケースでは、エンティティを（例えば、負荷、ネットワークトラフィック、及び／又は待ち時間に関して）最適に位置づけられたサブシステムに導くために、トラフィックマネージャ２１６が使用される。トラフィック管理製品及びサービスは、当技術分野において既知である。例示のシステムは、ＦｉｒｓｔＰｏｉｎｔＴＭという商品で知られており、マサチューセッツ州ケンブリッジのＡｋａｍａｉ Ｔｅｃｈｎｏｌｏｇｉｅｓから入手可能である。ＦｉｒｓｔＰｏｉｎｔの技術は、２００１年５月２９日に出願され「Ｇｌｏｂａｌ Ｌｏａｄ Ｂａｌａｎｃｉｎｇ Ａｃｒｏｓｓ Ｍｉｒｒｏｒｅｄ Ｄａｔａ Ｃｅｎｔｅｒｓ」と題する本出願人が所有する同時係属出願番号０９／８６６，８９７号に記載されている。その他の市販のグローバルルーティング製品には、Ｃｉｓｃｏ Ｇｌｏｂａｌ Ｄｉｒｅｃｔｏｒ、Ｆ５によるグローバルロードバランサ（ｇｌｏｂａｌ ｌｏａｄ ｂａｌａｎｃｅｒｓ）等がある。本発明において、エンティティをミラーサブシステムに接続するために、ネットワークのトラフィック状態やサーバ負荷等に基づいて１組のミラーサイトのうちの１つのミラーサイトにクライアント要求を導く能力を有する任意の製品／システム／管理サービスを使用することができる。

一般的に、プラットフォーム２００は、通常、１組のコンピュータである。代表的な装置は、コモディティ（例えば、Ｐｅｎｔｉｕｍクラス）ハードウェア、オペレーティングシステム（例えば、Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓ ２０００等）、アプリケーション実行時環境（例えば、Ｊａｖａ）、ウェブサーバ（例えば、Ａｐａｃｈｅ）、及び所定のサブシステムの機能を提供する１組のプロセス（例えば、Ｊａｖａサーブレット、リンク可能ライブラリ等）を実行するサーバである。従って、例えば、ウェブ予約サブシステム２０２は、エンティティに記入フォームを提示し、エンティティが入力したデータを受け取り、インターネット会議キャストイベントのイベント予約を作成するＪａｖａサーブレットとして実施される。ウェブ予約データは、データベース管理システム２０５の管理下でデータベース２０３に記憶される。

図３は、好ましくはオンラインでウェブブラウザを介して、予約エンティティ（「予約受付係」）に提示される予約記入フォーム３００を示す。フォーム３００は、ストリーミングメディアフォーマット３０２（例えば、Ｒｅａｌ、Ｗｉｎｄｏｗｓ Ｍｅｄｉａ、Ｑｕｉｃｋｔｉｍｅ）とセキュリティレベル３０４を識別し、オンデマンド可用性の指定３０６を提供するようにエンティティを案内する。後者の情報は、イベントをアーカイブすべき期間を識別するリストボックスから選択される。エンティティは、おそらく自動化された方法でフォームに書き込む。予約サブシステム（例えば、サーブレット）は、固有イベントＩＤ、アクセスコード又はＰＩＮ（個人識別番号）、及び参加者ウェブサイトアドレス（「参加者ＵＲＬ」）を生成し、この情報は、データファイル３０８に記憶される。データファイルは、ＸＭＬフォーマットであり、例えばｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌ等の適切な識別名を有する。ｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌデータファイルは、イベント名、フォーマット、時間、イベントＩＤ、ＰＩＮ、参加者ＵＲＬ、状況（例えば、予約済み、完了等）を含むがこれらに限定されない所定の情報を含むことが好ましい。前述のように、ＰＩＮは、会議を開始（又は、再開）するために会議主催者によって使用されるアクセスコードである。一般に、会議主催者は、サービスビューロの従業員、会議を運営する人、或いはより一般的には、任意の他の人、プロセス、又は自動化されたルーチンである。

代表的な実施形態では、ウェブ予約サブシステム２０２は、各イベント予約ごとにプロセス（例えば、サーブレット）をインスタンス化する。このサーブレットは、ｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌファイルを生成し、イベントを要求しているエンティティに所定の情報を返す。詳細には、サーブレットは、エンティティに、イベントＩＤ、主催者アクセスコード又はＰＩＮ、及び参加者ＵＲＬを含むデータファイルを返すことが好ましい。その後で、エンティティは、例えば電子メールを送るか、識別可能な場所に参加者ＵＲＬを公表するか、通知を行う他のウェブサイトに情報を配信することによって、それぞれの見込み参加者に参加者ＵＲＬを転送する。代表的な参加者ＵＲＬは、単なる例示として、次のようなフォーマットである。
ｈｔｔｐｓ：／／ｗｅｂ．ｓｅｒｖｉｃｅｂｕｒｅａｕ．ｎｅｔ／ｍｅｔａ？ｅｖｅｎｔ＝＜イベントＩＤ＞＆フォーマット＝＜名前＞

これから分かるように、参加者ＵＲＬは、コンテンツ記憶サブシステムが利用不可能な場合でも（後で説明するように）、参加者がイベントに参加できるようにするイベントに関する十分な情報が埋め込まれていることが好ましい。後で説明するように、参加者（即ち、イベントに参加したいエンティティ）がこのＵＲＬを活性化したとき、参加者のストリーミングメディアプレーヤは、参加者アクセスサブシステム２１０によって生成された所定のＵＲＬに導かれる。サーブレットは、データファイルを予約エンティティに転送する他に、ｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌファイルをコンテンツ記憶サブシステム２０４とデータベース管理システム２０５に転送する。ｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌデータファイルは、イベント名、フォーマット、時間、イベントＩＤ、ＰＩＮ、参加者ＵＲＬ、及び状況（例えば、予約済み、完了等）を含むがこれらに限定されない所定の情報を含むことが好ましい。また、コンテンツ記憶サブシステム２０４はミラー化されることが好ましく、そのケースでは、どのコンテンツ記憶サブシステムが要求を処理するかを決定するために、トラフィックマネージャ２１６が再度使用される。コンテンツ記憶サブシステム２０４でｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌファイルを受け取ったとき、サブシステムは、イベントＩＤによって指定されたディレクトリを提供する。ｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌファイルとイベントアーカイブファイル（後で示す）は、＜イベントＩＤ＞ディレクトリに記憶される。コンテンツ記憶サブシステムにおけるこのディレクトリの設定は、イベント予約時に必要とされる唯一のソース割り振りである。

このシステムの大きな技術的利点は、物理リソースを事前に提供する必要がなく、予約プロセス自体の間ではなくユーザの参加時に実質的に全てのリソースがイベントに結合されることである。これらの物理リソースは、後で説明するように、ボイスサーバサブシステムをホストするデータセンター、サブシステム内のボイスサーバ、所定のボイスサーバ上で実行されるエンコーダ等を含む。詳細には、従来技術と違って、本発明のシステムは、物理リソースを前もって予約する必要がない。イベントを予約し、そのすぐ後で実行することができ（参加者ＵＲＬが配布されている場合）、物理リソースは全て、オンデマンドで「ジャストインタイム（ＪＩＴ）」で割り振られる。従来技術と異なり、予約をするエンティティ（例えば、人、自動プロセス等）は、予定時間が過ぎていない限りイベントを予約することができる。イベントの「予定」時間は強制されず、むしろ単に目安として使用されることが好ましい。更に、イベントがどれだけ「遅れて」行われるかに関する制限はないことが好ましい。

ボイスサーバサブシステム２０６は、複数のデータセンターの場所からアクセス可能であることが好ましい。本発明の技術的利点によれば、電話信号の取得は、システムが所定のイベントに対するリソースを事前に提供する必要がないという点で「自動」的に行われる。代表的な実施形態において、音声信号の取得は、任意の数の周知の機構によって達成される。従って、例えば、高度なルーティング機能を有する８００番システムを使用して、１組の地理的に分散されたデータセンターのうちの１つに通話をルーティングすることができる。そのようなルーティング機能は、当技術分野において知られている。そのような場合、システム内の全てのボイスサーバサブシステムと全てのボイスサーバに単一の「８００」番台の電話番号が使用される。代替として、サンディエゴにあるデータセンター（及び関連するボイスサーバサブシステム）には１−８５８−ｘｘｘ−ｙｙｙｙ番、フィラデルフィアにあるデータセンター（及び関連するボイスサーバサブシステム）には１−４０８−ｘｘｘ−ｙｙｙｙ番等、各ボイスサーバサブシステムごとに１つの専用電話番号を使用することもできる。後者のケースにおいて、単一の電話番号は、特定のボイスサーバサブシステムのデータセンターの場所にある全てのボイスサーバを表す。通話の会議ブリッジを提供したいシステムでは、二以上の個別の電話番号が有効であり、複数の関係者が関与できる。従って、ブリッジされた会議通話が、２つのボイスサーバサブシステムで処理され、これにより会議に複数の（即ち、冗長な）ストリームが作成される。これは、後で分かるように、アーカイブプロセスにおいて有利な場合が多い。

一般に、データセンターは、自然災害を防ぐために地理的に散らばっていることが好ましく、各データセンターは、ボイスサーバサブシステム２０６のホストとして働く。図４に示したように、代表的なボイスサーバサブシステム４００は、前置電話交換機４０４（例えば、ＡＴ＆Ｔ ５ＥＳＳ、Ｎｏｒｔｅｌ ＤＭＳ １００等）に接続された１台以上のボイスサーバ群４０２ａ〜ｎを含む。トランク４０６は、交換機４０４に接続されており、各ボイスサーバ４０２は、ＩＳＤＮ一次群インタフェース（ＰＲＩ）線４０８等の接続を介して交換機に接続されている。各ＩＳＤＮ ＰＲＩ線４０８（及び、従って、各ボイスサーバ）は、代表的な実施形態において最大２３の通話を処理する。データセンターは、個別のネットワークサービス提供者の停電に備えて、異なるネットワークサービス提供者を使用することが好ましい。データセンターが使用できないときは、自動ルーティング機能（ＡＲＦ：Automatic Routing Feature）によって、到来した通話が使用可能なデータセンターに自動的に転送される。データセンターは、正当と認められた加入者によって生成された任意の音声通話を処理することができる。前述のように、データセンターは、イベントの昔の知識を持つ必要はない。

図５は、代表的なボイスサーバ５００を示す。前述のように、各データセンターには複数のボイスサーバがあることが好ましい。ボイスサーバは、Ｗｉｎｄｏｗｓ ２０００やＬｉｎｕｘ等のオペレーティングシステム５０４を実行するコモディティハードウェア５０２を含む。ユーザから来た音声信号をサーバに接続するために、Ｉｎｔｅｌ ＤｉａｌｏｇｉｃＤＣＢ／ＳＣシリーズのカード、Ｉｎｔｅｌ Ｄｉａｌｏｇｉｃ ＤＭ／Ｖ−Ａシリーズのカード、又はその相当品等のインターネット音声会議カード５０６が使用される。１つ以上のエンコーダ５０８ａ〜ｎが、フォーマット固有のエンコーディングを提供する。従って、代表的なサーバには、Ｒｅａｌエンコーダ、Ｗｉｎｄｏｗｓ Ｍｅｄｉａ Ｓｅｒｖｅｒ （ＷＭＳ）エンコーダ等を含む。通常、エンコーダは、コンピュータソフトウェア、即ち一連のコード命令として実施される。エンコーダプロセスは、キャストされるインバウンドコールごとにインスタンス化されることが好ましい。所定の条件、例えばユーザが電話を切ろうとしているか３９９等の所定のキーパッドコードを入力したときに、エンコーダがディスエーブル（即ち、停止）され、イベントがアーカイブされる。更に、サーバ５００は、後で説明する目的のためにプラットフォーム上で実行可能な１以上のアプリケーションを含む。そのようなアプリケーションには、ボイスサーバ電話エンジン（ＶＳＴＥ）５１０とボイスサーバネットワークマネージャ（ＶＳＮＭ）５１２がある。これらのモジュールは、個別でもよく、組み合わせてもよい。ＶＳＴＥ５１０は、通話制御と信号伝達を処理し（例えば、規格Ｑ．９３１に従って）、会議カード５０６ファームウェアに対するインタフェースを提供し、イベントＩＤとＰＩＮを要求するボイス応答ファイルを再生し、ユーザの電話キーパッドからのデュアルトーンマルチフリケンシ（ＤＴＭＦ）応答をデコードし、ディジタル音声ファイルを記録し、後で説明するようなデータ監視テーブルを発行し、イベントログを生成することを含む多数の機能を実行する。

図６は、通話を開始するときのボイスサーバの動作の簡略化したフローチャートである。詳細には、ウェブベース予約サブシステムを使用してイベントを予約し、着呼がデータセンター内の所定のボイスサーバに導かれたと仮定する。段階６００で、ＶＳＴＥは、着呼に応答するように会議カードに指示する。段階６０２で、ＶＳＴＥは、ユーザにイベントＩＤとＰＩＮを入力することを要求するボイスプロンプトを出す。その情報を認証するために、ＶＳＴＭは制御をＶＳＮＭに移す。ＶＳＮＭは、段階６０４で、イベントのｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌをフェッチするために例えばＨＴＴＰによってコンテンツ記憶サブシステムに要求を出す。段階６０６で、ｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌファイルがＶＳＴＥに返される。次に、ルーチンは、段階６０８に進み、ＶＳＴＥは、例えば、イベントがまだ終了していないことを確認するために状態フラッグを評価し、ｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌファイル内の返されたＰＩＮが、ボイスプロンプトに応じてユーザがＤＴＭＦを介して入力したＰＩＮと一致していることを検証することによって、イベント情報を認証する。イベント情報が認証された場合、ＶＳＴＥは、次に段階６１０に進んで、（フォーマットフラッグで識別された）適切なエンコーダをインスタンス化し、イベントの音声ストリームを開始する。これでプロセスが完了する。

本発明の技術的利点によれば、音声キャスティングは、ＶＳＴＥが、コンテンツ記憶サブシステムへの接続を確立できるかどうかに関係なく及び／又はｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌファイル内の所定の情報を受け取るか認証できるかどうかに関係なく始まる。詳細には、ＰＩＮ自体は、自己検査しており、ｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌファイル内のＰＩＮが何らかの理由で使用できない場合はＶＳＴＥが「その場で」再生できることが好ましい。これを達成する好都合な方法は、ＰＩＮ（第１のインスタンス内）をイベントＩＤ（又は他の識別名）と共有キー（ｓｈａｒｅｄ ｓｅｃｒｅｔ）の一方向ハッシュ（ｏｎｅ−ｗａｙ ｈａｓｈ）として生成することである。ＶＳＴＥが共有キーを知っているか又は取得できる限り、ＰＩＮを再生し、それを（例えば、ＤＴＭＦを介して）ユーザが入力したコードと比較することができる。従って、ｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌがサーバ内のＶＳＴＥに使用できない場合にイベントが遅れなく開始される。

周知のように、ストリーミングメディアの配信は、ストリームが所定の名前を有する必要がある。通常、ストリーム名は、ストリームを出力するリソースに対応する。従来、リソースは、通常、「ポート」又は「パブリッシングポイント」であり、ストリームは、何らかの固有名称と関連付けられているだけである。代表的な実施形態では、ボイスサーバがポート上にストリームを出力すると仮定する。しかしながら、これは本発明を限定するものではない。この実施形態での別の技術的利点は、データセンター内の各ボイスサーバにポートを割り振るか「事前に割り当てる」ことによって提供される。従って、例えば、データセンター内の第１のサーバは、ポート１０，０００〜１０，０４９を割り振られ、第２のサーバはポート１０，０５０〜１０，０９９を割り振られ、以下同様に割り振られる。ポートは、データセンター内のボイスサーバのセットアップ中に割り振られることが好ましい。前述のポート番号は単に代表的なものである。各ボイスサーバのポートを事前に割り振ることによって、データベースルックアップを実行してポート番号を得るためにストリームを提供する特定のサーバが不要になる。その結果、この操作に必要とされる通常の処理遅延が回避される。また、パブリッシングポイント、固有名称又は他の配信技術がサーバストリームに適用される場合にも事前割り振りを使用することができる。例示のために、ポートを利用したソリューションを以下に述べる。

現在、事前に割り当てられたポートの１つにイベントがストリーミングされていると仮定する。図７は、視聴会員（「参加者」）が音声キャストに参加する方法を示すフローチャートである。図８は、この操作を実施するために使用される様々なプロセスを示す。段階７００で、参加者は、（リンクをクリックするか入力することによって）次の形式の参加者ＵＲＬを活性化する。
ｈｔｔｐｓ：／／ｗｅｂ．ｓｅｒｖｉｃｅｂｕｒｅａｕ．ｎｅｔ／ｍｅｔａ？ｅｖｅｎｔ＝＜イベントＩＤ＞＆フォーマット＝＜名前＞

段階７０２で、参加者のブラウザは、前述のようにトラフィックマネージャプロダクト、システム、又は管理されたサービスを使用して（複数が稼働している場合）所定の参加者アクセスサブシステムに導かれる。次に図７と図８を参照すると、参加者アクセスサブシステムで実行されているメタファイルジェネレータ８００が、クライアント要求を受け取り、それに応じて、データ監視サブシステム８０２にポート識別要求を出す。メタファイルジェネレータは、サーブレット、ライブラリ、又は他の好都合な機構として実施することができる。これは段階７０４であり、ポート識別要求は、一般に、イベントＩＤとフォーマットを識別する。その代わりに、データ監視サブシステムは、イベントをストリーミングしているポートの番号を返す。前述のように（ストリーミングにポートが使用される場合）、ボイスサーバは、ポート番号によって識別された所定のポートを介して所定の通話をストリーミングする。ボイスサーバがエンコーダインスタンスを開始するたびに、ボイスサーバは、ポートから出力されているストリームに、例えば｛イベントＩＤ，フォーマット，ポート番号｝などのデータセットを生成することが好ましい。前述のように、ある環境（例えば、ブリッジされた会議や、イベントに複数のデータセンターが連動している場合）では、冗長通話が生じ、その場合は、別のボイスサーバが、同じイベントＩＤとフォーマットを有するが異なるポート番号を有する別のデータセットを生成する（全てのポート番号が事前に割り振られておりかつ固有であるため）。各データセットは、データ監視サブシステム８０２に連続的にプッシュされ、データ監視サブシステム８０２は、アクティブなイベントを識別するテーブル８０４をボイスサーバに発行する。従って、段階７０６で、データ監視サブシステム８０２は、メタファイルジェネレータ８００に、ボイスサーバからストリーム（イベントＩＤとフォーマットで定義されたような）を配信しているポート（又は、パブリッシングポイント）の識別名を返す。次に、ルーチンは段階７０８に進み、メタファイルジェネレータ８００はメタファイル８０６を生成する。メタファイル８０６は、参加者のストリーミングメディアプレーヤがストリームを利用できる１つ以上のストリームユニフォームリソースロケータを含むデータ構造である。イベントＩＤとフォーマットの対ごとに１つのＵＲＬがあることが好ましい。ＵＲＬは、参加者のストリーミングメディアプレーヤがコンテンツを取得できるようにするために必要な適切なストリームフォーマットと他のデータを備える。このＵＲＬは、参加者ＵＲＬと区別するために「ストリームＵＲＬ」と呼ばれることがある。従って、例えば、代表的なストリームＵＲＬは、次のようなフォーマットである（ＷＭＳストリームは「ｒｅｆｌｅｃｔｏｒ」とポート３０１２と名付けられた配信ネットワークで入手可能であると仮定する）。
ｍｍｓ：／／．．．ｓｔｒｅａｍ．ｎｅｔ／＜ｃｐｃｏｄｅ＞／
＜ｉｎｔｅｇｒｉｔｙｃｈｅｃｋｄａｔａ＞／ｒｅｆｌｅｃｔｏｒ：３０１２

冗長ストリームがある場合、メタファイル８０６は、例えばストリームが他のストリームＵＲＬから入手きない場合のフェイルオーバーとして、ストリームを得ることができる第２のストリームＵＲＬを含む。メタファイルは、イベントの現在の状態に基づいて動的に生成されることが分かる。また、このシステムは、ユーザが、静的及び／又は動的なＸＳＬファイルによってメタファイルをカスタマイズできるようにすることが好ましい。段階７１０で、メタファイルジェネレータ８００は、メタファイル８０６を参加者のウェブブラウザに返す。段階７１２で、参加者のウェブブラウザのメディアプレーヤは、ストリームＵＲＬを開いてストリームを自動的に取得する。接続を確立できた場合、参加者は会議に参加する。

参加者のブラウザにストリームＵＲＬを返す前に参加者を認証することが望ましい 場合がある（必須ではない）。これは、以下のように達成することができる。システムが、特定のイベントの参加者ＵＲＬを生成するとき、このＵＲＬには、主催者又は参加者のパスワードが埋め込まれることが好ましい。この結果、システムは、ルックアップを行うことなく正しいパスワードが提供されたかどうかを判定することができる。代表的なＵＲＬは、以下の通りである。
＜ＵＲＬの署名なし部分＞＆．．．＆＜ＵＲＬの署名付き部分＞＆．．．＆＜署名＞
ここで、
＜ＵＲＬの署名なし部分＞＝所定の情報
＜ＵＲＬの署名付き部分＞＝．．．＆ｏｒｇ＿ｉｄｘｘｘ＆ｅｖｅｎｔ＿ｉｄ＝ｙｙｙ＆ｅｖｅｎｔ＿ｔｉｍｅ＝ｚｚｚ＆ＭＤ５（ａｔｔｅｎｄｅｅ／ｈｏｓｔ＿ｐｗ，ｏｒｇ＿ｉｄ）
＜署名＞＝ＭＤ５（＜ＵＲＬの署名付き部分＞，秘密キー）
ＵＲＬにｅｖｅｎｔ＿ｔｉｍｅ（及び場合によっては他の情報）が含まれている場合でも、この情報は、コンテンツ記憶サブシステム（及び、従って、ｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌファイル）が利用できない場合にイベントを容易にするためだけに使用されることに注意されたい。最新情報は、記憶サブシステムのイベント情報ファイル内にあることが好ましい。ＭＤ５ハッシュ値がＵＲＬの署名付き部分内の値と一致すると、参加者は会議に出席することが認証される。

当業者は、以上の説明から、本発明の会議システムが、ＪＩＴ（ジャストインタイム）予約の提供の他に完全自動化された電話信号取得及びストリーミングを提供することを理解されよう。このシステムは、ユーザが話し始めたらすぐに（ｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌファイル内の予約情報にアクセスできない場合でも）イベントを自動的に認証し、エンコーダを起動し、配信ネットワークにストリームを注入する。別の言い方をすると、ユーザは、会議システムに電話をかけ、イベントＩＤとＰＩＮを入力し、通話を開始するだけである。見込み参加者は電話信号（即ち、会議通話）を直ぐに利用することができ、予約後に提供された参加者ＵＲＬを活性化するだけで通話にアクセスすることができる。これ応じて、参加者のアクセスサブシステムは、参加者のストリーミングメディアプレーヤが自動的に導かれるストリームＵＲＬを含むメタファイルを（要求クライアントに）返す。

本発明の会議システムは、また、従来技術よりも優れたアーカイブ機能を提供する。前述のように、アーカイブサブシステムは異なるデータセンターの場所で動作することが好ましく、そのケースでは、特定のアーカイブサブシステムにはトラフィックマネージャを介して到達する。例示の実施形態では、アーカイブサブシステムは、アーカイブプロセス８０８を含む。アーカイブサブシステムがミラー化されているとき、このプロセスは、１つ以上の装置上で実行される。各イベントは、そのイベントが終了したときにアーカイブされることが好ましく、この終了は、直接的（ユーザが、３９９のような所定のコードを入力することによって）に示されることもあり、間接的（ユーザが通話を切断し、アーカイブタイムアウトが終了したとき）に示されることもある。後で説明するように、通話の接続の単なる終了は、イベントが実際に終了したことを反映するとは限らないが、好ましい実施形態では、通話の終了によって、ストリームを表すファイルのアップロード（ボイスサーバから所定のコンテンツ記憶サブシステムへの）が生成される。従って、一般に、所定のイベントが、複数のストリームと、従ってコンテンツ記憶サブシステムへの複数の関連したファイルのアップロードに捕捉される。本明細書で使用されるとき、アーカイブは、全体のイベント自体に対して行われることが好ましく、従って、一般に、イベントを表すアップロードファイルの処理（例えば、集合、部分置換等）を伴う。

分散型システムでは、一般に、幾つかのアーカイブプロセスが同時に実行される。１つのアーカイブプロセスが、所謂「リーダー（leader）」として選出されることが好ましい。このアーカイブプロセスは、データ監視サブシステムから必要な情報を取得し、ストリーム履歴情報を調べる。好都合な任意のリーダー選出プロトコルを使用することができる。従って、例えば、所定のアーカイブプロセスは、他の全てのアーカイブプロセスに加入リストを公表し、他のプロセスからのリストを聞く。次に、プロセスは、他のアーカイブプロセスから受け取ったリストを組み合せて、応答リストをＩＰアドレスで分類し、所定の期間（例えば、２０秒）応答のなかった装置を除去し、所定の装置をリーダーとして選出し、他の装置に通知することによって、リーダーを選出する。

図９は、好ましいアーカイブの動作を示すフローチャートである。ルーチンは、イベントが進行中であると仮定している。これは、１つ以上のボイスサーバがストリームを出力していることを意味する。段階９００で、イベントをストリーミングするとき、積極的にイベントをストリーミングしているボイスサーバのエンコーダは、ストリームをそのローカルディスクに書き込む。段階９０２で、ボイスサーバが処理している音声信号が中断されたかどうかが判定される。中断されていない場合は、ルーチンは繰り返される。しかしながら、ボイスサーバが処理している音声信号が中断された場合、プロセスは、段階９０４に進み、ＶＳＮＭは、コンテンツ記憶サブシステム上の＜イベントＩＤ＞ディレクトリにアップロード（好ましくはＦＴＰで）を行う。＜イベントＩＤ＞ディレクトリがミラー化されている場合は、トラフィックマネージャを使用してアップロードに最適なミラーサイトを選択することができる。しかしながら、ファイルアップロードは、イベントが終了したことを必ずしも意味しない。従って、段階９０８で、別のボイスサーバがイベントのストリームを出力しているかどうかを判定する検査を行なう。リーダーは、これをデータ監視サブシステムによって供給されるデータから判定することができ、このデータは、どのボイスサーバ（及び、どのポート）がイベントのストリームを出力しているかを識別する。別のボイスサーバが、イベントのストリームを出力している場合、ルーチンは段階９００に戻る。しかしながら、段階９０８の検査の結果が否定の場合は、段階９１０で、所定のタイムアウトが終了したかどうか或いは主催者が所定のコード（例えば、３９９）を入力したかどうかを判定する検査が行われる。そうでない場合は、ルーチンは段階９０８に循環する。タイムアウトが終了したか又はアクセスコードが入力された場合、イベントは終了したと見なされ、処理は、段階９１１に進んでアーカイブプロセスが始まる。詳細には、段階９１１で、アーカイブリーダープロセスは、ｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌを編集してイベントが終了したことを反映させ、イベントに関するデータを記録する。従って、例えば、アーカイブプロセスは、状態フラッグを変更し、ストリーム開始時間、ストリーム終了時間、ＦＴＰアップロード中にボイスサーバから提供された固有ファイル名等を識別する。段階９１２で、アーカイブリーダーは、イベントと関連したストリームを処理してアーカイブを生成する。段階９１４で、アーカイブは、ｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌディレクトリに記憶される。段階９１６で、アーカイブは、任意のミラーに複写される。段階９１６は、必須ではない。これにより、自動化されたアーカイブ操作が完了する。この操作が完了した後で、エンドユーザは、自分のブラウザでシステムを開き、予約において最初に指定した期間のイベントのアーカイブを取得することができる。アーカイブは、前に示したように、アーカイブを望むエンドユーザにそのユーザのブラウザで参加者ＵＲＬを開かせてメタファイル（及び、埋め込まれたストリームＵＲＬ）を得ることにより取得されることが好ましい。

次に、段階９１２のストリームの処理について説明する。前述のように、イベント中に複数のストリームが生成される状況は幾つかある。１つのケースにおいて、主催者は、（異なる２つの電話番号で）２つの異なるデータセンターに電話し、冗長のために（２つの異なるボイスサーバから）複数のストリームを開始する。ブリッジされた会議通話が、２つのボイスサーバから複数のストリームを作り出す可能性もある。別の一般的なシナリオでは、ユーザが、会議を早く終了しすぎるか或いは間違って終了する（例えば、通話を切断することによって）。その後で、同じイベントＩＤとＰＩＮ（及び、従って同じｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌ）の別のエンコーダによって、異なるストリームで通話が再開される。そのような全ての状況で、アーカイブサブシステムには、イベント全体のアーカイブバージョンを構成できることが望ましい。幾つかのケース（例えば、単一の通話が欠落した場合）では、これは、（おそらく異なるデータセンターからの）複数のストリームを連結することを必要とする。他のケース（例えば、複数のストリームがある場合）では、品質等を考慮して、通話のある部分についてのストリームの一部分と別のストリームの一部分を使用することが望ましいことがある。従って、本発明によれば、段階９１２で、アーカイブリーダーがストリームを処理するとき、この処理は、一般に、各ストリームの再生すべき部分とアーカイブを作成する順序を識別する所定のメタデータの生成を含む。このメタデータは、段階９１４で、ｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌファイルに記憶される。ボイスサーバからアップロードされた生データは、無修正で記憶され、メタデータは、アーカイブの再生中に使用されることが好ましい。その意味で、ｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌファイルは、「仮想」アーカイブを記憶する。従って、例えば、特定の通話のメタデータは、エンドユーザのメディアプレーヤに指示して「時間ｘで始まり時間ｙで終わる」ストリーム１を再生させ、次にストリーム２を再生させ、以下同じように再生させることができる。情報「時間ｘで始まり時間ｙで終わる」が、メタデータである。

一般に、アーカイブリーダープロセスに提供される所定のイベントに複数のストリーム（各ストリームがイベント断片を表す）があるケースは多い。単純なケースでは、アーカイブリーダープロセスは、ストリームの開始時間と終了時間を分析し、適切な場合にアーカイブを要求するストリーミングメディアプレーヤに指示してストリームを単に連結させる。ストリームが、異なるボイスサーバから来ているが時間的に重なっている場合、アーカイブリーダーは、適切なストリーム断片を識別し、関連したメタデータをｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌファイルに記憶して、要求ストリーミングメディアプレーヤで複数のストリームをどのように再生するかを制御する。

本発明のアーカイブプロセスは、完全に自動化された方式で行われることが好ましい。詳細には、各イベントは、ユーザが通話を切断したときと、アーカイブタイムアウトが終了したとき、又は例えばユーザが所定のコードを入力することによってイベントが終了したときに、アーカイブされることが好ましい。同時に幾つかのアーカイブプロセスが実行されてもよく、一般に、リーダーとして１つのアーカイブプロセスが選出される。アーカイブプロセスは、データ監視サブシステムから必要な情報を取得し、ストリーム履歴情報を調べる。全ての通話からの全てのエンコードされたファイルがコンテンツ記憶サブシステム内にあると仮定する（前述のように、このファイルはボイスサーバによってコンテンツ記憶サブシステムに入れられる）。アーカイブリーダー（存在する場合）は、１つ以上のそのようなファイルが受け入れ可能なアーカイブを作成するかどうかを決定する。前述のように、受け入れ可能なアーカイブがある場合、アーカイブプロセスは、コンテンツ記憶サブシステムに入れられたファイルの適切なファイル名の順序付きリストを作成し、そのリストをそのイベントのｅｖｅｎｔ＿ｉｎｆｏ．ｘｍｌファイルに書き込む。やはり前述のように、このリストは、各ストリームの再生すべき部分とイベントの最適なアーカイブを作成する順序に関するメタデータを含む。受け入れ可能なアーカイブを決定できない場合、アーカイブプロセスは、エラーフラッグを設定しイベントの監視を中止する。後でこのエラーフラッグが解除された場合、アーカイブプロセスは、イベントをアーカイブすることを再試行する。

好ましい実施形態において、会議通話は、配信ネットワークを介してストリーミングされる。周知のように、コンテンツ配信ネットワークは、要求クライアントを過負荷でなくかつコンテンツへのアクセスを提供する可能性の高い、最適で、エッジベースである場合が多いコンテンツサーバにルーティングすることによって高度なコンテンツ配信ネットワークを提供する。代表的なストリーミングメディアコンテンツ配信ネットワークは、マサチューセッツ州ケンブリッジのＡｋａｍａｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ， Ｉｎｃ．から入手可能なＦｒｅｅＦｌｏｗ Ｓｔｒｅａｍｉｎｇである。この技術では、ストリームは、ネットワーク伝送経路の幾つかが機能停止したか損失が大きいときに所定のエッジサーバがストリームのクリーンコピーを構築することを可能にする複数の冗長経路に送られる。この「リフレクタ」伝送ネットワークは、２００１年１月３日に出願された「ＳＴＲＥＡＭＩＮＧ ＭＥＤＩＡ ＳＵＢＳＣＲＩＰＴＩＯＮ ＭＥＣＨＡＮＩＳＭ ＦＯＲ Ａ ＣＯＮＴＥＮＴ ＤＥＬＩＶＥＲＹ ＮＥＴＷＯＲＫ」と題する同時係属出願第０９／７５３，３９８号に記載されている。

図１０は、代表的なリフレクタネットワークである。この例において、ボイスサーバから出力されたストリームは、コンテンツ配信ネットワーク（ＣＤＮ）の入口点１２０２に送られる。入口点は、例えば、２つのサーバ（冗長用）を含み、各サーバは、複数のボイスサーバからの多数のストリームを処理することができる。入口点がストリームを受け取った後、入口点は、ストリームのコピーを、所謂セットリフレクタ１２０４ａ〜ｎに中継放送する。セットリフレクタは、サーバである。ストリームは多重化され、好ましくはＵＤＰ（例えば、ＩＰを介してＵＤＰにカプセル化されたＲＴＳＰ内にカプセル化されたＷＭＴ）を介してセットリフレクタに配信される。これらのセットリフレクタは、耐故障性を確実にするために、ネットワーク及び地理的な視点で異なる（例えば、種々のインターネットバックボーンデータセンターにある）ことが好ましい。各セットリフレクタは、次に、ストリームのコピーを、１組の加入領域（subscribing region）１２０６ａ〜ｎの各加入領域、例えば領域１２０６ｄに中継放送する。加入領域１２０６ｄは、ユーザがＣＤＮ要求ルーティング機構によってルーティングされた１つ以上のストリームエッジノード１２０８ａ〜ｎを含むＣＤＮ領域である。換言すると、セットリフレクタは、ストリームをそれが必要とされる全てのエッジ領域に送る。この例において、ＣＤＮ領域は、共通バックボーン１２０９、例えばローカルエリアネットワーク（ＬＡＮ）によって接続された１組のエッジノードを含む。一般に、エッジノード、例えばノード１２０８ｄは、ストリーミングサーバ１２１２を含み、キャッシュ１２１０を含むことがある。代表的なサーバは、Ｉｎｔｅｌプロセッサ、Ｌｉｎｕｘオペレーティングシステム、並びにＲｅａｌ Ｍｅｄｉａ又はＱｕｉｃｋＴｉｍｅ Ｓｅｒｖｅｒを実行する。Ｗｉｎｄｏｗｓベースのプラットフォームの場合、代表的なサーバは、Ｉｎｔｅｌプロセッサ、Ｗｉｎｄｏｗｓ ＮＴ又は２０００、及びＷｉｎｄｏｗｓ Ｍｅｄｉａ Ｓｅｒｖｅｒを実行する。また、エッジノードは、所定のエッジサーバが所定のストリームを申し込むことを可能にする制御プログラム１２１４を実行することができ、これは、会議参加者のストリーミングメディアプレーヤがそのエッジサーバに導かれたときに行われる。ストリームＵＲＬを所定の参加者に最適なエッジサーバに決定する例示の要求ルーティング機構は、米国特許第６，１０８，７０３号に記載されている。

前述のコンテンツ配信ネットワークは、単なる例である。ストリームがこのタイプのリフレクタ配列によって配信されなければならないという必要はない。単純な実施形態において、ストリームは、従来のＷＭＳ（又は、Ｒｅａｌ、Ｑｕｉｃｋｔｉｍｅ、又は他のフォーマット）のパブリッシングポイントで出力され、任意のタイプのネットワーク接続（例えば、インターネット、企業イントラネット、専用ネットワーク、ＶＰＮ等）によって対応するＷＭＳ（又はＲｅａｌ、Ｑｕｉｃｋｔｉｍｅ、又は他のフォーマット）ストリーミングサーバに配信される。

本発明は、サービス提供者によって管理されたサービスとして実施されてもよく、独立システムとして使用可能にされてもよい。システムは、イベントを予約し、修正し、又は取り消し、或いは既存のイベントに関する情報を取得するために、第３者がセキュアリンク（ＨＴＴＰＳ等）によってメッセージ（好ましくはＸＭＬ）を送ることができるアプリケーションプログラミングインタフェース（ＡＰＩ）を含むことができる。また、システムは、ウェブベースのエクストラネットアプリケーションとして実現されるイベントマネージャツールを含むことができる。このツールによって、全ての在来の会議イベントを監視することができる。

以下は、ボイスサーバの好ましい実施形態のさらなる詳細である。ＶＳＴＥ５１０は、通話が進行しているネットワークスイッチとボイスサーバの間のＢチャネル可用性シグナリング（ＢＣＡＳ：B-Channel Availability Signaling）をサポートしていることが好ましい。ＢＣＡＳは、複数のボイスサーバにわたる負荷分散を可能にする追加の機能を提供し、使用可能なポートのプールが少ないときにチャネルを休止させ、保守のためにボイスサーバを一時停止させ、ＰＲＩシグナリング又は装置障害を監視する。詳細には、ＢＣＡＳは、サービス要求の開始と肯定応答を行って個々のチャネルを稼働、保守、及び休止の３つの状態のうちの１つの状態にする。

また、ＶＳＴＥ５１０は、所謂「ポート可用性サスペンド」機能を提供する。この機能は、ボイスサーバ上の使用可能なポートのプールが少ないときに使用可能な全てのチャネルをサービスから除去する。この機能は、イベントをストリーミングするためにエンコーダポートが利用できない可能性があるときに他の通話がボイスサーバにルーティングされるのを防ぐ。作動されたとき、通話を待っているチャネルはどれも休止される。各イベントが終了したとき、イベントを受け取ったチャネルは休止される。ポート可用性サスペンドは、ユーザが無許可のイベントにアクセスするのを防ぐために実施される。動作において、イベントストリームにアクセスする各ユーザは認証コードを受け取り、この認証コードは、認証コードタイムアウト期間中有効であることが好ましい。ユーザが終了に近いイベントにアクセスした場合、認証コードは、認証コードタイムアウト期間中有効になり、ユーザは、そのポートで別のイベントにアクセスすることができる。これは好ましくない。この理由のため、イベントをストリーミングするポートは、「ポート再使用タイムアウト期間」後まで再び使用されない。ポート再使用タイムアウトが、認証コードタイムアウト期間と同じか又はそれより長い場合、ユーザは、無許可のイベントにアクセスすることができない。ボイスサーバが、使用可能なポートのないポイントに近づくとき、そのボイスサーバは、ポート可用性サスペンドモードにされることが好ましい。この「低いポート可用性」状態が解消されたとき、チャネルは、「稼働」状態にされる。

また、ボイスサーバ５００は、保守のためにサスペンド状態にされることがある。この状態では、使用されていないチャネルは全て「休止状態」に維持される。使用中のチャネルは全て、イベントが完了した後で「休止状態」にされる。サスペンドされたボイスサーバ上のイベントが全て休止状態のとき、ＰＲＩサービス（会議カードに対する）はサスペンドされ、ネットワークスイッチとボイスサーバ間の通信が終了され、それにより、ネットワークスイッチは、データセンター内の他のボイスサーバに通話をルーティングすることができる。また、ＶＳＴＥは、ｄチャネル通信の障害とシグナリングエラーを検出することができる。

前述のように、各ボイスサーバは、１つ以上のＰＲＩ互換会議カードを含む。図示していないが、各ボイスサーバを通信事業サービス提供者から供給される交換機や他の終端装置にチャネルサービスユニット（ＣＳＵ）を介して又は直接接続することができる。各会議カードは、各ボイスサーバが独立の動作を維持することを可能にするそれ自体のｄチャネルを備えていることが好ましい。ＣＳＵが必要かどうかは、ネットワークスイッチ（５ＥＳＳ、ＤＭＳ１００等）の場所と、データセンターの主入口点にある終端装置に依存する。ネットワークスイッチが、ボイスサーバ装置と同じ場所にある場合は、ラック間にＴ１ケーブルを配線することができ、ＣＳＵは不要である。ネットワークスイッチが遠く離れた電話局（ＣＯ）にあり、サービス提供者が診断／ループバック機能を提供できるデータセンターで終端装置が使用可能な場合もＣＳＵは不要である。遠く離れて配置されたネットワークスイッチからデータセンターへの接続を検証する他の手段がないときに、ＣＳＵを使用できる。

ネットワークスイッチは、ボイスサーバ会議カードから送られたサービスメッセージを肯定応答する機能を提供することが好ましい。この機能は、ＡＴ＆Ｔ ５ＥＳＳ交換機では「Ｂチャネル可用性シグナリング」と呼ばれる。これと同じ機能は、ＤＭＳ−１００交換機では「リモートブロック」と呼ばれる。サービスメッセージシグナリングの動作は、次のようなものとなる。即ち、サービスメッセージによって、顧客終端装置（このケースでは、会議カード）は、個々の伝達（bearer）チャネルを休止させたり、稼働させたりすることができる。この機能は、ポート再使用、ボイスサーバサスペンド、及び負荷分散の機能を使用可能にする。会議カードは、サービスメッセージをｄチャネルでネットワークスイッチに送ってチャネルを稼働又は休止することを要求する。次に、スイッチはサービス要求を肯定応答しなければならない。要求が、特定のチャネルを休止することであった場合、ネットワークスイッチは、そのサービスメッセージを肯定応答し、次に任意の通話をそのチャネルにルーティングしなければならない。通話は、休止されていない第１の使用可能チャネルにルーティングされることが好ましい。会議カードの全てのチャネルが使用中又は休止中の場合、ネットワークスイッチは、次に使用可能なカードに通話をルーティングすることが好ましい。

要約すると、本発明のシステムは、物理リソースを事前に確保する必要がない。イベントを予約し次にいつでも実行することができ、物理リソースは全て、「ジャストインタイム」（ＪＩＴ）でオンデマンドでイベントに割り当てられることが好ましい。これにより、従来のシステムと比べて高いフレキシビリティとコスト低減が実現される。より具体的には、本発明のシステムは、音声リソースを事前に提供しない。より正確に言うと、ユーザの参加時に実質的に全ての音声リソースがイベントに結合される。これらのリソースは、データセンター、ボイスサーバ、及びエンコーダを含む。音声リソースのこの「ジャストインタイム」又はオンデマンドの割り振りによってシステムの耐障害性を高めることができる。信号取得前にどれかのリソース又はアセット（asset）に障害が起こると、使用可能なリソースのプールからその装置が除去される。これにより、システムは、使用可能なアセットの中から正常に機能する状態で選択することができる。これらのアセットの状態が適正であることを保証するために、システムは、リソースアセットの自動的な監視及び検査を実施する。ダイアルインにより、会議は、正常に機能している音声リソースだけを使用することになり、それにより耐障害性が最高になる。ユーザがログインし、ボイスサーバに接続した後、システムは、データベースに依存せずにイベントを実行する。システムのデータベースインタフェースは非同期的であることが好ましく、その結果、イベント予約の要求が出されたときにデータベースが使用できない場合に、要求に応じて予約が完了する。その後で、データベースは、予約情報によって更新される。

音声のアーカイブプロセスは、アーカイブをいつ作成し、聴衆がアーカイブをいつ使用でき、また途絶えた通話をどのように処理するかを操作するために使用される多くのフレキシビリティを提供する。前述のように、システムは、イベントが終了した後又はコールバック期間が終了した後でイベントを自動的にアーカイブする。イベントが終了したことが分かっているとき、又はイベント後システムが、ある一定の期間ライブストリームが生成されていないことを検出したときに、アーカイブが生成される。主催者は、ウェブインタフェース又はＤＴＭＦ（音声用）によって、イベントが終了したことをシステムに通知し、このケースでは、アーカイブが直ちに生成される。イベントがいつ終了しイベントをいつアーカイブすべきかを決定する別々のタイムアウトがある。イベントが終了したとき、そのイベントの通話はボイスサーバに受け入れられない。顧客が電話を切るか又は通話が途絶えた後アーカイブタイマが開始される。このタイマは、全てのイベントについて所定のデフォルトで設定されるか又は個別に設定できることが好ましい。タイマが終了した後で、ファイルは記憶装置にアップロードされる。システムのユーザは、指定されたＦＴＰディレクトリに会議イベントファイルをアップロードする。アップロード後に、コンテンツ記憶システムは、コンテンツを複製し、複数の各記憶センターにファイルのコピーを置くことが好ましい。

エンドユーザが、そのエンドユーザに最適であると決定されたストリーミングサーバにまだキャッシュされていないアーカイブイベントを要求したとき、サーバは、要求されたファイルのコピーを最適な記憶センターからフェッチする。これを達成する１つの技術は、２００２年４月１日に出願された「ＳＣＡＬＡＢＬＥ， ＨＩＧＨ ＰＥＲＦＯＲＭＡＮＣＥ ＡＮＤ ＨＩＧＨＬＹ ＡＶＡＩＬＡＢＬＥ ＤＩＳＴＲＩＢＵＴＥＤ ＳＴＯＲＡＧＥ ＳＹＳＴＥＭ ＦＯＲ ＩＮＴＥＲＮＥＴ ＣＯＮＴＥＮＴ」と題する同時係属出願第１０／１１３，１８３号に記載されている。次に、ストリーミングサーバは、ユーザの要求を満たし、またそのキャッシュにファイルのコピーを維持し、それにより、そのコンテンツの次の類似の要求を満たすことができる。

本発明は、双方向通信サービスのための総合的な機能群を提供し、拡張性と信頼性が最大になるように設計された分散型の標準的なソフトウェアアーキテクチャを提供する。このプラットフォームは、基本ストリーミングに必要な頑強なイベント提供、信号取得、監視、アーカイビング、報告、課金を可能にする。本発明の機能は、万能サイズ（one-size fits-all）のアプリケーションではなく、アプリケーションプラットフォームから利用可能である。サービス提供者は、ＡＰＩを使用することによって統合されカスタマイズされた製品を提供し、更に必要に応じて自分自身の技術を統合することができる。前述のように、本発明の大きな利点は、物理リソースを前もって確保する必要がないことである。イベントを予約しその後直ちに実行することができ、物理リソースは全て、「ジャストインタイム」でオンデマンドでイベントに割り振られる。システムに単一障害箇所がなく、自己回復する。即ち、単一の構成要素の障害によってイベントが停止することがなく、構成要素に障害が起きたときにシステムが自動的に補償する。更に、システムは、多数の同時イベントと大規模な総視聴者数を処理することができる。需要が大きくなったとき、システムを負荷に対応するように容易に拡張することができる。

主催者がインターネット音声会議の予約を行う方法を示す従来技術の会議キャスティングシステムの図である。 本発明の会議システムを構成する様々な機能のサブシステムを示すブロック図である。 会議イベント予約を作成するためにウェブ予約サブシステムによって使用される例示的な記入フォームである。 本発明の例示的ボイスサーバサブシステムのブロック図である。 例示的ボイスサーバのブロック図である。 会議通話を開始する際のボイスサーバの動作の簡略化したフローチャートである。 視聴会員が会議イベントに参加する方法を示すフローチャートである。 図７のフローチャートに示したように視聴会員が会議イベントに参加することを可能にするために使用される構成要素のブロック図である。 本発明による自動化されたアーカイブ機能を示すフローチャートである。 会議ストリームを配信するために使用することができる代表的なストリーム「リフレクタ」ネットワークの図である。

符号の説明

２００ プラットフォーム
２０２ ウェブ予約サブシステム
２０３ データベース
２０４ ボイスサーバサブシステム
２０５ データベース管理システム
２０６ コンテンツ記憶サブシステム
２０８ データ監視サブシステム
２１０ 参加者アクセスサブシステム
２１２ アーカイブサブシステム
２１６ トラフィックマネージャ

Claims (12)

1. コンピュータネットワークを介してウェブキャスティングするための装置であって、
   ウェブキャスティングされるイベントは話し手のスピーチをコンピュータネットワークを介して一人以上の視聴会員へキャスティングするウェブベースの音声会議イベントであり、
   コンピュータネットワークを介してアクセス可能であり、エンティティが、ウェブキャスティングされるイベントを予約し、イベント識別名、アクセスコード及び参加者ＵＲＬを取得し、ウェブキャスティングされるイベントと関連したイベント情報ファイルの記憶を開始することを可能にするコードを含む第１のサブシステムと、
   電話網に接続可能であり、エンティティが、イベント情報ファイルにアクセスすることなく、エンティティが入力したイベント識別名と、共有キーとの一方向ハッシュから導出する値がエンティティが入力したアクセスコードと一致することを検証することによってウェブキャスティングされるイベントを開始することを可能にするコードと、電話網を介して受信可能な話し手のスピーチから得られた音声信号からデータストリームを生成するコードとを含む第２のサブシステムと、
   コンピュータネットワークを介してアクセス可能であり、視聴会員である聞き手と関連したクライアントブラウザが参加者ＵＲＬを要求するのに応答して、ストリームＵＲＬを含むデータ構造をクライアントブラウザに返すコードを含む第３のサブシステムとより成り、
   ストリームＵＲＬがストリーミングメディアプレーヤによるデータストリームの取得を可能にすることにより、ウェブキャスティングされるイベント中に聞き手が視聴会員でない話し手のスピーチを聞くことができるウェブキャスティング装置。
2. 第２のサブシステムが、１台以上のサーバの組を含み、各サーバが、イベント識別名とアクセスコードを入力することをエンティティに要求する音声応答ファイルを再生する電話制御エンジンを含む、請求項１に記載のウェブキャスティング装置。
3. 電話制御エンジンが、ウェブキャスティングされるイベント中にサーバと関連した記憶ディスクにデータストリームを書き込む、請求項２に記載のウェブキャスティング装置。
4. 電話制御エンジンが、音声信号に所定の中断が発生した時に記憶ディスクからデータ記
   憶機構へデータストリームをアップロードする、請求項３に記載のウェブキャスティング装置。
5. コンピュータネットワークを介してアクセス可能であり、ウェブキャスティングされるイベントのディレクトリを生成するコードと、ディレクトリにイベント情報ファイルとアップロードされたデータストリームのコピーを記憶するコードとを含む第４のサブシステムを更に含む、請求項４に記載のウェブキャスティング装置。
6. コンピュータネットワークを介してアクセス可能であり、ウェブキャスティングされるイベントのアーカイブを作成しアーカイブをディレクトリに記憶するコードを含む第５のサブシステムを更に含み、参加者ＵＲＬはウェブキャスティングされるイベントの後アーカイブへアクセスするために有用である請求項４に記載のウェブキャスティング装置。
7. 会議システムによりコンピュータネットワークを介して会議をウェブキャスティングする方法であって、
   （ａ）会議システムがエンティティにイベント識別名、アクセスコード、及び参加者ＵＲＬを提供し、（ｂ）イベント情報ファイルを生成し、（ｃ）音声会議キャスティングイベントであるウェブキャスティングされるイベントと関連した、イベント情報ファイルを記憶するディレクトリを作成することによって、ウェブキャスティングされるイベントのエンティティによる予約を可能にする段階と、
   （ｄ）会議システムがエンティティが入力したイベント識別名と、共有キーとの一方向ハッシュから導出する値がエンティティが入力したアクセスコードと一致することを検証し、（ｅ）検証できたときに、話し手のスピーチデータをデータストリームにエンコードすることによって、ウェブキャスティングされるイベントを開始する段階と、
   （ｆ）会議システムが参加者ＵＲＬを開いたクライアントブラウザに、データストリームを取得することができるストリームＵＲＬを含むデータ構造を返すことによって、視聴会員である聞き手がデータストリームにアクセスするのを可能にすることにより、ウェブキャスティングされるイベント中に聞き手が視聴会員でない話し手のスピーチを聞くことができるようにする段階と、
   会議システムがウェブキャスティングされるイベントの終了時にアーカイブを生成する段階と、
   会議システムが、参加者ＵＲＬに対してクライアントブラウザを開くことにより、後でエンドユーザをアーカイブへアクセスさせる段階とを含むウェブキャスティングの方法。
8. 会議システムがウェブキャスティングされるイベントが進行するにつれてデータストリームのコピーを生成する段階と、
   会議システムがスピーチデータの所定の中断が発生した時にコピーを中央記憶機構に自動的にアップロードする段階とを更に含む、請求項７に記載のウェブキャスティングの方法。
9. ウェブキャスティングされるイベントにイベント識別名、アクセスコード及び参加者ＵＲＬを関連させることによってウェブキャスティングされる所定のイベントが予約された会議システムにより会議をウェブキャスティングする方法であって、
   （ａ）会議システムがエンティティが入力したイベント識別名と、共有キーとの一方向ハッシュから導出する値がエンティティが入力したアクセスコードと一致することを検証し、（ｂ）検証できたときに、話し手のスピーチから得られたスピーチデータをデータストリームにエンコードすることによって、ウェブキャスティングされるイベントを１つ以上の場所で開始させる段階と、
   （ｃ）会議システムが参加者ＵＲＬを開いたクライアントブラウザに、データストリームを取得することができる１以上のストリームＵＲＬを含むデータ構造を返すことによっ
   て、視聴会員である聞き手がデータストリームにアクセスするのを可能にし、ウェブキャスティングされるイベント中に聞き手が視聴会員でない話し手のスピーチを聞くことができるようにする段階と、
   会議システムが、ウェブキャスティングされるイベントが進行するにつれて、ローカルデータ記憶機構に各データストリームのコピーを記憶する段階と、
   会議システムが、スピーチデータの中断時に、記憶されたデータストリームのコピーを中央データ記憶機構に転送する段階と、
   会議システムが、ウェブキャスティングされるイベントの終了時に、アーカイブを自動的に生成する段階と、
   会議システムが、後で、エンドユーザが参加者ＵＲＬを用いてアーカイブへアクセスするのを可能にする段階とを含む、会議をウェブキャスティングする方法。
10. アーカイブを自動的に生成する段階が、
    データストリームのコピーを、イベント識別名と一意に関連付けられた中央記憶機構のディレクトリに記憶する段階を含む、請求項９に記載の会議をウェブキャスティングする方法。
11. 会議システムが、或る期間が経過した後でアーカイブに対するアクセスを制限する段階を更に含む、請求項９に記載の会議をウェブキャスティングする方法。
12. データストリームが、コンテンツ配信ネットワークを介してストリーミングされる、請求項９に記載の会議をウェブキャスティングする方法。

Images