JP4559484B2

JP4559484B2 - 通信システムにおける会議通信管理

Info

Publication number: JP4559484B2
Application number: JP2007531780A
Authority: JP
Inventors: カルタビル，ヒシャム
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2004-09-16
Filing date: 2005-09-13
Publication date: 2010-10-06
Anticipated expiration: 2025-09-13
Also published as: EP1794996A4; US20060056440A1; JP2008514070A; WO2006030061A1; EP1794996A1; FI20041205A0

Description

本発明は通信システムに関し，特に共有リソースを介した会議通信に関する。特に本発明は，通信システム内の共有リソースを介した会議通信管理に関する。

通信システムは，通信デバイス及び／又は通信システムに関係するほかのノードのような２つ以上のエンティティ間の通信セッションを可能にする施設と理解することができる。ユーザ又はエンドユーザのような通信システムの加入者は，通話，データ通信又はマルチメディアサービス，若しくはインターネットのようなネットワークへの単なる接続，のような多くのサービスを享受できる。各サービスは，通信システム運用事業者又は外部サービス提供事業者のサーバによって提供される。

通信システムの例は，限定するものではないが，公衆交換電話ネットワーク（ＰＳＴＮ）のような固定地上回線通信システム，例えば世界移動体通信システム（ＧＳＭ），はん用パケット無線サービス（ＧＰＲＳ），はん用移動体通信システム（ＵＭＴＳ）などの公衆地上移動体ネットワーク（ＰＬＭＮ）のような無線通信システム，無線構内ネットワーク（ＷＬＡＮ）のようなほかの無線システム，及び／又はインターネットプロトコル（ＩＰ）ネットワークのようなほかの通信ネットワーク，及び／又はほかのパケット交換データネットワークである。さまざまな通信システムが同時にコネクションに係わることもある。

通信システムの加入者に提供されるサービスは，例えばいわゆる直接音声通信サービスなどの多地点会議のような会議サービスを含む。直接音声通信サービスの一例は，ＰＴＴ（プッシュ‐ツ‐トークサービス）とも呼ばれる「セルラネットワークを介したプッシュ‐ツ‐トーク」（ＰｏＣ）サービスである。直接音声通信サービスは，例えばインターネットプロトコルマルチメディアサブシステム（ＩＭＳ）の能力を用いてもよい。ＩＭＳは，通信デバイスと，ほかの通信デバイス又はネットワークに関係するエンティティのようなほかの通信相手とにＩＰコネクションを提供する。直接音声通信サービスは，ユーザが１以上のユーザと直ちに通信を行えるようにできる。

ＰｏＣサービスは，半２重通信の例であり，同時には１人のユーザが話をして，ほかの人は聞くことを意味する。ユーザは，使用している通信デバイスから話をしたい人又は人のグループを選択し，通信デバイスのプッシュ‐ツ‐トークキーを押下，保持して話を始める。それでユーザはキーを押している間，話をすることができる。プッシュ‐ツ‐トークキーは，特定のボタン，スタイラス（ｔａｎｇｅｎｔ），又はユーザインタフェース内のどのようなほかの適当なキーであってもよい。タッチセンサ又は音声起動ユーザインタフェースを備えるデバイスも同様に用いることができる。通信セッションのすべての参加者が類似の方法でＰｏＣアプリケーションサーバと音声データ通信ができるので，双方向通信が提供できる。ユーザがプッシュ‐ツ‐トークキーを離すとすぐに，グループのほかのメンバが話をする順番を予約できる。話をする順番はプッシュ‐ツ‐トークキーを押下することによって要求することができ，先着順又は優先度に基づいて許可される。ＰｏＣ会議中の発言バーストは通常受信者が応答しなくても接続され，普通は通信デバイスの内蔵スピーカで聞くことができる。

標準の主流セルラネットワーク上に提供される，例えばＩＰによるパケットモードのグループ通信サービス層については，２００１年４月１７日にＬｏｐｐｏｎｅｎほかの名義で出願された米国特許出願第２００２／０１５００９１号に記載されている。

セルラシステムを介したプッシュ‐ツ‐トークについては，本願譲受人が２００４年９月７日に出願し，２００４年５月７日出願の英国特許出願第０４１０２７０．３号の優先権を主張する米国特許出願，及び本願譲受人名義で２００４年６月２２日に出願した英国特許出願第０４１３９７２．１号に記載されている。

会議アプリケーションは普通，発言権，帯域制限ビデオチャネルへの接続，若しくは共有アプリケーション内のポインタ又は入力フォーカスのような共有リソースを有する。多くの場合，共有リソースに誰が，例えば送信，書き込み又は制御などの入力をすることができるかをアプリケーションに応じて制御できることが望ましい。また，会議で議論されるトピックのペースを制御及び設定することが望ましい。例えば，トピックが結論を得たと思われるまで，トピックを変えたいユーザは共有リソースへの接続を拒否される。ユーザが現在議論されているトピックに寄与したいときは，共有リソースが許可される。

フロア（ｆｌｏｏｒ）制御は，共有リソースへの共同の，又は排他の接続を管理する，会議環境，特に多地点会議環境における機構である。例えばフロア制御は，どのユーザ又は複数のユーザがどの聞き手に話すことが許可されるかを管理する。フロア制御は，アプリケーション又はユーザが，例えば音声などのメディア制御のためのフロアのような共有オブジェクト又はリソースに対して，安全かつ相互排他の，又は非排他の接続ができるようにする。

既存の枠組みのコンテキストにおける多地点会議のフロア制御プロトコルへの要求条件は，Ｋｏｓｋｅｌａｉｎｅｎほか，「フロア制御プロトコルへの要求条件」，draft-ietf-xcon-floor-control-req-01.txt，２００４年７月，に規定されている。このＩＥＴＦ（インターネット技術委員会，www.ietf.org）インターネットドラフトは，参加者とサーバとの間の通信への要求条件をフロア制御プロトコルとして規定しており，フロアを要求している参加者が，オーディオフロアへの議論中のトピックのような要求について追加情報を与えることができる。更にこのインターネットドラフトは，いくつかのシナリオにおいて，フロアサーバ，すなわちフロアモデレータとも呼ばれるフロア制御議長が，ユーザにフロアを許可するとき，又はサーバにおいてフロアセットに操作を行うときにこの情報を用いることができることを特記している。

フロア要求トピックを用いることは，フロア要求者が何のトピックについて議論したいかをフロア議長に示す１つの方法である。このためにユーザは，フロアを要求する前にトピックを入力する必要がある。これはユーザに時間及び手間を取らせ，ユーザが議論されているトピックに寄与するのが遅れることになるかもしれない。また例えば機械又はソフトウェアのようなオートマトンがフロアを取り仕切るときは，これは不可能かもしれない。オートマトンは普通，テキストを理解し，知的に解釈することができない。

したがって，フロアを要求しているユーザが何のトピックについて何かを発言したいかを，より効率的に，及び／又はよりオートマトンに適した方法で示す方法が必要である。

本発明の実施例は，上記課題又は論点の１つ又はいくつかを処理することをねらいとする。

本発明の態様によれば，通信システム内の共有リソースを介した通信を管理する方法が提供される。この方法は，多数の接続要求を受信し，そのうち少なくとも１つの接続要求は，共有リソースを介して現在通信されている話題に関係するかどうかについて所定の指示を有するステップを有する。更にこの方法は，前記所定の指示に関して前記多数の接続要求を検証するステップを有する。更にこの方法は，所定のポリシに基づいて前記多数の接続要求を処理し，前記所定のポリシは基準として前記所定の指示を用いるステップを有する。

本発明のもう１つの態様によれば，通信システム内の共有リソースを介した通信への接続を要求する方法が提供される。この方法は，接続要求が前記共有リソースを介して現在通信されているトピックに関するかどうかについて所定の指示を有する接続要求を生成するステップを有する。更にこの方法は，前記接続要求を通信への接続を管理する管理エンティティに送信するステップを有する。

本発明のもう１つの態様によれば，通信システム内の共有リソースを介した通信を管理する管理エンティティが提供される。この管理エンティティは，多数の接続要求を受信し，そのうち少なくとも１つの接続要求は，共有リソースを介して現在通信されている話題に関係するかどうかについて所定の指示を有するように構成される。更にこの管理エンティティは，前記所定の指示に関して前記多数の接続要求を検証するように構成される。更にこの管理エンティティは，所定のポリシに基づいて前記多数の接続要求を処理し，前記所定のポリシは基準として前記所定の指示を用いるように構成される。

本発明のもう１つの態様によれば，そのような管理エンティティを備える通信システムが提供される。

本発明のもう１つの態様によれば，通信システム内の共有リソースを介した通信に参加するように構成した通信デバイスが提供される。この通信デバイスは，接続要求が通信システム内の共有リソースを介して現在通信されているトピックに関するかどうかについて所定の指示を有する接続要求を生成するように構成される。更にこの通信デバイスは，前記接続要求を，前記共有リソースを介した会議通信を管理する管理エンティティに送信するように構成される。

本発明のもう１つの態様によれば，通信デバイスのユーザインタフェースが提供される。このユーザインタフェースは，ユーザが選択を指示できるようにする制御手段と，前記ユーザの前記選択を検出する検出手段と，を備える。更にこのユーザインタフェースは，前記ユーザの前記選択を，前記接続要求が通信システム内の共有リソースを介して現在通信されているトピックに関するかどうかについて所定の指示を有する接続要求を生成する前記通信デバイスの生成手段に伝送する通信手段であって，前記所定の指示は前記ユーザの前記選択から値を得る手段を備える。

実施例において，少なくとも１つの接続要求は，前記少なくとも１つの接続要求が，前記共有リソースを介して現在通信されている前記トピックに関することを指示する第１所定値と，前記少なくとも１つの接続要求が，前記共有リソースを介して現在通信されている前記トピックとは異なるトピックに関することを指示する第２所定値と，のいずれか１つであるように構成したトピックフラグを有する。接続要求を生成するステップ及び送信するステップにおいてフロア制御プロトコルが用いられ，接続要求は更に所定の指示を有する。

実施例において，前記所定の指示に関して前記多数の接続要求が検証される。前記所定の指示を含む前記接続要求について前記所定の指示の値が検証される。

実施例において，前記接続要求が前記共有リソースを介して現在通信されているトピックに関することを前記接続要求の前記所定の指示が示しているとき，接続が許可される。実施例において，前記接続要求が前記共有リソースを介して現在通信されているトピックと異なるトピックに関することを前記所定の指示が示しているとき，前記の接続は拒否される。

実施例において，前記共有リソースを介した実行中の通信があるとき前記接続要求が受け入れられ，待ち行列内に保持される。前記接続要求が前記共有リソースを介して現在通信されているトピックに関することを前記所定の指示が示しているとき，第１待ち行列に前記接続要求が保持される。前記接続要求が前記共有リソースを介して現在通信されているトピックと異なるトピックに関することを前記所定の指示が示しているとき，第２待ち行列に前記接続要求が保持される。実施例において，前記接続要求に所定の指示がないときは，前記第１待ち行列又は前記第２待ち行列のいずれか１つに前記接続要求が保持される。実施例において，前記接続要求に所定の指示がないときは，第３待ち行列に前記接続要求が保持される。

実施例において，トピックを変えないことを示す同じ値に設定された所定の指示を有する少なくとも２つの接続要求が受信されることがある。そのような実施例においては，前記所定のポリシにおいて第２基準が用いられる。

ここで以降に示す例示及び付属の図面を参照し，本発明を例示としてのみ更に詳細に説明する。

図１に，通信ネットワーク１０と，第１通信デバイス２２と，第２通信デバイス３２と，第３通信デバイス４２と，を含む構成例を示す。第１通信デバイス２２は，接続エンティティ２４を介して通信ネットワーク１０に接続することが示されている。例えば第１通信デバイスは，接続エンティティ２４に接続された送受信ネットワーク要素と，無線インタフェースを介して無線信号を無線で送受信してもよい。同様に送受信ネットワーク要素は，通信デバイス２２と無線信号を無線で送受信してもよい。更に第２通信デバイス３２は，接続エンティティ２４を介して通信ネットワーク１０に接続することが示されている。第３通信デバイス４２は，接続エンティティ４４を介して通信ネットワーク１０に接続することが示されている。

共有リソースへの接続を管理し，フロア議長に関係するフロア制御サーバ１２も示されている。例示フロア制御サーバの動作は，以降に示す本発明の実施例の例によって明らかになるであろう。

図１は３つの通信デバイスだけが示されている例に過ぎないことを認識されたい。通常は，多数の通信デバイスが同時に通信ネットワークを介して通信する。更に通信デバイスは，例えばいくつかのＳＩＰセッションである数個の同時通信セッションと，活性化されたパケットデータプロトコル（ＰＤＰ）コンテキストと，を有してもよい。通信デバイスは，同一又は別のネットワークから通信システムへ接続することができる。通信デバイスは，任意の適切な接続システムを介して通信ネットワーク１０に接続してもよい。例示には，例えばＵＭＴＳ地上無線接続ネットワーク（ＵＴＲＡＮ），又はＧＳＭのＥＤＧＥ無線接続ネットワーク（ＧＥＲＡＮ）などの無線接続ネットワークと，Ｂｌｕｅｔｏｏｔｈ（登録商標）のような近距離無線システムと，その他と，が含まれるがそれらに限定するものではない。通信ネットワーク１０は，どのような単数又は複数の適切な通信ネットワークを含んでもよい。実施例において通信ネットワーク１０は，少なくとも部分的にはＩＭＳが提供することができる。

通信システム内のエンティティの名称は，システムに依存する。例えば無線接続ネットワークの接続エンティティは，３ＧＰＰ（第３世代パートナシッププロジェクト）システムにおける無線ネットワークコントローラ（ＲＮＣ）のようなコントローラと，３ＧＰＰ２（第３世代パートナシッププロジェクト２）システムにおける基地局コントローラ（ＢＳＣ）と，のようなコントローラを備えてもよい。更に図１では省かれているが，通常通信システムは，更なる交換及びほかの制御エンティティと，いくつかの無線接続ネットワークを介した通信を可能にし，また１以上のほかの通信システムと，１つの通信システムとをインタフェースするためのゲートウェイとを備える。数個の送受信ネットワーク要素，換言すれば３ＧＰＰにおけるノードＢ，又は３ＧＰＰ２におけるＢＴＳ（基地送受信局）のような送信器及び受信器，が１つの無線接続ネットワーク内に含まれてもよい。

エンドユーザは，ユーザ装置（ＵＥ），移動機（ＭＳ），携帯電話機，パーソナルデジタルアシスタント（ＰＤＡ），又はその類似物のような任意の適切な通信デバイス，若しくは，パーソナル計算機（ＰＣ）のようなほかのデバイス，若しくはセション開始プロトコル（ＳＩＰ），無線アプリケーションプロトコル（ＷＡＰ），又はハイパテキスト転送プロトコル（ＨＴＴＰ）のような適切なネットワークプロトコルによって動作する任意のほかの装置，によって通信ネットワークに接続することができる。通信デバイスは，無線通信システムの送受信ネットワーク要素と無線で信号を送受信するためのアンテナ又はほかのそのような送受信手段を備えてもよい。また通信デバイスは，ディスプレイ及びスピーカを備えてもよい。通信デバイスの動作は，キーパッド，音声コマンド，タッチスクリーン又はタッチパッド，それらの組合せ，若しくはその類似物のような制御手段を備えた適切なユーザインタフェースによって制御することができる。ユーザインタフェースは，メニュー，リスト，又はその類似物をユーザに表示することができ，そしてユーザがメニューから機能を選択することができるようにする。ユーザは上記の制御手段を用いて選択を指示することができる。ユーザインタフェースは，ユーザの行動を検出し，通信デバイスの通信論理に選択結果を伝えることができる。通常通信デバイスは，プロセッサ及びメモリ手段，並びにデバイスを操作し，ほかのエンティティの操作を可能にするソフトウェア及びアプリケーションを備える。ソフトウェアは，通信システム内のほかのエンティティにサービスを要求することができるものであり，クライアントと呼んでもよい。

例えばＩＭＳなどの通信システムは，インターネット技術委員会（ＩＥＴＦ）が開発したセッション開始プロトコル（ＳＩＰ）に対応してもよい。詳細は例えばＩＥＴＦＲＦＣ３２６１，"SIP: Session Initiation Protocol"，を参照されたい。ＳＩＰは，１人以上の参加者，すなわち端点を有するセッションを生成し，修正し，終了させるためのアプリケーション層制御プロトコルである。ＳＩＰに基づく通信システムに接続したユーザは，標準化されたＳＩＰメッセージに基づいて，通信システムのさまざまなエンティティと通信することができる。通信デバイス，又は通信デバイス上であるアプリケーションを操作しているユーザ，はＳＩＰバックボーンに登録され，それによって特定のセッションへの招待をこれら端点に正しく配信できる。ＳＩＰはデバイス及びユーザに登録機構を提供し，位置サーバ及び登録簿のような機構を適用して，セッション招待を適切に配信する。

ＳＩＰ制御ネットワークにおいてさまざまな種別の参加者を識別するために，普遍リソース識別子（ＵＲＩ）が用いられる。通常ＵＲＩは個々のユーザの登録されたユーザ識別情報を指す。またＵＲＩは，音声メールサーバ又は会議仲介（ｆａｃｔｏｒｙ）のようなサービス，チャット又はＩＰ電話（ＶｏＩＰ）会議のような会議インスタンス，若しくはほかの種別のリソースを識別することができる。

本発明の実施例は，例えばＰｏＣサービスのような多地点会議サービスで実現することができる。ＰｏＣシステムはセルラ通信システム内に組み込むことができ，ＩＭＳ内のプッシュ−ツ−トークサーバを用いて実現することができる。ＰｏＣサービスはマルチユニキャストに基づく。各送信通信デバイスは，専用プッシュ−ツ−トークサーバにパケットデータトラヒックを送信することができる。グループ通話の場合サーバは，すべての受信者がトラヒックを受信できるように複製又は増加させる。また本発明の原理は，ほかの多地点会議サービスによって実現することもできる。

ＰｏＣのような会議は，さまざまな方法で作ることができる。例えばＳＩＰ又は会議ポリシ制御プロトコル（ＣＰＣＰ）を用いることができる。ＣＰＣＰは，例えばＩＥＴＦの，Khartabilほか，"Conference Policy Control Protocol (CPCP)"，draft-ietf-xcon-cpcp-00，２００４年９月に述べられている。音声及びデータ制御トラヒックは，リアルタイムプロトコル（ＲＴＰ）ストリーミングベアラを通じて搬送することができる。ＲＴＰは，ＩＥＴＦＲＦＣ３５５０，"RTP: A Transport Protocol for Real-Time Applications"，に規定されている。ＲＴＰは，対話型のオーディオ及びビデオのような実時間特性を有するデータのためのエンド‐ツ‐エンド配信サービスを提供し，下位ネットワークが提供しているときはマルチキャスト配信を用いて，複数の目的地へのデータ転送に対応する。

フロア制御は，ＣＰＣＰと共に用いてもよい。又は会議がどのように始められたかとは無関係に，フロア制御を用いてもよい。

フロアは，特定の共有リソース又はリソースの組に一時的に接続するか，操作する許可と定義することができる。例えばフロアの許可，拒否又は取消しのために１つのフロアを管理するユーザ又はエンティティは，フロア議長又はフロアモデレータという。フロアを管理するエンティティは，オートマトンを備えてもよい。フロア制御サーバは，フロアの状態を維持する論理的なエンティティであって，フロアの状態は，どのフロアがあるか，フロア議長は誰か，誰がフロアを保持しているか，などを含む。フロア操作要求は，フロア制御サーバと，更にフロアモデレータとに向けられる。フロアを要求しているユーザは，フロア要求者集団と呼ばれる。現在フロアを保持しているすべての参加者を識別する論理データ構造は，フロア保持者集団である。

フロア制御サーバは，会議サーバ，会議ブリッジ，会議フォーカスと共設してもよいし，スタンドアロンでもよい。会議フォーカスとは，会議ＵＲＩでアドレスされるＳＩＰユーザエージェントであって，会議を識別する。フォーカスは，会議中各参加者とＳＩＰの信号通知関係を維持して，会議ポリシを実施する。フォーカスは，各参加者が会議を構成するメディアを受信することをいくつかの点で保証する論理的役割を担う。

図１に示すフロア制御サーバ１２は，通常ＩＭＳ又はほかの適切な通信システムに接続されたアプリケーションサーバ又はその一部であってもよい。フロア制御サーバ１２は，フロア議長又はフロアモデレータと関連して，多地点会議サービスのフロア制御を提供してもよい。

フロア議長又はモデレータは，Koskelainenほか，"Requirements for Floor Control Protocol"，draft-ietf-xcon-floor-control-req-01.txt，２００４年７月，に規定されるように，１つのフロアを管理（フロアの許可，拒否又は取り消し）するユーザ（又はエンティティ）である。フロア議長は，会議のメンバである必要はない。サーバ，及び参加者の１人又は第三者もまた，フロア議長として行動することができる。Koskelainenの文献の段落４に規定されたとおり，フロア制御プロトコルは，会議のフロア議長（モデレータ）と，フロア制御サーバと，会議の参加者との間でフロア制御メッセージを搬送するために用いられる。すべてのメッセージは１つの点，フロア制御サーバを経由する。フロア制御要求の処理（許可又は拒否）は，ポリシに依存して１以上のフロア議長又はサーバ自体が行う。Koskelainenの文献の段落７．１によれば，フロアを要求している参加者は，オーディオフロアに対する議論中のトピックのような，要求についての追加情報を与えることができる。

フロア制御プロトコルはバイナリであり，さまざまな情報を搬送する。Camarilloほか，"The Binary Floor Control Protocol (BFCP)"，http://www.softarmor.com/xcon/drafts/draft-ietf-xcon-bfcp-00.txt，２００４年７月，パラグラフ６．１，によれば，フロア要求形式は現在次のように規定されている。

FloorRequest = (FIXED-HEADER)
(TRANSACTION-ID)
(USER-ID)
[BENEFICIARY-ID]
[PRIVACY]
[FLOOR-REQUEST-ID]
*(FLOOR-ID)
[HUMAN-READABLE-INFO]
[PRIORITY]
[INTEGRITY]

Camarilloの文献によれば，クライアントはFloorRequestメッセージをフロア制御サーバに送信することによってフロアを要求する。更にまたFloorRequestメッセージは既存のフロア要求を修正するためにも用いられる。FLOOR-IDフィールドは，会議内のフロアを唯一に識別する。HUMAN-READABLE-INFOフィールドは，Koskelainenの文献に規定され，また上述したとおり，オーディオフロアに対する議論中のトピックのような要求についての追加情報を与えるために用いてもよい。

フロア制御プロトコルのフィールドにテキストで入力されたトピックを用いる代わりに，フロア制御プロトコルのFloorRequestのようなフロア要求に，フロア要求者が現在のトピックに寄与したいかどうか，又はトピックを変えたいかどうか，を示す新規のフィールド又はフラグを導入してもよいことがここで分かる。本明細書において新規フィールドは一般に「トピックフラグ」を指し，「新規トピック」フラグ及び「トピック変更」フラグ，又は代替として「現在のトピック」又は「トピックを続ける」フラグと呼んでもよい。フィールドがとることができる値は，フィールドの定義に依存する。以降にこれを例示するいくつかの例を示す。しかし，任意のほかの文字列又はその類似物も同様にフィールド名として用いることができ，フィールドがとる値は，何が記述されるかによって大きく異なってもよいことを理解されたい。特に，「現在のトピック」又は「トピックを続ける」フィールドは，フィールドが「新規トピック」又は「トピック変更」と呼ばれるときは類似の値とは反対を示す値をとることができる。

トピックフラグは，固定長フィールドによって提供してもよいし，又はフロア制御プロトコルにおける所定の選択可能な値をとるフィールドによって提供してもよい。実施例においてトピックフラグは，次に説明するように０及び１の値をとることができる１ビットフィールドであってもよい。代替として，数字又は文字のシーケンスのようなほかの所定の単純な指示を用いてもよい。代替の所定シーケンスは，真又は偽のシーケンスであってもよい。所定の指示は，機械又はソフトウェアのようなオートマトンが容易に解釈できることが好ましい。更に所定の指示は，フロア制御サーバに与える議論中のトピックについての追加情報を，通信デバイス内のアプリケーション又はソフトウェアが自動的に生成できることが好ましい。

実施例において，トピックフラグは「新規トピック」又は「トピック変更」フラグ，若しくはその類似物のように呼んでもよい。フロア要求者は，「新規トピック」フラグを値０に設定して，現在議論されているトピックに関して何かを言いたいことを示すことができる。代わりにフロア要求者は「新規トピック」フラグを値１に設定して，トピックの変更を示してもよい。また代わりに値「偽」を用いてフロア要求者が現在議論されているトピックに関して何かを言いたいことを示し，値「真」を用いて新規トピックを開始したいことを示してもよい。

代わりに新規フィールドを「現在のトピック」又は「トピックを続ける」，若しくはその類似物のように呼んでもよい。フロア要求者は，「現在のトピック」フラグを値１に設定して，現在議論されているトピックに関して何かを言いたいことを示すことができる。代わりにフロア要求者は「現在のトピック」フラグを値０に設定して，トピックの変更を示してもよい。また代わりに値「真」を用いてフロア要求者が現在議論されているトピックに関して何かを言いたいことを示し，値「偽」を用いて新規トピックを開始したいことを示してもよい。

更なる実施例において，新規フィールドは単に「トピック」フラグ又はその類似物のように呼んでもよい。フロア要求者は，トピックフラグを値「現在」に設定して，現在議論されているトピックに関して何かを言いたいことを示すことができる。代わりにフロア要求者はトピックフラグを値「新規」に設定して，トピックの変更を示してもよい。

フロアを要求するユーザは，どんなテキストも入力しなくてよい。このトピックフラグはオートマトンだけでなく人間が用いてもよい。トピックフラグは，フロア要求に優先度を与えるために用いてもよい。実施例において，フロア要求又は接続要求は，接続が直ちに許可されるときは待ち行列に保持してもよい。トピックフラグは，フロア要求の待ち行列を２つの待ち行列，すなわち１つは現在のトピックに対するもの，１つは新規トピックに対するもの，に完全に自動的に分離するために用いてもよい。フロア要求が受け付けられると適切な待ち行列に置かれる。これによって２つのフロア要求状態の報告が要求者に送信される。すなわち１つは要求が受け付けられたことを示し，もう１つは要求が待ち行列に入れられたことを示す。

実施例においてトピックフラグは，現在のトピック又は新規トピックのいずれかである既定値を有してもよく，ユーザがフロアを要求しているとき，ユーザからの対話又は選好値が何も検出されないときに設定される。

実施例においてトピックフラグは任意機能である。任意のトピックフラグを有する実施例においては，ユーザがトピックフラグを設定したとき，及びユーザから選好値が何も検出されないときにトピックフラグがフロア要求に含められ，フロア要求手続はトピックの指示なしに行ってもよい。トピックフラグがフロア要求又は接続要求にないときは，フロアモデレータは要求者がトピックを変えたいかどうか不明と解釈してもよい。実施例において，トピックフラグがないことが，「トピックの変更なし」のような既定の意味を持つように設定してもよい。そしてトピックを変更したい要求者だけがトピックフラグを設定する。

実施例において，通信デバイスにおいて所定の指示の設定に関して何の行動も検出されないときは，トピックフラグは不明値の指示を有してもよい。

図２に本発明の実施例の信号図を示す。

信号２０１で，クライアントＡ２２がフロア制御サーバ１２にフロア要求を送信してフロアを要求する。クライアントＡ２２は，フロア要求内の「新規トピック」フラグを偽，例えば値０に設定してトピックを変更しないことを主張する。信号２０２でフロア制御サーバ１２がフロアを許可する。

直後に信号２０３で，クライアントＢ３２が「新規トピック」フラグを真，例えば値１に設定して，トピックを変更したいことを表すフロア要求を行う。クライアントＢ３２は待ち行列に入れられ，信号２０４で要求が受け付けられたことを通知される。

次に信号２０５でクライアントＣ４２が，同じくトピックの変更なしを主張してフロアを要求する。フロア制御サーバ１２は，クライアントＣ４２のフロア要求を待ち行列内のクライアントＢ３２の要求の前に置く。クライアントＣ４２は信号２０６でそのように通知される。

信号２０７でクライアントＡ２２がフロアを解放する。フロア制御サーバ１２は更新した状態信号２０８をクライアントＡ２２に送信する。信号２０９でフロア制御サーバ１２は，トピックの変更がないのでクライアントＢ３２の前にクライアントＣ４２にフロアを許可する。信号２１０でクライアントＣ４２がフロアを解放すると，フロア制御サーバが信号２１１で応答する。フロア制御サーバは，現在のトピックに対してもうフロア要求がないと判定する。信号２１２でフロア制御サーバ１２はクライアントＢ３２にフロアを許可する。

フロア制御サーバ１２はフロア議長又はフロアモデレータに関係してもよく，人間，若しくは機械又はソフトウェアのようなオートマトンであってもよい。図２の要求２０１と，２０３と，２０５とは，フロア制御サーバ１２がフロア要求を受け付け，拒否し，又は許可するフロア議長又はモデレータに転送してもよい。明りょう性のため，フロア制御サーバ１２とフロア議長又はモデレータとの間の議長行動と呼ばれるこれらのフローは，図２には示していない。

更にクライアントＡ２２が，例えばフロアを許可されたとき，クライアントＢ３２及びＣ４２はフロア状態情報を受信してもよい。これらのフローもまた明りょう性のため，図２から省かれている。

実施例において，複数のユーザが同時に１つのフロアに，すべてがトピック変更について同じように指示する接続を要求してもよく，例えばすべてがトピックを変更しないことを示して新規トピックフラグを偽に設定する。そのような場合，フロア議長はフロア許可の第２基準を適用してもよい。例えばフロア議長はまず最初に要求を受信したユーザにフロアを許可し，それに続いて要求を受け付けた順に更なるユーザに許可するようにしてもよい。そのような原則は例えば，先着順型許可又は先入れ先出し待ち行列を指してもよい。

上記の実施例は，フロア制御サーバが，そしてそれによってフロア議長がどのようにトピックフラグ情報を処理することができるかについての１つの例示である。トピックフラグ情報を処理するもう１つの方法は，トピックフラグが，フロア要求者はトピックの変更を意図していることを示しているときは，フロア要求を拒否するものであってもよい。

デバイスのユーザインタフェースはトピックフラグがどの位置に設定されるかを決定するユーザフレンドリな方法をユーザに提供してもよい。活性な会議セッション中ユーザインタフェースは，ユーザが現在のトピックに寄与したいのか，トピックを変えたいのかを簡単に示すことができるようにしてもよい。例えばデバイスのユーザインタフェースは，このために特定のキーを備えてもよい。ユーザは，プッシュ−ツ−トークキーを押下するのと同時又は直前にそのキーを押下して，好みを示すことができる。キーを押下するとトピックフラグが，新規トピック又は現在のトピックのいずれか１つに設定される。したがってフロアを要求するときにキーを押下しないとフラグを代替値に設定するか，又は要求にトピックフラグを含めずにフロアを要求することになる。

本発明を特定の実施例で説明したが，本願請求項によって規定される本発明の範囲及び精神から逸脱することなく，さまざまな変形物が可能である。本発明の実施例を主として移動体ユーザ装置のような移動体通信デバイスに関して説明したが，本発明の実施例は通信ネットワークに接続し共有リソースを介してグループ通信に参加できるほかの種別の通信デバイスにも適用できることを認識されたい。更に通信システムは，ここでは主として移動体通信システムを参照したが，共有リソースを介してグループ通信を提供する任意の適切な通信システムであってもよい。

本発明の実施例における構成例を示す図である。本発明の実施例を示す信号図である。

Claims

通信システム内の共有リソースを介した通信を管理する方法であって，
多数の接続要求を受信し，そのうち少なくとも１つの接続要求は，共有リソースを介して現在通信されている話題に関係するかどうかについて所定の指示を有する受信ステップと，
前記所定の指示に関して前記多数の接続要求を検証する検証ステップと，
所定のポリシに基づいて前記多数の接続要求を処理し，前記所定のポリシは基準として前記所定の指示を用いる処理ステップと，
を有する方法。
前記多数の接続要求を受信する前記受信ステップは，前記少なくとも１つの接続要求が前記共有リソースを介して現在通信されている前記トピックに関することを指示する第１所定値と，前記少なくとも１つの接続要求が前記共有リソースを介して現在通信されている前記トピックとは異なるトピックに関することを指示する第２所定値と，のいずれか１つであるように構成したトピックフラグを有する前記少なくとも１つの接続要求を受信するステップを含む請求項１に記載の方法。
前記多数の接続要求を受信する前記受信ステップは，前記所定の指示を有するフロア制御プロトコルによって，前記少なくとも１つの接続要求を受信するステップを含む請求項１又は２のいずれか一項に記載の方法。
前記検証ステップは，前記多数の接続要求が前記所定の指示を含むかどうかを検証するステップと，前記所定の指示を含む前記多数の接続要求について前記所定の指示の値を検証するステップと，を含む請求項１〜３のいずれか一項に記載の方法。
前記処理ステップは，接続を許可するステップと，接続要求を受け入れ，かつ保持するステップと，接続要求を拒否するステップと，を含む請求項１〜４のいずれか一項に記載の方法。
前記処理ステップは，前記接続要求が前記共有リソースを介して現在通信されているトピックに関することを前記接続要求の前記所定の指示が示しているとき，前記の接続を許可するステップを含む請求項５に記載の方法。
前記処理ステップは，前記接続要求が前記共有リソースを介して現在通信されているトピックと異なるトピックに関することを前記所定の指示が示しているとき，前記の接続を拒否するステップを含む請求項５に記載の方法。
前記処理ステップは，前記共有リソースを介した実行中の通信があるとき前記接続要求を受け入れ，かつ前記接続要求を少なくとも１つの待ち行列内に保持する保持ステップを含む請求項５に記載の方法。
前記保持ステップは，前記接続要求が前記共有リソースを介して現在通信されているトピックに関することを前記所定の指示が示しているとき，第１待ち行列に前記接続要求を保持するステップを含む請求項８に記載の方法。
前記保持ステップは，前記接続要求が前記共有リソースを介して現在通信されているトピックと異なるトピックに関することを前記所定の指示が示しているとき，第２待ち行列に前記接続要求を保持するステップを含む請求項８又は９のいずれか一項に記載の方法。
前記保持ステップは，前記接続要求を前記所定の指示なしに受信したとき，前記第１待ち行列又は前記第２待ち行列のいずれか１つに前記接続要求を保持するステップを含む請求項１０に記載の方法。
前記保持ステップは，前記接続要求を前記所定の指示なしに受信したとき，第３待ち行列に前記接続要求を保持するステップを含む請求項８〜１０のいずれか一項に記載の方法。
前記受信ステップは，それぞれ同一の値に設定した前記所定の指示を有する少なくとも２つの接続要求を受信するステップを含み，かつ前記の処理ステップは，前記所定のポリシのもう１つの基準を用いるステップを含む請求項１〜１２のいずれか一項に記載の方法。
前記受信ステップは，所定の指示を有しない接続要求を受信するステップを含み，かつ前記の処理ステップは前記接続要求がトピックの変更に関するかどうか不明なものとして，また既定の意味を有するものとして前記接続要求を解釈するステップを含む請求項１〜１３のいずれか一項に記載の方法。
計算手段上で動作させたとき，請求項１〜１４のいずれか一項に記載のステップを実行するプログラムコード手段を含む計算機プログラム。
通信システム内の共有リソースを介した通信への接続を要求する方法であって，
接続要求が前記共有リソースを介して現在通信されているトピックに関するかどうかについて所定の指示を有する接続要求を生成する生成ステップと，
前記接続要求を，通信への接続を管理する管理エンティティに送信する送信ステップと，
を有する方法。
前記生成ステップは，前記接続要求が前記共有リソースを介して現在通信されている前記トピックに関することを指示する第１所定値と，前記接続要求が前記共有リソースを介して現在通信されている前記トピックとは異なるトピックに関することを指示する第２所定値と，のいずれか１つであるように構成したトピックフラグを有する前記接続要求を生成するステップを含む請求項１６に記載の方法。
前記生成ステップは，前記接続要求が前記所定の指示を有するようにした通信デバイスにおいて，キーと，スタイラスと，ボタンと，タッチセンサ部と，音声起動手段と，のうち１つを用いて前記所定の指示を設定するステップを含む請求項１６又は１７のいずれか一項に記載の方法。
前記生成ステップは，前記所定の指示を設定するステップに関する操作が何も検出されなかったとき，前記所定の指示の既定値を与えるステップを含む請求項１６〜１８のいずれか一項に記載の方法。
前記生成ステップは，前記所定の指示を設定するステップに関する操作が何も検出されなかったとき，前記所定の指示に何の値も与えないか，又は不明値である指示を与えるいずれかのステップを含む請求項１６〜１９のいずれか一項に記載の方法。
前記接続要求を送信する前記送信ステップは，前記所定の指示を有するフロア制御プロトコルによって前記接続要求を送信するステップを含む請求項１６〜２０のいずれか一項に記載の方法。
計算手段上で動作させたとき，請求項１６〜２１のいずれか一項に記載のステップを実行するプログラムコード手段を含む計算機プログラム。
通信システム内の共有リソースを介した通信を管理する管理エンティティであって，
多数の接続要求を受信し，そのうち少なくとも１つの接続要求は，共有リソースを介して現在通信されている話題に関係するかどうかについて所定の指示を有し，
前記所定の指示に関して前記多数の接続要求を検証し，かつ
所定のポリシに基づいて前記多数の接続要求を処理し，前記所定のポリシは基準として前記所定の指示を用いる，
ように構成する管理エンティティ。
前記所定の指示は，前記接続要求が，前記共有リソースを介して現在通信されている前記トピックに関することを指示する第１所定値と，前記接続要求が，前記共有リソースを介して現在通信されている前記トピックとは異なるトピックに関することを指示する第２所定値と，のいずれか１つであるように構成したトピックフラグを有する請求項２３に記載の管理エンティティ。
前記所定の指示を有するフロア制御プロトコルによって，前記少なくとも１つの接続要求を受信するように構成する請求項２３又は２４のいずれか一項に記載の管理エンティティ。
前記多数の接続要求が前記所定の指示を含むかどうかを検証し，かつ前記所定の指示を含む前記多数の接続要求について前記所定の指示の値を検証するように構成する請求２３１〜２５のいずれか一項に記載の管理エンティティ。
接続を許可し，接続要求を受け入れ，かつ保持し，又は接続要求を拒否するように構成する請求項２３〜２６のいずれか一項に記載の管理エンティティ。
前記接続要求が前記共有リソースを介して現在通信されているトピックに関することを前記接続要求の前記所定の指示が示しているとき，前記の接続を許可するように構成する請求項２７に記載の管理エンティティ。
前記接続要求が前記共有リソースを介して現在通信されているトピックと異なるトピックに関することを前記所定の指示が示しているとき，前記の接続を拒否するように構成する請求項２７に記載の管理エンティティ。
前記共有リソースを介した実行中の通信があるとき前記接続要求を受け入れ，かつ前記接続要求を少なくとも１つの待ち行列内に保持するように構成する請求項２７に記載の管理エンティティ。
前記接続要求が前記共有リソースを介して現在通信されているトピックに関することを前記所定の指示が示しているとき，第１待ち行列に前記接続要求を保持するように構成する請求項３０に記載の管理エンティティ。
前記接続要求が前記共有リソースを介して現在通信されているトピックと異なるトピックに関することを前記所定の指示が示しているとき，第２待ち行列に前記接続要求を保持するように構成する請求項３０又は３１のいずれか一項に記載の管理エンティティ。
前記接続要求を前記所定の指示なしに受信したとき，前記第１待ち行列又は前記第２待ち行列のいずれか１つに前記接続要求を保持するように構成する請求項３２に記載の管理エンティティ。
前記接続要求を前記所定の指示なしに受信したとき，第３待ち行列に前記接続要求を保持するように構成する請求項３０〜３２のいずれか一項に記載の管理エンティティ。
それぞれ同一の値に設定した前記所定の指示を有する少なくとも２つの接続要求を受信し，かつ前記所定のポリシのもう１つの基準を用いるように構成する請求項２３〜３４のいずれか一項に記載の管理エンティティ。
所定の指示を有しない接続要求を受信し，かつ前記接続要求がトピックの変更に関するかどうか不明なものとして，また既定の意味を有するものとして前記接続要求を解釈するように構成する請求項２３〜３５のいずれか一項に記載の管理エンティティ。
多地点会議サーバと，セルラネットワーク上のプッシュ‐ツ‐トークサーバと，前記共有リソースを介した前記通信の参加者と，第三者と，のうち１つを含む請求項２３〜３６のいずれか一項に記載の管理エンティティ。
通信システム内の共有リソースを介した会議通信を管理する管理エンティティであって，
多数の接続要求を受信する受信手段であって，そのうち少なくとも１つの接続要求は，共有リソースを介して現在通信されている話題に関係するかどうかについて所定の指示を有する手段と，
前記所定の指示に関して前記多数の接続要求を検証する検証手段と，
所定のポリシに基づいて前記多数の接続要求を処理する処理手段であって，前記所定のポリシは基準として前記所定の指示を用いる手段と，
を備える管理エンティティ。
請求項２３〜３８のいずれか一項に記載の管理エンティティを備える通信システム。
通信システム内の共有リソースを介した通信に参加するように構成した通信デバイスであって，
接続要求が通信システム内の共有リソースを介して現在通信されているトピックに関するかどうかについて所定の指示を有する接続要求を生成し，かつ
前記接続要求を，前記共有リソースを介した会議通信を管理する管理エンティティに送信する，
ように構成する通信デバイス。
前記接続要求は，前記接続要求が，前記共有リソースを介して現在通信されている前記トピックに関することを指示する第１所定値と，前記接続要求が，前記共有リソースを介して現在通信されている前記トピックとは異なるトピックに関することを指示する第２所定値と，のいずれか１つであるように構成したトピックフラグを有する請求項４０に記載の通信デバイス。
ユーザインタフェースに前記所定の指示を設定するステップに関する操作が何も検出されなかったとき，前記所定の指示に既定値を与える請求項４０又は４１のいずれか一項に記載の通信デバイス。
前記通信デバイスにおいて，前記所定の指示を設定するステップに関する操作が何も検出されなかったとき，前記所定の指示に何の値も与えないか，又は不明値である指示を与える請求項４０〜４２のいずれか一項に記載の通信デバイス。
前記所定の指示を有するフロア制御プロトコルによって，前記接続要求を生成するように構成する請求項４０〜４３のいずれか一項に記載の通信デバイス。
通信システム内の共有リソースを介した通信に参加するように構成した通信デバイスであって，
接続要求が通信システム内の共有リソースを介して現在通信されているトピックに関するかどうかについて所定の指示を有する接続要求を生成する生成手段と，
前記接続要求を，前記共有リソースを介した会議通信を管理するサーバに送信する送信手段と，
を備える通信デバイス。
前記生成手段は，前記接続要求が前記所定の指示を有するようにした，キーと，スタイラスと，ボタンと，タッチセンサ部と，音声起動手段と，のうち１つを備える請求項４５に記載の通信デバイス。
通信システム内の共有リソースを介した通信に参加するように構成した通信デバイスであって，
接続要求が通信システム内の共有リソースを介して現在通信されているトピックに関するかどうかについて所定の指示を有する接続要求を生成し，かつ
前記接続要求を，前記共有リソースを介した会議通信を管理する管理エンティティに送信する，
ように構成する通信デバイス。
前記共有リソースを介した前記通信は，多地点会議と，セルラネットワーク上のプッシュ‐ツ‐トーク通信と，のうち１つを含む請求項４７に記載の通信デバイス。
通信デバイスのユーザインタフェースであって，
ユーザが選択を指示できるようにする制御手段と，
前記ユーザの前記選択を検出する検出手段と，
前記ユーザの前記選択を，前記接続要求が通信システム内の共有リソースを介して現在通信されているトピックに関するかどうかについて所定の指示を有する接続要求を生成する前記通信デバイスの生成手段に伝送する通信手段であって，前記所定の指示は前記ユーザの前記選択から値を得る手段と，
を備えるユーザインタフェース。
共有リソースを介した通信を管理する管理エンティティであって，
多数の接続要求を受信する受信手段であって，そのうち少なくとも１つの接続要求は，共有リソースを介して現在通信されている話題に関係するかどうかについて所定の指示を有する手段と，
前記所定の指示に関して前記多数の接続要求を検証する検証手段と，
基準として前記所定の指示を用いる所定のポリシに基づいて前記多数の接続要求を処理する処理手段と，
を備える管理エンティティ
を備える通信システム。