JP2002532012A - 最適部品構成用のセッションアナウンスメント - Google Patents

Abstract

(57)【要約】 この発明はマルチキャスト可能な網上で行なわれるマルチメディア会議のようなメディアセッションの記述をアナウンスするための方法とシステムを与えるもので、例えばＭボーン（インターネットプロトコルマルチキャストバックボーン）として知られている通信網上で行なわれる。この発明はまたこのようなメディアセッションを受領するためのプラットホームを構成するための方法とシステムとを用意する。セッション記述をアナウンスする方法は次の段階で成る：メディアセッションの少くとも一つのメディア流を受領するためにユーザにとって必要とされるメディア指向データを含むセッション記述（１１１５）を生成すること、ここでメディア指向データはいくつかの応用プログラム成分（１１４５）か、いくつかの応用プログラムについての要件か、応用プログラム部品（１１４５）の構成かで該メディアセッションへの参加にとって必要なものを識別するものであるとし；またメディアセッションの潜在的な受領者（１１３５）によって入手可能なセッション記述を作ることによってメディアセッションをアナウンスすることという段階である。この発明を別な観点でとらえると、メディアセッションについてのプラットホームを構成する方法であり、それには次の段階が含まれている：前述の形式のセッション記述（１１１５）を受領することと、セッション記述を処理して適当な応用プログラム構成（１１５０）を入手可能な応用プログラムもしくはプログラム部品（１１４５）のリストから適切な応用プログラムを判断するようにすることと；前記メディアセッションへの参加について該リスト（１１４０）からのそれぞれのメディアセッション応用プログラム（１１５５）を構成することの段階である。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

この発明は通信網上でのメディアセッション（media session）のアナウンス
メント（告知、知らせ）と、メディアセッションを受領するための応用プログラ
ムと部品との最適な（適応性のある）構成とに関する。

【０００２】

【従来の技術】

マルチキャスト伝送（multicast transmission）はインターネット上で益々普
通のものとなってきている。標準のインターネットプロトコル（ＩＰ）点点間（
ポイントトゥポイント）伝送（すなわちユニキャスト，unicast）とは対照的に
、ＩＰマルチキャストは単一のソース（源）から一群の受領者に向けて情報を同
時伝送できる。ＩＰマルチキャスト伝送についてのルート設定支持（ルーテング
サポート）はMbone（Ｍボーン，IP Multicast Backbone）によって与えられ、こ
れはインターネットの上の仮想網（virtual network）レイヤとなっている。

【０００３】 ＩＰマルチキャストは広域ＩＰ網上で実時間（リアルタイム）通信を可能とし
、典型的な伝送はビデオとオーディオ会議（コンファレンス）、ライブ（生）の
マルチメディア学習訓練、大学講義、及びライブのテレビジョンプログラムの伝
送を含んでいる。

【０００４】 マルチキャスト伝送は、通常はマルチメディアセッションで構成され、このセ
ッションは一般にビデオ、オーディオ、ホワイトボード（白板）もしくは生のデ
ータを運んでいる数個の個別メディア流（ストリーム）で作られている。あるセ
ッションは永続性のあるものだが、大部分は特定の時間期間について存在し、連
続性は求められてはいない。Ｍボーン上でのマルチキャスト応用伝送はユニキャ
ストＩＰ伝送とは違っていて、伝送を受領するいずれのユーザも（伝送が暗号化
されている場合を除いて）セッションに加わることができて、伝送を受領し、ユ
ーザは適切な伝送アドレスとタイミング情報を知っている必要があるだけとなっ
ている。

【０００５】 マルチキャスト伝送の前には、適切なアナウンスメントでセッション記述（de
scription）を含むものが、通常はＩＰグループマルチキャストアドレスで作ら
れる。標準のセッション記述がセッションデスクリプションプロトコル（ＳＤＰ
）を用いて生成される。このプロトコルはInternet Engineering Task Force’s
draft RFC 2337によって規定されている。ＳＤＰは単純なＡＳＣＩＩテキスト
応用のプロトコルで実時間マルチメディアセッションとそれが関係するスケジュ
ール作成用情報とを記述するために使用される。ＳＤＰメッセージはキャリヤプ
ロトコルの中にラップ（包みこみ）され、これがセッションアナウンスメントプ
ロトコル（ＳＡＰ）として知られているところであり、インターネットもしくは
Ｍボーンをまたいでの伝送用に必要とされるＩＰアドレスとルート設定のための
情報を含んでいることに加えて、ＳＤＰメッセージが暗号化されたり、サインを
付されたり、あるいは圧縮されたりができるようにしている。そこで次にアナウ
ンスメントが定期的な間隔でアナウンスメントグループアドレスに向けて送るこ
とができる。ＳＡＰに代るものとしては、ＳＤＰメッセージをワールドワイドウ
エブサイト（ＷＷＷ）上におくことによるか、それを個人個人に向けてＥメール
で送るか、参加するように招くユニキャスト伝送として送るかすることによって
、セッションがアナウンスされるようにしてもよい。

【０００６】 ＳＤＰメッセージは、マルチキャストマルチメディアセッション内の各メディ
ア流についての情報を伝えて、受領者がセッションに関与できるようにする。一
般的なＳＤＰメッセージは、セッション名称と目的、セッションが活性となる時
間と日付、セッションの構成要素（部品）メディア流、及び情報で各メディア流
に参加するのに必要とされるもの（ＩＰマルチキャストアドレス、ポート、メデ
ィアフォーマット）を含んでいる。ＳＤＰメッセージはセッションの帯域幅要件
の詳細、公開キー暗号を用いる安全なマルチキャスト伝送に参加するために必要
とされる暗号キー、マルチキャストセッションのオーガナイザについてのコンタ
クト情報、及びＷＷＷもしくはインターネットウエブサイトを指定するＵＲＩ（
Unique Resource Indicator）を含むことができ、このサイトにはそのセッショ
ンでの別な情報、例えば会議に関する背景の情報が見付けられるようにできる。

【０００７】 ユーザがセッションもしくは流れ（ストリーム）の中でしてもよい参加のレベ
ルはその目的に依存する。マルチキャストテレビジョンセッションでは、一般に
、ユーザはセッション流を受領することだけが可能であり、またマルチキャスト
会議セッションでは、通信は中央サーバと双方向であり、（後出のグループ（群
）アドレス１２０のように）各参加者伝送を受けて他の参加者にそれを中継する
。セッションもしくは流れの中でユーザに期待されている参加のレベルはセッシ
ョン記述の中に明白に述べられるようにできるし、あるいはセッション記述から
当然とされる本来的なものであってよく、例えば、受領専用応用がセッション記
述内でメディア流形式と関係している場合がこれに当る。

【０００８】 マルチキャストの末端の（エンド）ユーザによって使用される普通のフロント
エンドインターフェースはセッションディレクトリィランデブー（ＳＤＲ）とし
て知られている。このインターフェースは受領したアナウンスメントを取りあげ
て、ＳＤＰメッセージをデコードし、リストの中に依然として現存するセッショ
ン名称を表示する。エンドユーザはそこでリストとされたアナウンスメントの一
つを選んで、アナウンスされたセッションの別な技術的かつユーザ指向の詳細を
眺めることができる。表示された情報から、エンドユーザはセッションの個々の
流れに加わるか、全体のセッションに加わるかを選択できる。参加することにな
る流れが選ばれると、ＳＤＲは必要とされるマルチキャストが可能とされたマル
チメディア応用をエンドユーザの計算機上で開始する。これはVic，Vat，あるい
はｗｂなどであり、関連の流れ情報（移送ポートアドレス）をアナウンスメント
から応用に送り、この応用が関係するＩＰマルチキャストアドレスと流れへの参
加に向けたリンクを伝送時に設定する。応用を開始して関連の移送ポートアドレ
スを送ると、ＳＤＲはこのセッションでは別の役割を演じない。

【０００９】

【発明が解決しようとする課題】 マルチメディアもしくはメディアセッションについての近年の増大した使用と
需要とはＳＤＰに多数の制限（限界）があることを明らかにした。ＳＤＰはセッ
ション記述がセッションの内部のすべての流れに応用するようなタイミングの単
一の組をもつようにセッションを定義することを制限している。伝送全体の中程
で流れが始まるセッションはＳＤＰを用いて簡単には記述できない。ＳＤＰで書
かれたセッション記述の構造は単純な流れの線形リストであり、これは複雑なセ
ッションの直観的な構造を反映してはいない。ＳＤＰは制限されかつ予め定めら
れた応用の組を支持し、これが流れと制限されかつ予め定められた移送機構の組
（例えば単純なレイヤリング、ＲＴＰ、及びＵＤＰ）を受領できる。保証された
サービス品質（ＱｏＳ）は消費者と供給者とにとってより一層望ましいものとな
っており、セッション全体と個々の流れとにとってＱｏＳポリシイを規定する必
要性は要求されたシステム資源、帯域幅要件及び支持された応用についてもまた
適っていることが必要とされる。流れとサブセッションとについての優先順位に
関する要件とか、流れを受領することについてのより複雑な規則とかが存在して
もよい。供給者の側での別な要件は、課金施設についての必要性であり、エンド
ユーザが加入しているマルチキャスト伝送について受領した流れのＱｏＳと形式
とに従って課金ができるようにすることである。ＱｏＳポリシイについて情報を
含めたり、ＳＤＰセッション記述の従来形の構造の中での課金についての情報を
含めたり、あるいはそのセッションについてのいずれかのメタデータを含めると
いった考え方はほとんど存在していなかった。

【００１０】 現在の（マルチ）メディアセッションのプロバイダ（提供者）と関係する（マ
ルチ）メディア応用のデベロッパ（開発者）とが直面している別な問題は、次の
ような応用を実施するのに必要とされる技芸（スキル）の拡散である。この応用
は通信網上での実時間データ接続を開始し管理することができ、かつ（マルチ）
メディア機能でエンドユーザが期待しているものを実行できるものである。例え
ば、マルチメディア応用のデベロッパは技芸をもったチームを必要とし、その分
野はオーディオ及びビデオコーデング、網トランスポートプロトコル、実時間プ
ログラミング、ユーザインターフェース設計、及び統合技術にわたる。さらに今
日まで、ＱｏＳポリシイが実施できる唯一のやり方はセッション記述を処理する
ことであって、それによってセッションのどの流れが実行できるか、あるいは実
行されるべきであるかを判断し、それから応用を始動させて、それぞれの流れに
接続するようにしていた。これは通信マネージャを必要とし、それによってセッ
ション要件と利用可能なシステム資源について知るようにするだけでなく、各応
用の能力についても知るようにするのに必要とされる。

【００１１】 別な問題は、応用が利用可能な網とホスト資源に適応できるものでなければな
らないことである。これは異種混合環境（ヘテロジニアスエンバイロメント）内
で動作するマルチパーティ（複数当事者）応用にとってはとくに重要であり、こ
の環境では各当事者は利用可能な異なる資源をもっていてよい。さらに、異種混
合の本質はセッションの寿命中に変ってよく、例えば、網の輻輳が変るとか、端
末資源が他の応用もしくは他のユーザと共用されるといった場合である。この発
明はセッション記述内部に組込まれているＱｏＳポリシイを用いることができ、
資源の割当てを優先順位づけかつセッションにおける関与は見込みのあるものか
どうかを判断するようにする。

【００１２】 別な問題は、応用デベロッパとサービスプロバイダとは一般にセキュリテイと
課金との要件に注目する必要があることである。この発明はセキュリテイと課金
ポリシイがセッション記述内部に組込まれることができるようにし、セッション
制御システム内部での使用にあてて、適切な課金とセキュリテイプロセスを呼出
すようにする。セキュリテイと課金機能を開発することを必須なものとするのに
代って、応用デベロッパとサービスプロバイダとは適切なポリシイを特定するた
めを必要とする。これらのポリシイはセッション記述内で識別されたかつセッシ
ョン制御システムにより呼出された遠隔サービスと関係していてよく、その条件
としてユーザが特定のメディアセッションを受領することを選んだこととしてい
る。

【００１３】

【課題を解決するための手段】 この発明の第１の特徴によると、メディアセッションの記述をアナウンスする
方法が用意されていて、ユーザにとってメディアセッションの少くとも一つのメ
ディア流を受領するために必要とされるメディア指向データを備えたセッション
記述を生成する段階と、ただし該メディア指向データはいくつかの応用プログラ
ム部品もしくはいくつかの応用プログラムについての要件もしくは応用プログラ
ム部品の構成で前記メディアセッションへの参加に必要とされているものを識別
するものであるとし、また該メディアセッションの潜在的な受領者にとって入手
できるセッション記述を作ることによってメディアセッションをアナウンスする
段階とを備えた方法となっている。

【００１４】 好ましいのは、前記メディア指向データは、メディアセッションにおける参加
に向けて応用を構築するために使用される多数の応用プログラム部品を指示して
いることである。

【００１５】 好都合なのは、前記メディア指向データは、前記部品が前記応用プログラムを
構築するために構成されることになるやり方を指示していることである。

【００１６】 好ましい実施例では、前記セッション記述は構造をもつデータフォーマットを
用いて生成される。

【００１７】 前記構造をもつデータフォーマットは拡張可能なマークアップ言語の形式に適
っているのがよい。

【００１８】 便利なのはメディア流の各々についてユーザ指向データが前記セッション記述
内部のいくつかの各メディアモジュールにおいて生成され、かつ前記方法はさら
にメディアセッションと関連のあるユーザ指向データを備えたベースモジュール
を生成する段階と、該ベースモジュールと各メディアモジュールの間でリンクを
用意する段階と、該ベースモジュールが前記潜在的な受領者にとって入手可能と
することによってメディアセッションをアナウンスする段階とを備え、メディア
モジュールの各々に向けてのリンクがベースモジュールに続くメディアモジュー
ルの各々にユーザがアクセス出来るようにすることである。

【００１９】 この発明の第２の特徴によると、メディアセッションを受領するためのプラッ
トホームを構成する方法が用意されていて、メディアセッションのセッション記
述を受領する段階と、ただしここで該セッション記述はメディアセッションの少
くとも一つのメディア流を受領するためにプラットホームにとって必要とされる
メディア指向データを備え、該メディア指向データはいくつかの応用プログラム
部品もしくはいくつかの応用プログラムについての要件もしくは応用プログラム
部品の構成で前記メディアセッションへの参加に必要とされているものであると
し、前記セッション記述を処理して適切な応用プログラム構成を入手可能な応用
プログラムもしくはプログラム部品のリストから判断する段階と、前記メディア
セッションへの参加について入手可能なプログラムの前記リストからそれぞれの
メディアセッション応用プログラムを構成する段階とを備えた方法となっている
。

【００２０】 この方法は、前記メディアセッションがそこを通って送られることになる網に
ついての特性に関する網データを受領する段階をさらに含み、かつそれぞれのメ
ディアセッション応用が前記網データにより構成されている。

【００２１】 この方法は、前記メディアセッションがそこで受領されることになる端末の特
性に関する端末データを受領する段階をさらに含み、かつそれぞれのメディアセ
ッション応用が前記端末データに従って構成されている。

【００２２】 好ましいのは、前記網データもしくは端末データもしくはその両方がメディア
セッションの間に監視され、かつメディアセッション記述が監視したデータに対
する変化に応答して修正される方法である。

【００２３】 好ましい実施例では、前記メディアセッションのユーザの好みに関するユーザ
プロフィルデータを受領する段階を含み、かつそれぞれのメディアセッション応
用が前記ユーザプロフィルデータによって構成されている。

【００２４】 便利なのは前記セッション記述はさらに前記メディアセッションを受領するた
めのサービス品質ポリシイを定義するデータを含み、かつそれぞれのメディアセ
ッション応用は該サービス品質ポリシイにより構成されていることである。

【００２５】 前記セッション記述はさらに前記メディアセッションへの参加にとって必要な
いくつかのサービスを定義するデータを含み、かつそれぞれのメディアセッショ
ン応用は該いくつかの遠隔サービスの要件によって構成されている。

【００２６】 好ましいのは前記セッション記述を処理する段階は、端末セッション制御を用
いてセッション記述を解析して入手可能な応用プログラムもしくはプログラム部
品のリストから適切な応用プログラム構成を判断する段階と、該セッション記述
内で識別されたいくつかのメディア流を選択する段階と、選択されたメディア流
を前記構成内でいくつかの応用プログラムもしくは部品と、各応用プログラムも
しくは部品についてのメディア流を管理するように構成されたセッション制御の
手段によって接続する段階とを備えていることである。

【００２７】 この発明の第３の特徴によると、メディアセッションの記述をアナウンスする
ためのシステムが用意されていて、メディアセッションの少くとも一つのメディ
ア流を受領するためにユーザにとって必要なメディア指向データを含むセッショ
ン記述を生成するためのメディアセッション記述生成器と、ただしここで該メデ
ィア指向データはいくつかの応用プログラム部品もしくはいくつかの応用プログ
ラムについての要件もしくは応用プログラム部品の構成で前記メディアセッショ
ン参加するのに必要とされているものを識別するものであるとし、また該メディ
アセッションの潜在的な受領者にとって入手できるセッション記述を作ることに
よってメディアセッションをアナウンスするメディアセッションアナウンサとを
備えたシステムとなっている。

【００２８】 この発明の第４の特徴によると、メディアセッションを受領するためのプラッ
トホームを構成するためのシステムが用意されていて、メディアセッションのセ
ッション記述を受領するための受信機と、ただし該セッション記述はメディアセ
ッションの少くとも一つのメディア流を受領するためにプラットホームにとって
必要とされるメディア指向データを備え、該メディア指向データは、いくつかの
応用プログラム部品もしくはいくつかの応用プログラムについての要件もしくは
応用プログラムの構成で前記メディアセッションへの参加に必要とされているも
のであるとし、前記セッション記述を処理して適切な応用プログラム構成を入手
可能な応用プログラムもしくはプログラム部品のリストから判断するプロセッサ
と、前記メディアセッションへの参加について入手可能なプログラムの前記リス
トからそれぞれのメディアセッション応用プログラムを構成する応用ビルダとを
備えたシステムとなっている。

【００２９】 この発明の上記特徴では、応用プログラム開発が、セッション記述を用いるこ
とによって簡単化されて、クライアントシステムの動的な管理と構成とがドライ
ブ（駆動）されるようにしてそこで実施がされるようにし、また利用可能な網と
端末資源とによりクライアントシステムに適応されるようにしている。また、課
金とセキュリテイ要件とを、課金とセキュリテイポリシイをセッション記述内部
で特定する事項について処理するという問題を軽減していても、これが遠隔サー
バによって与えられたサービスを用いて実施することもできるようにしている。

【００３０】 この発明はこの特許出願に記載されているモジュール形式の記述と一緒に使用
されるときはとくに有用であり、また出願人がした未決連合王国（ＵＫ）出願98
26158.9の主題ともなっており、この特許出願にも記載されているセッション制
御システムと一緒に使用されるときにもあてはまり、また出願人の未決ＵＫ出願
9826157.1の主題でもある。

【００３１】 この発明の例を添付の図面を参照して詳細に記述して行く。

【００３２】 実施例 ＩＰマルチキャスト伝送システムの一例が図１を参照して記述される。マルチ
キャスト伝送前に、セッション記述を含んでいる適切なアナウンスメント（告知
）が作られ、それによってエンドユーザ１１０ａ〜１１０ｅは伝送受領すること
を選ぶ。伝送受領を選んだ各エンドユーザはその伝送と関係している群ＩＰマル
チキャストアドレス１２０にリンクされている。マルチキャストセッションの伝
送時間には、セッション流（ストリーム）はソース１３０から、あるいは複数の
ソースから、群アドレスへ向けて送られる。群アドレスでは、伝送がリンク１４
０に沿って散布（ディスセミネート）されてこういったエンドユーザはそれを受
領することを選んだエンドユーザに送られる（この例ではエンドユーザは１１０
ａ〜１１０ｃとなっている）。

【００３３】 アナウンスメントと選出システムの例は図２を参照して記述される。最も公衆
的な（パブリックな）マルチキャストセッションは単一の群ＩＰマルチキャスト
アドレス２００でアナウンスされ、このアドレスはマルチキャストエンドユーザ
に向けたアナウンスメントの伝送に専用とされている。エンドユーザ２１０ａ〜
２１０ｅでアナウンスメントを受領することを選んだものはアナウンスメント群
アドレスにリンクされ、実際のセッション伝送と同じやり方で、アナウンスメン
ト群アドレスに到達する各アナウンスメントはエンドユーザに向けて配布される
。フロントエンドインターフェース２２０で各エンドユーザの計算機上にあるも
のは各アナウンスメントについて関係するセッション記述から得られた情報を表
示する。セッション記述が含んでいてよい最小情報は時間と日時についてのもの
でセッションが活性となるときを示すものと、群ＩＰマルチキャストアドレスで
あって、そこからエンドユーザがいくつかのメディア流を受領することを選んで
よく、しかもそこに向けてそのセッションについての独自の流れを送ることがで
きるアドレスである。フロントエンドインターフェースを用いて、エンドユーザ
はアナウンスされたセッションを選ぶことができ、あるいは参加したいと願って
いる部品流を選ぶことができる。

【００３４】 図３は単純なマルチキャストテレビジョンセッションについてのセッション記
述３００の構成図である。セッション記述３００はベースモジュール３１０を備
え、それがメディアモジュール３２０とリンクしている。

【００３５】 ベースモジュール３１０はセッションに関するユーザ指向データを含んでおり
、名称（タイトル）とタイミング情報とを含んでいる。ベースモジュール３１０
は記述もしくは概要、オーガナイザについての接触（コンタクト）情報、及びＷ
ＷＷもしくはイントラネットＵＲＩでもっと情報を含んでいるウエブサイトを指
しているものをまた含んでいてよい。理想的には、ベースモジュール３１０は、
ユーザにとってセッションへ参加するのに興味をもつかどうかを決めるのに十分
な情報を含むべきものである。

【００３６】 メディアモジュール３２０はセッションのビデオ流に関するアナウンスメント
データを含んでいる。メディアモジュール３２０は技術情報（データ）であって
ユーザにとって関係するメディア流を受領するのに必要とされるものを含んでい
る。とくに、接続と、タイミングと、メディアフォーマットの詳細が用意されて
いる。

【００３７】 セッション記述３００の第１の例でエンドユーザに向けて伝送するために生成
されたものを以下に示す。

【００３８】

【表１】

【００３９】 ベースモジュールはユニークな識別子（ＩＤフィールド）を有していて、セッ
ション記述の処理の間に二つのモジュール間でリンクを生成する際に使用される
。ベースモジュール３１０のモジュールフィールドは、ベースモジュール３１０
にリンクされるメディアモジュール３２０の形式とユニークな識別子とをリスト
する。メディアモジュール３２０のＩＤフィールド内の第２の識別子はユニーク
な識別子であり、ベースモジュール３１０に属していて、メディアモジュールを
ベースモジュール３１０に向けて戻すリンクを形成している。拡張によって、こ
れら二方向のリンクはモジュールの木（トリー）をベースモジュールから下方に
、もしくはメディアモジュールから上方にトラバース（移動）することができる
ようにしている。この特徴の使用は後にセッション記述例４を参照して記載され
る。

【００４０】 メディアモジュール３２０の接続フィールドはＩＰマルチキャストアドレスと
ポート番号とを含み、そこからメディア流が受領できる。

【００４１】 図４はセッション記述４００の構成図で、二つのトラックもしくはサブセッシ
ョン、及びパネルディスカッションをもつマルチメディア会議、複雑なマルチキ
ャストセッション用のものである。各トラックは複数当事者（マルチパーティ）
ビデオ及びオーディオ会議と、ノートとメッセージとを残すための共用の白板と
を与えている。パネルディスカッションは暗号化されて、全会議は各参加者によ
り事前に支払われる加入者料金が求められる。

【００４２】 セッション記述４００はトップレベルベースモジュール４１０とを含み、それ
が別のベースモジュール４２０，４３０，４４０とオプションのモジュール４１
１とリンクされている。トップレベルベースモジュール４１０は全体のセッショ
ンに関するデータを含み、そこにはその名前、目的及びタイミング情報が含まれ
ている。オプションモジュール４１１は加入料金についての支払い方法の詳細が
含まれている。

【００４３】 別のモジュール４２０，４３０，４４０の各々は会議のサブセッションと関係
している。ベースモジュール４２０は会議の第１のトラックと関係している。ベ
ースモジュール４２０はメディアモジュール４２１〜４２３にリンクされていて
、各々は接続、タイミング及びメディアフォーマットデータをそれぞれのビデオ
、オーディオ及びホワイトボード（白板）流について含んでいる。

【００４４】 ベースモジュール４２０はまたオプションのモジュール４２４にリンクされて
いて、そこには第１のトラックについてのＱｏＳポリシイに関するデータを含み
、どのメディアモジュールがオプションであり、どれが第１のトラックについて
の参加に強制されるかを定義している。強制のリストは、正しく動作するために
セッションもしくはサブセッションにとって必要とされる、そういったメディア
モジュールの識別子を含んでいて、またオプションのリストはシステム資源が乏
しいとすると、正しく動作をするためにセッションもしくはサブセッションにと
って必要ではないメディアモジュールの識別子を含んでいる。

【００４５】 ベースモジュール４３０は会議の第２のトラックと関係している。これはメデ
ィアモジュール４３１〜４３３とリンクされていて、その各々は接続、タイミン
グ及びメディアフォーマット詳細をそれぞれのビデオ、オーディオ、ホワイトボ
ード流について含んでいる。ベースモジュール４３０はまたオプションのモジュ
ール４３４にリンクされていて、このモジュールは第２のトラックについてのＱ
ｏＳポリシイに関するデータを含んでいて、どのメディアモジュールがオプショ
ンであり、またどれが第２のトラックの参加者にとって強制的であるかを定義し
ている。ベースモジュール４４０はパネルディスカッションと関係している。こ
れはメディアモジュール４４１，４４２とリンクされていて、接続、タイミング
及びメディアフォーマット詳細をパネルディスカッションのそれぞれビデオ及び
オーディオ流について含んでいる。ベースモジュール４４０はまたオプションの
モジュール４４３にリンクされていて、このモジュールは暗号詳細（すなわち、
どのようにして、またどこで必要とされる暗号キーを得るか）を含んでいて、こ
れはＤＥＳもしくは公開キー暗号法のような既知の暗号方法によりパネルディス
カッションメディア流４４１，４４２をデコードするために参加者にとって必要
なものである。

【００４６】 ビデオメディア流でメディアモジュール４４１内で定義されたものはレイヤ（
層構成）とされている。メディア流をレイヤとすることは異なるシステム資源を
備えたユーザがその者達のシステムが許す限り多くの流れを受領することができ
るようにする。ユーザは各人が最小の流れデータを含んでいる流れの底のレイヤ
を受領しなければならない。しかし、ユーザがもし十分な空いているシステム資
源を有していれば、その者達は前のレーヤに対するエンハンスメント（強化部分
）を含んでいる次のレイヤの上までを受領できる。継続するレイヤは受領できて
、受領したメディア流を強化して、レイヤの最大数が受領できるまで実行するか
、空いているシステム資源容量のすべてが使用されるまで実行する。メディアモ
ジュール４４１はオプションモジュール４４４にリンクされていて、そこにはエ
ンドユーザがレイヤとされた流れを正しく受領できるようにするのに必要なレイ
ヤ形成についてのデータを含んでいる。

【００４７】 エンドユーザに向けて伝送するためのモジュール４１０，４１１，４２０及び
４４０に対して生成されたセッション記述４００の一部がセッション記述例２と
して以下に示されている。

【００４８】

【表２】

【００４９】 余剰の帯域幅が利用可能な場合は、完全なセッション記述がエンドユーザに向
けてアナウンスできて、エンドユーザはそこでアナウンスされたセッションもし
くはその一部を受領することを選んでよい。しかし、セッション記述の個別のモ
ジュールは一緒にアナウンスされる必要はない。もしアナウンスメントのために
利用できる網帯域幅がセッション記述の大きさを制限するのであれば、トップレ
ベルのベースモジュールだけがアナウンスされる。この状態では、モジュール間
のリンクは、例えば、ＵＲＬでＷＷＷへもしくはインターネットウエブもしくは
サーバへ、あるＥメールアドレスへ、あるＩＰマルチキャストアドレスへ、ある
ＦＴＰアドレスへあるいはローカル計算機システム上に記憶されたファイルまた
はデータベースの詳細へ向けたものであって、そこから関心のあるユーザが残り
のモジュールを得ることができるものとする。

【００５０】 以下のセッション記述例はベースモジュール４２０についての上記セッション
記述がどのように変ることになるかを示しており、その条件はメディアモジュー
ル４２１がＷＷＷサーバ上に記憶されていることとしている。

【００５１】

【表３】

【００５２】 さらに、あるセッション記述のトップレベルモジュールは現実の伝送に十分に
先行してアナウンスされるようにできて、コンテンツの最終的な詳細が未知であ
るような時間にできて、この場合には残っているレベルは後刻に予めアナウンス
されたリンクから入手できることになる。

【００５３】 図５はこの発明によりエンドユーザシステムの端末でメディア流接続を制御す
るためのシステムの模式図である。

【００５４】 セッション制御システム５００はアナウンスメント受領用インターフェース５
１０と、いくつかのマルチキャストが可能とされているマルチメディア応用５２
０とにリンクされている。セッション制御システム５００とアナウンスメント受
領用インターフェース５１０とは網インターフェース５３０に接続されていて、
そこを介してアナウンスメントが受領され、またマルチキャスト伝送が開始され
及び／又は受領される。

【００５５】 網インターフェース５３０で受領されたアナウンスメントは受領用インターフ
ェース５１０へ向けてルート設定される。受領用インターフェース５１０は各ア
ナウンスメントをデコードしてセッション記述を得て、いくつかのベースモジュ
ールからのユーザ指向情報をリストの中でユーザに向けて表示する。ユーザは受
領したいと願っているセッションをアナウンスしているリストからセッション記
述を選択することができる。選択された記述はセッション制御システム５００に
向けて送られて、そこではユーザのマルチメディア応用５２０のどれが記述され
たセッションへの参加にとって必要とされるかを判断し、応用を開始し、必要と
されるメディア流をそれぞれの応用５２０に向けて通信マネージャ５５０を経て
与える。

【００５６】 受領用インターフェース５１０は他のインターネット通信応用５４０とリンク
されていてよく、ＷＷＷブラウザとかＥメールクライアント（図示せず）が応用
５４０の例であり、これが使われてセッション記述の中で用意されたリンクに基
いて記述されたセッションで別な情報を集める。また、不完全なベースの組及び
／又はセッション記述のメディアモジュールが受領される場合には、受領用イン
ターフェース５１０は残っているモジュールを得ようと試み、そのときにはセッ
ション制御システム５００へ送るのに先行してインターネット通信応用を使用す
る。

【００５７】 図６はセッション記述を受領したときにセッション制御システム５００によっ
てとられる段階を示す流れ図である。記述はまず解析されて（段階６００）、各
メディアモジュールについてのクライアント応用を識別する。これが行なわれる
と第２の解析が実行され、そこでは応用が放出され（段階６１０）、いいかえる
と、各メディアモジュールについてクライアントフィールドで特定された応用が
、もしすでに開始されていなければ開始される。それぞれのメディア形式に関す
るセッション記述の部分すなわちメディアモジュール、そのメディアモジュール
の直接上のベースモジュール、ベースモジュールに取付けられた他のすべてのモ
ジュール、及び応用対象の他のオプションモジュールが対応する応用に向けて送
られる（段階６２０）。メディアモジュールは適切なクライアント応用でしるし
が付けられているので、各応用は参加しようとしているメディア流を選べるよう
になる。この応用はセッション制御システムに対して接続要求で返答し、メディ
アモジュールの識別子のリストの形式で要件を特定し、そこから流れが開始され
ることになる（段階６３０）。接続要求はセッション制御システムによってまと
められ（アッセンブルされ）（段階６４０）、システムはそこでセッション記述
を解析して放出すべき他の応用を識別する（段階６４５）。もし他のメディア形
式が見付かると、段階６１０から６４０までが繰返され、そうでなければ、セッ
ション制御システムはまとめられた接続要求を用いてメディアモジュールのセッ
ション制御システムにより使用されるシステムであるリストを形成する。このリ
ストは、セッションＱｏＳポリシイと一緒に、通信マネージャに向けて送られ、
そこでＱｏＳポリシイと利用可能なシステム資源とにより各接続要求が存立可能
（見込みあり）かどうか判断される。

【００５８】 セッションＱｏＳポリシイは二段階で構築されている。第１は、始動されるこ
とになるメディアモジュールすべてに関連している複数のセッションＱｏＳポリ
シイが一つのセッションＱｏＳポリシイに組合されることである。第２は、結果
として生じたセッションＱｏＳポリシイが次のことを勘案するために適応される
ことである。すなわち（ａ）ユーザデフォルトプレファレンス（好み）（ユーザ
プロフィル内で定義されている）、（ｂ）対話形式でポリシイを決めたいとする
ユーザの希望、（ｃ）応用のデフォルト構成（応用プロフィル内で定義されてい
る）。

【００５９】 通信マネージャはセッション制御システムに対して存立可能なメディア流接続
要求を表示するもの（インディケーション）で応答する（段階６５０）。必要で
あれば、セッション制御システムは課金システムに接触してそのセッションにつ
いての会計計算を開始し、それを通信マネージャに対して存立可能なメディア流
接続を作ることを要求する前に行なう（段階６６０）。

【００６０】 セッションが開始されると、そのセッションと関係する各受領したデータ流が
関係しているマルチメディア応用に送られ（段階６７０）、計画された流れ時間
が終るまで続く（段階６８０）か、あるいはマルチメディア応用がセッション制
御システムに接続が終了させることを要求する（段階６９０）まで続けられ、そ
の点でセッション制御システムは接続を外す（段階７００）。

【００６１】 図７は図６のＱｏＳ管理段階６５０を詳細に示す流れ図である。

【００６２】 接続要求をまとめたリストを受領すると、通信マネージャはメディアプロフィ
ルに対してこのリストの各アイテムを整合させる（段階７０５）。メディアプロ
フィルは要件を定義し、この要件は要求されたメディア流にとって流れを満足し
て受領するために必要とされる最小網帯域幅を含んでいるエンドユーザ計算機上
で動作するためには、満たされていなければならない。

【００６３】 端末プロフィルは段階７１０で判断される。端末プロフィルは、要求されたメ
ディア流により使用するためのエンドユーザの計算機で利用可能な資源を定義す
る。これには利用可能な網帯域幅、空いているメモリ及びディスクスペース、そ
れに利用可能なハードウェアであって、モニタサイズ、プロセッサ速度、空いて
いるオーディオ及びビデオ捕捉装置といったものが含まれている。各接続要求の
メディアプロフィルは、端末プロフィルによって定義される利用可能なシステム
資源と比較される（段階７２０）。端末プロフィルがメディアプロフィルと整合
しているか、越えていれば、接続要求が存立するものとして宣言され（段階７３
０）、端末プロフィルがそれによつて残っている接続要求のためにデクレメント
され（減ぜられ）る（段階７４０）。各接続要求が処理されて、残っている要求
がなくなるまで、あるいは要求のメディアプロフィルが端末プロフィルを越える
まで続けられる。この状態では、通信マネージャは、本質的でない応用がすべて
実行されていない場合に、ユーザの計算機がもつことになる最適端末プロフィル
を判断して（段階７５０）、その計算機がメディアプロフィルを完遂することが
できるかどうかを判断する（段階７６０）。計算機がメディアプロフィルを完遂
できるのであれば、通信マネージャは現在割当てられている流れからシステム資
源を空けるように試みるか、低い優先順位をもつ接続要求からシステム資源を空
けるように試みるか、計算機上で実行している他の本質的でない応用を終結させ
るようユーザに求めるかする（段階７７０）。これに代って、レイヤとされてい
る流れ伝送から受領したレイヤの数を減らしてこれを実行することもできる。十
分な資源が見付からなければ、例外がユーザに報告され、接続要求が存在できな
いとしてしるしをつけられる。受領することができないメディア流が、メディア
セッションもしくはサブセッションについてＱｏＳポリシイの中で強制的なもの
として定義されているとすると、そのメディアセッションもしくはサブセッショ
ンについての全接続要求が取消される（段階７９０）。しかしもしメディア流が
オプション（適宜選ばれる類のもの）であれば、通信マネージャは別な接続要求
を処理し続ける（段階７２０）。すべての未決の（ペンデングとなっている）接
続要求が処理されてしまうと、通信マネージャは存立可能なものについてセッシ
ョン制御システムに報告する。

【００６４】 セッション記述の処理と、セッション記述の例４でトラック１について生成さ
れたセッション記述（図４のモジュール４１０及び４２０〜４２４）とがここで
図４を参照して記述される。

【００６５】

【表４】

【００６６】 セッション制御システムで上記のセッション記述を受領したものは、ベースモ
ジュール４１０で始まるセッション記述の木の構造を処理する。先ず最初に登場
するモジュールはベースモジュール４２０である。これはメディアモジュールで
はないがサブモジュールをもっているので、セッション制御システムはこの枝（
ブランチ）をメディアモジュールに向けて下げて続行する。

【００６７】 メディアモジュール４２１のメディアフィールドはすでにRealPlayer G2（Rea
l Network Incのマルチメディア応用）として要求されているマルチメディアク
ライアント応用を定義しており、したがって、セッション制御システムはそれを
無視して次のメディアモジュールへ続く。メディアモジュール４２２のメディア
フィールドは定義されたマルチメディアクライアント応用をもってはいないが、
しかし、オーディオデータについてのフォーマットは特定されている。このセッ
ション制御システムは、この特定のオーディオフォーマットがRealPlayer G2に
よってサポートできるので、それによってメディアフィールドをclient＝RealPl
ayer G2と読むように修正することを認識する。次のメディアモジュール４２３
はすでにクライアント応用をｗｂとして定義しており、したがってこのモジュー
ルを無視し、またオプションモジュール４２４を無視する。

【００６８】 セッション制御システムはクライアント応用を放出するために再びトリー（木
）構造を解析する。第１のメディアモジュール４２１はRealPlayer G2が放出さ
れるべきことを特定し、したがってセッション制御システムはエンドユーザのシ
ステム上で応用を放出して、この活動の記録を保存する。第２のメディアモジュ
ール４２２は応用を特定し、それがすでに放出されたことを特定し、それにより
セッション制御システムはそれを無視して次のメディアモジュールへ続ける。メ
ディアモジュール４２３はｗｂが放出されるべきことを特定し、それによってセ
ッション制御システムは応用を放出して、この活動の記録を保存する。

【００６９】 RealPlayer G2はメディアモジュール４２１、ベースモジュール４２０、及び
モジュール４２２−４２４に送られる。応用は与えられたメディアモジュールを
処理して、どれを処理できるかを判断し、この場合にはモジュール４２１と４２
２とを識別する。どの流れを処理できるかを判断すると、応用が接続要求をセッ
ション制御システムに向けて送り、モジュール４２１と４２２とのメディア流の
接続を要求する。同じように、ｗｂがメディアモジュール４２３、ベースモジュ
ール４２０、モジュール４２１〜４２２、及びモジュール４２４に送られる。応
用は与えられたモジュールを前記のように処理して、モジュール４２３のメディ
ア流への接続を要求する。

【００７０】 上記の接続要求はセッション制御システムによりリストにまとめられ（アッセ
ンブルされ）、このリストが次に通信マネージャに向けてセッションＱｏＳポリ
シイモジュール４２４と一緒に送られる。通信マネージャは各要求が存立可能か
どうか図７の諸段階に従って判断する。

【００７１】 強制的なメディア流についての接続要求のすべてに対して十分な資源が存在し
ていると仮定すると、通信マネージャか存立可能な流れのリストをセッション制
御システムに向けて送り戻し、そこで今度は再びトリー（木）を処理して各メデ
ィアモジュールの接続フィールド内に保持されている接続データを判断し、それ
によって、通信マネージャが接続データに従って存立可能な接続要求の各々につ
いて適切なメディア流への接続を開始することを要求できるようにする。セッシ
ョン制御システムはそこでこのセッションとそのメディア流接続とを管理し、そ
のやり方は図６の段階６７０〜７００を参照して記述したところによる。

【００７２】 この発明のこれまで記載してきた例はほとんどがメディアセッション記述に関
するものであり、そこでは構成要素であるメディア流を受領するために必要とさ
れるクライアント応用が明確に指示されていた。セッション記述例２として前記
したものはセッション記述の例であって、そこではクライアント応用が明白に指
示されていて、例えば“client＝RealPlayer G2”がそれであった。もしクライ
アント応用が複数のメディア流エンコードフォーマットを受理できるのであれば
、そのときはこれがまたセッション記述の中でも指示されてよい。加えて、ある
いはこれに代って、セッション記述はクライアント応用プログラム部品のブルー
プリント（計画、モデル等を示す青写真）を指示していて、その中には部品の必
要とされる構成が含まれていて、インターフェースとデータパッシング（送り）
などが含まれ、メディアセッションへの参加のためにユーザの端末で開始がされ
るようにしている。例えば部品は伝送／受領、暗号もしくは圧縮を目的としたも
のである。

【００７３】 このようなやり方についてのメディアモジュールの例を以下に示す。

【００７４】

【表５】

【００７５】 この例では、メディアフィールドは多数の応用部品とメディアセッションへの
ユーザ参加を支持するためにそれらがどのように構成されることになるかの方法
を指示している。例５のメディアフィールドはBeanマークアップ言語（ＢＭＬ）
を用いて定義されており、ＢＭＬはＩＢＭによって開発された記述用言語であり
、ネストされかつ相互接続されたJavaBeans部品の構造を記述するためにあてら
れる。JavaBeansはSun Microsystemsにより開発された規格でありソフトウェア
部品を定義するためのものである。JavaBeans部品もしくはBeansは再使用可能な
ソフトウェア部品であり、ＪＡＶＡプログラミング言語で書かれている。JavaBe
ans部品は一緒に組合わされて実行可能なプログラムを作る。ＢＭＬは直接実行
可能であり、言い換えると、例５におけるメディアフィールドのようなＢＭＬス
クリプトを処理することはそのスクリプトに従って構成された応用プログラムを
結果として生じさせる。ＢＭＬは新しいJavaBeansを作ることを記述するために
使用できる要素を有しているほか、既存のJavaBeansへのアクセス、性質もしく
はフィールドを得るか設定するかによるBeansの構成、いわゆる“イベント（事
象）”を他のBeansに結びつけること及びBeans内部に含まれる方法を呼出すこと
を記述するために使用できる要素を含んでいる。

【００７６】 ＢＭＬスクリプトで例５にあげたものはマルチキャスト“チャット（おしゃべ
り）”応用を記述するためのスクリプトを備えており、言い換えると、プログラ
ム応用で何人かのユーザがテキスト応用メッセージを交換できるようにするもの
を備えている。図８はグラヒカルユーザインターフェース（ＧＵＩ）を示し、こ
れが例５のＢＭＬスクリプトを処理する結果として構成されかつ実行されている
。例５のスクリプトをここで図８のＧＵＩ応用に関して説明する。

【００７７】 ＢＭＬスクリプトはフレーム“Text Chat”を定義する。これは図８に示した
ＧＵＩの矩形の周縁８００を定義する。ＢＭＬスクリプトはさらにつぎのものを
備えている：− ｉ）“StringMulticastBean”JavaBean部品でテキスト応用メッセージデータの
伝送と受領にあてるもの； ii）編集できない“TextArea”JavaBeans部品でメッセージの表示にあてるもの
； “TextArea”部品はテキストラインを表示する図８内の矩形のテキストエリア
８０５を定義する： “チャット応用のスクリーンショットを私に送れますか” “どのフォーマットをそこに入れてほしいですか” である。 iii）テキストエリア８０５をクリアするために“Clear”というラベルのついて
“Button”部品を含んでいる“Panel” 部品；PanelとButton部品はソフトボタ
ン“Clear”８１０を図８のテキストエリア８０５の右に定義している。 iv）ＧＵＩのユーザによってタイプされたメッセージを表示するための“TextFi
eld”部品を含んでいる“Panel”部品でメディアセッションの他の参加者に向け
て送られるべきもの、及び“TextField”部品内のテキストを送るため“Send”
とラベルを付けた“Button”部品。“TextField”部品は、図８の図面の中でＧ
ＵＩ周縁８００の底の縁に向けて置かれた矩形のテキストエリアを定義する。関
係する“ボタン”部品は“Send”とラベルを付けたソフトボタン８２０を図８の
図面の中でテキストエリア８１５の右に定義している。

【００７８】 例５では、<event-binding name＝“message”>…</event-binding>タグ間の
スクリプトの部分が網から受領したいずれものメッセージが“Text Area”部品
に向けて送られることを宣言している。第１の<event-binding name＝“action
”>…</event-binding>タグ間のスクリプトの部分はテキストエリア８０５で表
わされたテキストをＧＵＩ上のClearボタン８１０を押すことがクリアすること
を宣言している。加えて、第２の<event-binding name＝“action”>…</event-
binding>タグ間のスクリプトの部分はＧＵＩ上でSendボタン８１０を押すことが
“ＴｅｘｔＦｉｅｌｄ”部品のコンテンツを“StringMulticastBean”部品に向
けて伝送のために送ることを宣言している。

【００７９】 構成に先だって、例５でＢＭＬスクリプトによって記述された応用はセッショ
ン記述の情報フィールドと接続フィールドとからの別の情報を送られて、特定の
セッションについて応用を開始するようにしている。この情報はセッション記述
の異なるフィールド内に分けて保たれていて、それによりセッション固有のパラ
メータから応用記述を分離するようにしている。

【００８０】 例５では、ＢＭＬが定義した応用は、ＢＭＬプレーヤもしくはＢＭＬコンパイ
ラを用いて、利用可能なJavaBean部品から実行時に構築される。別の例では、セ
ッション記述もしくは少くともメディアフィールドがエクステンシブルマークア
ップ言語（ＸＭＬ）で記述されるように適応されていて、ＸＭＬからＢＭＬへ実
行時間に適当なエクステンシブルスタイルシート言語（ＸＳＬ）変換スクリプト
を用いて変換される。

【００８１】 既述したように、例５ではメディアフィールドが多数の応用部品とメディアセ
ッションへのユーザの参加をサポートするためにそれがどのように構成されるべ
きかのやり方を指示している。しかし、別な例では、上述の指示によるやり方と
は違って、メディアセッション記述がメディア流への参加のためのクライアント
の要件を宣言することができて、それをエンドユーザの端末に向けて残して置い
て、クライアント応用プログラム（１または複数）もしくはそのメディア流に参
加するのに必要とされる部品を判断するようにしている。要件を宣言すると、セ
ッション記述はメディア流のエンコード用フォーマットを定義して、それをエン
ドユーザ端末に残すことができて、そのエンコード用フォーマットを処理できる
クライアント応用を見付けることができるようにする。セッション記述例４とし
て上記したものはこの例である。別な例では、多数の部品形式（例えばビデオ、
オーディオ暗号等）が代って宣言されて、ユーザの端末はそこで利用できる部品
から選択をして、セッションへの参加のために適当な応用を開始する。例えば、
信頼性、コスト及びおくれといったメディアセッションの遅れがセッション記述
で特定されて、それにより部品が特定の要件に従って選択できる。例えば、信頼
性のある、低コストの、大きな遅れのある部品はメディア流再伝送用にはより適
切なものであろうし；中位の信頼性で、中位のコストで、中位の遅れをもつ部品
はメディア流データの冗長度を支持するためにより適したものであろう；また高
コストで、高信頼性をもち、低遅延の部品は高いサービス品質を求められるメデ
ィア流もしくはセッションを支持するためにより適していよう。いくつかの適切
な部品を選択することは知識ベースシステムを例えば使って実現できる。

【００８２】 必要とされるメディア流エンコード用フォーマットを宣言するためのセッショ
ン記述の例を以下に示す：

【表６】

【００８３】 例５に関連して述べたように、セッション記述、あるいは少くとも記述のメデ
ィアフィールドはエクステンシブルマークアップ言語（ＸＭＬ）で書かれていて
、ＸＭＬからＢＭＬへ実行時に適当なエクステンシブルスタイルシート言語（Ｘ
ＳＬ）変換スクリプトを用いて変換できる。

【００８４】 図９は端末でメディア流接続を管理するための別のシステムの模式図である。
このシステムは図５，６，７を参照して記述したところと似たやり方で動作する
。とくに、この例はセッション記述が宣言的もしくは指示的な部品で上述したよ
うなものを含んでいるときにとりわけ有用である。

【００８５】 セッション制御システム９００はセッション記述解析器９１０、応用ビルダ９
２０，多数の応用と応用部品９３０、及び通信マネージャ９４０を含んでいる。
セッション制御システム９００によりセッション記述を受領すると、セッション
記述解析器（パーサ）９１０はセッション記述を解析して、セッション記述によ
り記述されたメディアセッションのメディア流についてクライアント応用要件を
判断する。このクライアント応用要件は応用ビルダ（構築器）９２０に向けて送
られて、そこで多数の可能性のある応用構成が利用可能な応用と応用部品９３０
に基づいて生成される。通信マネージャ９４０と組合せて、応用ビルダは各応用
構成を評価して最善の構成を判断し、この最善の構成はクライアント応用要件と
一番よく整合がとれていて、しかもサービス品質、資源利用及びユーザの好みと
いった所定の基準を満足している。最善の構成は、部品の組合せに代って既存の
応用であってもよいのであり、そこで選択されて、始動される。この部品にはJa
vaBeans、ＣＯＭオブジェクト、ＭＨＥＧオブジェクト、動的なリンクされたラ
イブラリイからの部品、あるいはActiveMovie応用といった他のものとリンクす
ることができる応用であってよい。

【００８６】 例をあげると、マルチメディア会議では、応用はオーディオ部品と暗号部品と
を含むことが要件とされる。多数の資源を必要とする応用を選んで、会議によっ
て支持されていないビデオのような機能を提供するのに代って、個別のJavaBean
s部品が応用ビルダによって組合されて応用を作るようにする。

【００８７】 応用ビルダは通信マネージャと組合せて最善の応用構成を判断するように構成
されており、それには帰納的な（ヒューリステックな）方法もしくは他の人工知
能（ＡＩ）的方法によっており、例えば知識ベースシステム、ニューラル網、あ
るいは遺伝的（ジェネテック）プログラミングが採用される。

【００８８】 インターネットの異種混合性、異なる能力及び動作環境がエンドユーザ計算機
システムに存在することが原因となって、セッション制御システムで記述してき
たものはJava（JavaはSun Microsystems Inc.の商標である）で実現されている
。アナウンスメント受領用インターフェースである、Session Directoryはアナ
ウンスメントを受領してエンドユーザにより選択されたものを、セッション制御
マネージャでエンドユーザの計算機上の背景プロセスとして実行している、応用
プログラミングインターフェースとして実現されたものに向けて送る。

【００８９】 応用ビルダで図９のシステムで使用するのに適したものをここで図１０と１１
とを参照して行く。図１０では、クライアントサーバ環境内で網形成されたクラ
イアント１０００は応用ビルダ１００５、セッションディレクトリイ１０１０、
網インターフェース１０１５及び応用ＧＵＩ１０２０、クライアント応用／部品
で遠隔サービス１０２５、遠隔サービスを制御するための応用制御１０３０及び
多数のメディア流通信チャンネル１０３５を含んでいる多数の応用部品を備えて
いる。クライアント１０００は網１０４５に接続されていて、網は他のクライア
ント１０５０、メディアサーバ１０５５、及び遠隔サービスのサーバ１０６０を
備えている。この例の場合には、遠隔サービスはクライアント１０００から遠く
の位置にあるサービスプロバイダによって提供されるサービスである。この例で
は、遠隔サービスは次のものを含んでいる：−支払いサービスのようなＥコマー
スサービス、承認サービス、証明サービス、キーサービス（公開キー配信用）、
メールサービス、ホワイト及びイエローページのようなディレクトリイサービス
、及び課金サービスであり、セッション記述の関係するオプションモジュール内
に含まれているようなものである。

【００９０】 図１１では、応用ビルダ１００５は応用記述ライタ（書込み器）１１０５と応
用ビルダ（構築器）ツール１１１０とを備えている。応用記述ライタは第１のイ
ンターフェース（図示せず）を備えていて、セッションディレクトリイ１０１０
からセッション記述１１１５を受領するのにあたり、第２のインターフェース（
図示せず）を備えていて、メディアセッションが伝送されることになる網の各種
の特性を記述している網プロフィル１１２０を定義するデータを受領するのにあ
たり、第３のインターフェース（図示せず）を備えていて、メディアセッション
を受領することになるエンドユーザのいろいろな好みを記述しているユーザプロ
フィル１１２５を定義しているデータを受領するのにあたり、第４のインターフ
ェース（図示せず）を備えていて、メディアセッションを受領することになる端
末１１３５の各種の資源が関係する特性を記述している端末プロフィル１１３０
を定義しているデータを受領するのにあたる。第５のインターフェース（図示せ
ず）が用意されていて、応用部品１１４５の部品プロフィル１１４０を定義して
いるデータを受領するためにあてられていて、この応用部品１１４５は遠隔クラ
イアント１０５０もしくはサーバ１０５５，１０６０に局在するかあるいは離れ
ている応用ビルダにとって利用可能なものである。

【００９１】 一例では、応用記述ライタはセッション記述１１１５をＸＭＬスクリプトの形
式でセッションディレクトリイから、また少くとも一つの部品プロフィル１１４
０をこれもまたＸＭＬスクリプトの形式で受領する。セッション記述は指示的か
宣言的かであってよく、あるいは指示的で宣言的な要素を両方とも含んでいてよ
い。記述ライタはそれに加えて現在の網アクセス拘束条件を記述している網プロ
フィル１１１５を受領してよく、例えばユーザプロフィル１１２５で特定のユー
ザの好みを記述するもの、例えば網が輻輳しているとすると、低品質オーディオ
及びビデオよりも高品質オーディオが好ましいとしたり、また現在の端末能力を
記述する端末プロフィル１１３０を受領してよい。こういったプロフィルはまた
、ＸＭＬスクリプトで表現されていて、応用記述ライタ１１０５によって容易に
処理するようにしている。応用記述ライタはＸＳＬ変換スクリプトを含み、これ
がセッション記述を処理して、最適部品構成とセッション記述と資源関連プロフ
ィルとに基づいて判断する。応用記述ライタの出力はＢＭＬスクリプト１１５０
である。このスクリプトはビルダツール１１１０によって処理されて、クライア
ント１０００による選択されたメディアセッションでの使用のために始動するよ
うにされる。

【００９２】 こうして、セッション記述を処理するために、ＸＳＬスクリプトは実行されて
ＢＭＬスクリプトを一時的ファイルに向けて出力する。例えば、＜chat（おしゃ
べり）＞タグがセッション記述で解析されるときには、ＢＭＬスクリプトでチャ
ット応用に対する者が書き出される。同じように、＜address（アドレス）＞タ
グが解析されるときは、ＢＭＬスクリプトがチャット応用の書き出しのために設
定される。端末と網とユーザプロフィルとがまたＸＭＬで用意されて、プロフィ
ルに基づいて、解析されたＢＭＬスクリプトを修正するための規則がＸＳＬで呈
示される。ＢＭＬスクリプトは、それぞれのＸＳＬスクリプトの各々に関してそ
れを処理することにより各プロフィルについて修正がされる。例えば、低帯域幅
接続がオーディオ・ビデオ会議用に用意されているとすると、ビデオメディア流
は網プロフィル内の帯域幅情報を基にして落される。

【００９３】 次の例では、ＢＭＬスクリプトでオーディオ・ビデオ会議用のものが呈示され
ている。網プロフィルを処理した後に、ビデオ成分は取り除かれ、その条件は帯
域幅拘束条件で網プロフィルの中で識別されたものがそのように判断した場合と
する。こういった環境の下では、第１の<add>タグから第１の</add>タグに至る
間のスクリプトのすべてということになる。

【００９４】

【表７】

【００９５】 同じような動作がユーザプロフィルによってとられることができて、例えば、
もしユーザが会議の一部にだけ参加したいとしているときである。同じように、
端末プロフィルがＢＭＬスクリプトを修正でき、その条件はオーディオとビデオ
メディア流の両方を処理するためには不十分な処理能力しか存在しなかった場合
である。

【００９６】 クライアント応用の構築は、部品の利用可能性によって影響をされることにな
る。例えば網をまたいで部品をダウンロードするときの遅延を回避するためにこ
れが行なわれる。局所的にはオーディオ部品だけが利用可能であるとすると、そ
のときには応用ビルダはビデオ部品なしに応用を構築してよい。同じ、修正を加
えていないＢＭＬスクリプトを用いて、応用ビルダは、一旦ダウンロードがされ
たときには、ビデオ部品を加えることができる。別な例では、ＢＭＬスクリプト
は一つの部品を例えばＭＰＥＧのデコード用に特定してよいが、そのユーザは別
なものをインストールしてもよい。インストールされた部品はユーザプロフィル
から判断されたＸＳＬに従って示唆された部品に優越してもよい。

【００９７】 この発明はインターネットとマルチキャスト伝送に関して記述されてきたが、
読者にとって明らかなことは、記述されたモジュール形式のセッション記述とセ
ッション制御システムとが、ユニキャストのような他の既知の移送方法を用いて
、（マルチ）メディアセッションのメディア流（ストリーム）との接続について
アナウンスメント（告知）とその後の管理とに応用可能であるということである
。

【００９８】 さらに、暗号、課金、及び他のこの種のサービスについての方法ないしは機構
は明白には記述していないが、読者にとっては適切なセッション記述と関係する
帰納とでその処理のためのセッション制御システム内部にあるものは、求められ
た方法ないしは機構により直ちに実現できることは明らかであろう。

【図面の簡単な説明】

【図１】 Ｍボーンをまたいだマルチキャスト伝送を示す模式図。

【図２】 ＳＤＰアナウンスメントの配信を示す模式図。

【図３】 この発明により生成された単純なセッションについてのモジュール形式の構成
図。

【図４】 この発明により生成された複雑なセッションについてのモジュール形式の構成
図。

【図５】 メディア流（ストリーム）接続を管理するためのシステムの模式図。

【図６】 図５に示したシステムによるメディアセッションを管理するのに含まれる段階
を示す流れ図。

【図７】 図６の解析段階をさらに示す流れ図。

【図８】 この発明の特徴によるセッション記述において定義されるグラヒカルユーザイ
ンターフェース（ＧＵＩ）の模式図。

【図９】 端末においてメディア流接続を管理するための別なシステムの模式図。

【図１０】 クライアント応用ビルダを含むクライアント・サーバ環境の模式図。

【図１１】 図１０のクライアント応用ビルダを示す模式図。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号 ９９１３９２１．４ (32)優先日 平成11年６月15日(1999．6．15) (33)優先権主張国 イギリス（ＧＢ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＡＵ，ＣＡ，Ｊ Ｐ，ＳＧ，ＵＳ (72)発明者 ベル、サラ イギリス国、シービー４・８エックスダブ リュ、ケンブリッジ、コッテナム、ブレン ダ・ガウトリー・ウェイ ９ (72)発明者 イング、サロム イギリス国、アイピー４・２アールアー ル、サフォーク、イプスウィッチ、スプリ ング・ロード 112 (72)発明者 スミス、アラン・フィリップ イギリス国、アイピー４・５エルユー、サ フォーク、イプスウィッチ、アーンレイ・ ロード 12 (72)発明者 フェアマン、イアン・ラルフ イギリス国、アイピー３・８ジェイダブリ ュ、サフォーク、イプスウィッチ、カムデ ン・ロード 28 Ｆターム(参考） 5B085 BG07 5B089 GB01 JA16 JB21 KA10 KE07 KG03 5K030 KX28 LD02 【要約の続き】 階である。この発明を別な観点でとらえると、メディア セッションについてのプラットホームを構成する方法で あり、それには次の段階が含まれている：前述の形式の セッション記述（１１１５）を受領することと、セッシ ョン記述を処理して適当な応用プログラム構成（１１５ ０）を入手可能な応用プログラムもしくはプログラム部 品（１１４５）のリストから適切な応用プログラムを判 断するようにすることと；前記メディアセッションへの 参加について該リスト（１１４０）からのそれぞれのメ ディアセッション応用プログラム（１１５５）を構成す ることの段階である。

Claims (22)

【特許請求の範囲】
1. 【請求項１】 メディアセッションの記述をアナウンスする方法であって、 ユーザにとってメディアセッションの少くとも一つのメディア流を受領する
   ために必要とされるメディア指向データを備えたセッション記述を生成する段階
   と、ただし該メディア指向データはいくつかの応用プログラム部品もしくはいく
   つかの応用プログラムについての要件もしくは応用プログラム部品の構成で前記
   メディアセッションへの参加に必要とされているものを識別するものであるとし
   、また、該メディアセッションの潜在的な受領者にとって入手できるセッション
   記述を作ることによってメディアセッションをアナウンスする段階とを備えた方
   法。
2. 【請求項２】 前記メディア指向データは、メディアセッションにおける参
   加に向けて応用を構築するために使用される多数の応用プログラム部品を指示し
   ている請求項１記載の方法。
3. 【請求項３】 前記メディア指向データは、前記部品が前記応用プログラム
   を構築するために構成されることになるやり方を指示している請求項２記載の方
   法。
4. 【請求項４】 前記セッション記述は構造をもつデータフォーマットを用い
   て生成される請求項１ないし３のいずれか１項記載の方法。
5. 【請求項５】 前記構造をもつデータフォーマットは拡張可能なマークアッ
   プ言語の形式に適っている請求項４記載の方法。
6. 【請求項６】 メディア流の各々についてユーザ指向データが前記セッショ
   ン記述内部のいくつかの各メディアモジュールにおいて生成され、かつ前記方法
   はさらに、 メディアセッションと関連のあるユーザ指向データを備えたベースモジュー
   ルを生成する段階と、 該ベースモジュールと各メディアモジュールの間でリンクを用意する段階と
   、 該ベースモジュールが前記潜在的な受領者にとって入手可能とすることによ
   ってメディアセッションをアナウンスする段階とを備え、メディアモジュールの
   各々に向けてのリンクがベースモジュールに続くメディアモジュールの各々にユ
   ーザがアクセス出来るようにする請求項１ないし５のいずれか１項記載の方法。
7. 【請求項７】 メディアセッションを受領するためのプラットホームを構成
   する方法であって、 メディアセッションのセッション記述を受領する段階と、ただしここで該セ
   ッション記述はメディアセッションの少くとも一つのメディア流を受領するため
   にプラットホームにとって必要とされるメディア指向データを備え、該メディア
   指向データはいくつかの応用プログラム部品もしくはいくつかの応用プログラム
   についての要件もしくは応用プログラム部品の構成で前記メディアセッションへ
   の参加に必要とされているものであるとし、 前記セッション記述を処理して適切な応用プログラム構成を入手可能な応用
   プログラムもしくはプログラム部品のリストから判断する段階と、 前記メディアセッションへの参加について入手可能なプログラムの前記リス
   トからそれぞれのメディアセッション応用プログラムを構成する段階とを備えた
   方法。
8. 【請求項８】 前記メディア指向データは使用されることになる多数のプロ
   グラム部品を指示し、また前記セッション記述を処理する前記段階は前記リスト
   から前記指示された部品を選択する段階を含んでいる請求項７記載の方法。
9. 【請求項９】 前記メディア指向データは前記部品が構成されることになる
   やり方を指示し、また前記それぞれのメディアセッション応用プログラムの構成
   段階は前記指示されたやり方に従って前記選択した部品を構成する段階を備えて
   いる請求項８記載の方法。
10. 【請求項１０】 前記メディアセッションがそこを通って送られることにな
    る網についての特性に関する網データを受領する段階をさらに含み、かつそれぞ
    れのメディアセッション応用が前記網データにより構成される請求項７ないし９
    のいずれか１項記載の方法。
11. 【請求項１１】 前記メディアセッションがそこで受領されることになる端
    末の特性に関する端末データを受領する段階をさらに含み、かつそれぞれのメデ
    ィアセッション応用が前記端末データに従って構成される請求項７ないし１０の
    いずれか１項記載の方法。
12. 【請求項１２】 前記網データもしくは端末データもしくはその両方がメデ
    ィアセッションの間に監視され、かつメディアセッション記述が監視したデータ
    に対する変化に応答して修正される請求項１０または１１記載の方法。
13. 【請求項１３】 前記メディアセッションのユーザの好みに関するユーザプ
    ロフィルデータを受領する段階を含み、かつそれぞれのメディアセッション応用
    が前記ユーザプロフィルデータによって構成される請求項７ないし１２のいずれ
    か１項記載の方法。
14. 【請求項１４】 前記セッション記述はさらに前記メディアセッションを受
    領するためのサービス品質ポリシイを定義するデータを含み、かつそれぞれのメ
    ディアセッション応用は該サービス品質ポリシイにより構成される請求項７ない
    し１３のいずれか１項記載の方法。
15. 【請求項１５】 前記セッション記述はさらに前記メディアセッションへの
    参加にとって必要ないくつかのサービスを定義するデータを含み、かつそれぞれ
    のメディアセッション応用は該いくつかの遠隔サービスの要件によって構成され
    る請求項７ないし１４のいずれか１項記載の方法。
16. 【請求項１６】 少くともセッション記述は構造をもつデータフォーマット
    を用いて生成されている請求項７ないし１５のいずれか１項記載の方法。
17. 【請求項１７】 前記構造をもつフォーマットは拡張可能なマークアップ言
    語のフォーマットと一致する請求項１３記載の方法。
18. 【請求項１８】 前記セッション記述を処理する段階は、端末セッション制
    御を用いてセッション記述を解析して入手可能な応用プログラムもしくはプログ
    ラム部品のリストから適切な応用プログラム構成を判断する段階と、 該セッション記述内で識別されたいくつかのメディア流を選択する段階と、 選択されたメディア流を前記構成内でいくつかの応用プログラムもしくは部
    品と、各応用プログラムもしくは部品についてのメディア流を管理するように構
    成されたセッション制御の手段によって接続する段階とを備えている請求項７な
    いし１７のいずれか１項記載の方法。
19. 【請求項１９】 メディアセッションの記述をアナウンスするためのシステ
    ムであって、メディアセッションの少くとも一つのメディア流を受領するために
    ユーザにとって必要なメディア指向データを含むセッション記述を生成するため
    のメディアセッション記述生成器と、ただしここで該メディア指向データはいく
    つかの応用プログラム部品もしくはいくつかの応用プログラムについての要件も
    しくは応用プログラム部品の構成で前記メディアセッション参加するのに必要と
    されているものを識別するものであるとし、また該メディアセッションの潜在的
    な受領者にとって入手できるセッション記述を作ることによってメディアセッシ
    ョンをアナウンスするメディアセッションアナウンサとを備えたシステム。
20. 【請求項２０】 メディアセッションを受領するためのプラットホームを構
    成するためのシステムであって、 メディアセッションのセッション記述を受領するための受信機と、ただし該
    セッション記述はメディアセッションの少くとも一つのメディア流を受領するた
    めにプラットホームにとって必要とされるメディア指向データを備え、該メディ
    ア指向データは、いくつかの応用プログラム部品もしくはいくつかの応用プログ
    ラムについての要件もしくは応用プログラムの構成で前記メディアセッションへ
    の参加に必要とされているものであるとし、 前記セッション記述を処理して適切な応用プログラム構成を入手可能な応用
    プログラムもしくはプログラム部品のリストから判断するプロセッサと、 前記メディアセッションへの参加について入手可能なプログラムの前記リス
    トからそれぞれのメディアセッション応用プログラムを構成する応用ビルダとを
    備えたシステム。
21. 【請求項２１】 請求項１ないし１８のいずれか１項記載の方法を実行する
    ための実行可能な命令を含んでいる計算機が読取り可能な記憶媒体。
22. 【請求項２２】 請求項１９または２０記載のシステムを含む計算機が読み
    取り可能な記憶媒体。