(57)【要約】  プッシュツートーク型サービスで使用する方法が提供される。この方法は、プッシュツートーク型セッションにクライアント端末（１０）とともに参加している少なくとも１つの他の端末に、メディア項目を配信するためにクライアント端末（１０）に対して要求されるフロアが、そのメディア項目のサイズに関する情報に依存して管理される。このフロアの管理は、フロアの授与、維持、監視および解放の少なくとも１つを備える。この情報は、クライアント端末（１０）からフロアを要求するメッセージ（１）で送信されてもよい。フロアを要求するクライアント端末（１０）からのメッセージ（１）の受信に応じて、情報に依存して、このフロアはクライアント端末（１０）に授与または拒否される（２）。メディア項目が所定のサイズを超える場合、フロアは拒否されてもよい。セッション中のメディア項目の取得の進捗表示で使用するために、および／またはメディア項目を記憶するメモリの割当のために、その情報は、セッションに参加している少なくとも１つの他の端末にも送信されてもよい。このプッシュツートーク型サービスは、プッシュツートークオーバーセルラー（ＰｏＣ）サービスでもよい。このプッシュツートーク型サービスは、一般的な会議サービスでもよい。【選択図】  なし
2009514289.tif 000002
【特許請求の範囲】
【請求項１】
プッシュツートーク型セッションにクライアント端末（１０）とともに参加する少なくとも１つの他の端末にメディア項目を配信するために、前記クライアント端末（１０）に対して要求されるフロアが、前記メディア項目のサイズに関する情報に依存して管理される、プッシュツートーク型サービスで使用する方法。
【請求項２】
前記フロアは、前記メディア項目の種類に関する情報に依存して管理される
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記フロアは、前記メディア項目に対する期待転送レートに関する情報に依存して管理される
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記メディア項目は、優先度が割り当てられ、かつ前記フロアは、前記優先度に関する情報に依存して管理される
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記フロアの管理は、フロアの授与、維持、監視および解放の少なくとも１つを含む
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記フロアを要求するクライアント端末（１０）からのメッセージに応えて、前記情報に依存して前記クライアント端末（１０）へのフロアを承諾または拒否する工程を備えている
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記メディア項目が所定のサイズを超える場合、前記フロアを拒否する工程を備える
ことを特徴とする請求項６に記載の方法。
【請求項８】
前記フロアが与えられる場合、前記メディア項目を転送するための最小転送レートを指定する工程と、フロアが開いている所定の期間にわたって前記最小転送レートが達成されない場合、前記フロアを取り消す工程とを備える
ことを特徴とする請求項６または７に記載の方法。
【請求項９】
前記フロアを要求するメッセージで、前記クライアント端末（１０）から前記情報を送信する工程を備える
ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
前記セッションに参加する少なくとも１つの他の端末に、前記情報の少なくとも一部を送信する工程を備える
ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
前記セッション中に全mぉメディア項目の取得の進捗を示すために、受信側端末において前記情報を使用する工程を備える
ことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記メディア項目を記憶するメモリを割り当てるために、受信側端末において前記情報を使用する工程を備える
ことを特徴とする請求項１０または１１に記載の方法。
【請求項１３】
前記情報の少なくとも一部は、前記メディア項目のサイズに関する情報を含む
ことを特徴とする請求項１０乃至１２のいずれか１項に記載の方法。
【請求項１４】
前記プッシュツートーク型サービスは、プッシュツートークオーバーセルラーサービスである
ことを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
【請求項１５】
前記プッシュツートーク型サービスは、会議サービスである
ことを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
【請求項１６】
前記メディア項目は、フレーム化メディア項目である
ことを特徴とする請求項１乃至１５のいずれか１項に記載の方法。
【請求項１７】
前記メディア項目は、所定のサイズ、または少なくとも所定のサイズの範囲を有し、かつ前記情報は、前記サイズまたは前記サイズの範囲に関するものである
ことを特徴とする請求項１乃至１６のいずれか１項に記載の方法。
【請求項１８】
プッシュツートーク型サービスで使用するサーバであって、
プッシュツートーク型セッションにクライアント端末（１０）とともに参加する少なくとも１つの他の端末にメディア項目を配信するために、前記クライアント端末（１０）に対して要求されるフロアを、前記メディア項目のサイズに関する情報に依存して管理する手段を備える
ことを特徴とするサーバ。
【請求項１９】
プッシュツートーク型セッションに参加する少なくとも１つの他の端末にメディア項目を配信するためにフロアが要求される、プッシュツートーク型サービスで使用する方法であって、
セッションを制御するために指定されているサーバ（２０）へ、前記フロアを管理するためにサーバ（２０）によって使用される、前記メディア項目のサイズに関する情報を送信する工程を備える
ことを特徴とする方法。
【請求項２０】
プッシュツートーク型セッションに参加する少なくとも１つの他の端末にメディア項目を配信するためにフロアが要求される、プッシュツートーク型サービスで使用するクライアント端末であって、
セッションを制御するために指定されているサーバ（２０）へ、前記フロアを管理するために前記サーバ（２０）によって使用される、前記メディア項目のサイズに関する情報を送信する手段を備える
ことを特徴とするクライアント端末。
【請求項２１】
装置にロードされる場合に、前記装置を請求項１８に記載のサーバあるいは請求項２０に記載のクライアント端末を実現するオペレーティングプログラム。
【請求項２２】
装置で動作する場合に、前記装置に請求項１乃至１５、１９のいずれか１項に記載の方法を実行させるオペレーティングプログラム。
【請求項２３】
搬送媒体上で搬送される
ことを特徴とする請求項２１または２２に記載のオペレーティングプログラム。
【請求項２４】
前記搬送媒体は、伝送媒体である
ことを特徴とする請求項２３に記載のオペレーティングプログラム。
【請求項２５】
前記搬送媒体は、記憶媒体である
ことを特徴とする請求項２３に記載のオペレーティングプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
１．本発明の分野
本発明は、例えば、いわゆるプッシュツートークオーバーセルラーサービス等のプッシュツートーク型サービスで使用する方法および装置に関するものである。
【背景技術】
【０００２】
２．関連技術の説明
トランシーバ（walkie-talkie：ウォーキートーキー）型サービスは、相互間で短いメッセージを簡単に通信したいと要望するユーザ間で長い間にわたり知られているものである。従来、このようなサービスは、無線スペクトラムの専用部分を利用する双方向携帯無線によって提供されているが、この双方向携帯無線は、同種の端末を利用し、かつ比較的短距離の無線の動作範囲内に存在する事前に選択された小グループのユーザと通信することだけを可能にする。最近になって、既設のセルラー電話インフラストラクチャに便乗する（piggy-back：ピギーバックする）サービスが、米国で導入されている。しかしながら、このサービスは本質的に独自仕様であり、ユーザが異なるオペレータネットワーク間で通信することは許容されていない。
【０００３】
トランシーバ型サービスの使用を拡大するための試みに、セルラーネットワーク上で提供されるトランシーバサービスのネットワーク間運用（operability：オペラビリティ）を可能にする適切なプロトコルの標準化を目的として、オープンモバイルアライアンス（ｗｗｗ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｏｒｇ）として知られる産業団体が設立されている。様々な標準によって確立されているサービスは、ＰｏＣ（Push to talk over Cellular：プッシュツートークオーバーセルラー）として知られている。このＰｏＣは、パケット交換アクセスネットワークを通じて関連音声データを転送することを提案している。ＧＳＭおよびＵＭＴＳの場合、これは、汎用パケット無線サービス（ＧＰＲＳ、General Packet Radio Service）アクセスネットワークまたは３Ｇアクセスネットワークである。他のネットワークアーキテクチャでは、類似のパケット交換アクセスネットワークは、トークデータ（talk data）を転送するために利用されることになる。プッシュツートークサービスは、回線交換アクセスネットワーク上でも提供されてもよいが、好ましい選択肢（オプション）ではない。
【０００４】
プッシュツートークオーバーセルラー（ＰｏＣ）システムは、典型的には、ＧＳＭ／ＧＰＲＳ／３Ｇネットワークに実装され、セルラーネットワークへの高度データサービス、特に、リアルタイムマルチメディアサービスの導入を促進するために、第３世代パートナシッププロジェクト（３ＧＰＰ）によって標準化されているＩＰマルチメディアサブシステム（ＩＭＳ：IP Multimedia Subsystem）を使用する。このＩＭＳは、マルチメディアＩＰベースのセッションのセットアップおよび制御に対して、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ：Internet Engineering Task Force）によって定義されているセッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）に依存している。ＰｏＣサーバは、このＩＭＳ内に配置またはＩＭＳに接続され、ＰｏＣセッションをセットアップするおよび制御する機能を実現する。
【０００５】
既存のプッシュツートーク（ＰＴＴ：Push-To-Talk）システムおよび会議システムは、ユーザの１人に発言権を与え、通話中の他のユーザの発言権を拒否して、リスニングモードにすることを可能にするための、制御メカニズムを通常使用する。この制御メカニズムは、フロア制御、話者調停、トークバースト制御等と通常呼ばれる。例えば、オープンモバイルアライアンスは、トークバースト制御プロトコル（ＴＢＣＰ：Talk Burst Control Protocol）を有するプッシュツートークオーバーセルラー（ＰｏＣ）システムの仕様に現在取り組んでいる。
【０００６】
ユーザに代わって発言権を要求するために、端末（ＰｏＣクライアント）は、通常、コントローラ（ＰｏＣサーバ）に要求メッセージを送信する。このコントローラは、通常、要求の承諾または拒否で応答する。このコントローラは、要求を承諾する時点で発言許可タイマを開始することによって、ユーザに発言を許可する時間を通常制限し、通常、ユーザ端末へ取消（revoke）メッセージを送信することによって、または単にユーザのメディアを転送しないことによって、ユーザを遮断するいくつかのメカニズムを使用する。このコントローラによって遮断されるユーザは、いくつかの方法で、例えば、一定期間発言権を与えらないことによって、そのコントローラによって通常ペナルティが科される。
【０００７】
ＯＭＡ  ＰｏＣの次のバージョン（本明細書では、「ＰｏＣ２」と呼び、前のバージョンは「ＰｏＣ１」と呼ぶ）が、ＯＭＡで開発されている。ＰｏＣ２の新機能の一部は、ＰｏＣセッションで画像、映像等の送信を可能にする新規のメディアタイプを含めることである。以下は、非特許文献１からの抜粋である。「ＰｏＣ２サービスは、音声に加えてメディアタイプを使用するＰｏＣユーザ間の通信を容易にする。サポートされる追加のメディアタイプは、静止画、ライブストリームビデオ、ファイル転送、およびテキストとすることができるが、ここに示されるものに限定されない。ＰｏＣ２コンテキストでのビデオメディアストリームは、音声に言及せずに視覚要素だけを意図している。ＰｏＣ２サーバは、ＰｏＣセッションで１より多いメディアタイプのサポートを提供する。ＰｏＣ２クライアントは、ユーザ装置の性能（ケイパビリティ）に基づいて、セッションで１より多いメディアタイプをサポートすることができる」。また、非特許文献１から、「ＰｏＣクライアントは、ＰｏＣセッションの参加者に、（例えば、カメラから）ユーザ装置で利用可能な画像または一連の画像を送信してもよい」、「ＰｏＣサーバは、ＰｏＣクライアントによって送信される画像または一連の画像の転送をサポートしなければならない」、「ＰｏＣクライアントは、ＰｏＣセッションの参加者にユーザ装置で利用可能なファイル（例えば、ＭＳワード文書、ゲームソフトウェアパッケージ）を送信可能にしてもよい」、「ＰｏＣサーバは、ユーザ装置で利用可能なファイル（例えば、ＭＳワード文書、ゲームソフトウェアパッケージ）の転送をサポートしなければならない」。
【０００８】
上述のように、ＰｏＣセッションで送信されるメディアは、フロア（floor）制御メカニズムで管理される。現在フロアを有するユーザだけがメディアを送信できる。ＰｏＣ１では、送信されるメディアは音声だけである。フロアは一定時間あるユーザに割り当てられ、その期間中、そのユーザが話すことができ、他のユーザはトークバーストを受信することになる。
【非特許文献１】ＯＭＡ  ＰｏＣ２要件文書、ＯＭＡ−ＲＤ−ＰｏＣ−Ｖ２＿０−２００５０９０２−Ｄ「プッシュツートークオーバーセルラー２要件」、ドラフトバージョン２．０、２００５年９月２日
【発明の開示】
【発明が解決しようとする課題】
【０００９】
ＰｏＣ２において、同一のメカニズムが画像等の新しいメディアタイプに使用される場合に問題が生じる。ユーザが正当なサイズの画像を送信するためにフロアを要求する場合、ユーザがフロアを有する時間は画像の転送には十分でない可能性があり、その結果、画像の一部だけが、セッション参加者によって受信されることになるであろう。同一のことが、ファイル、ビデオクリップ等のあらゆるフレーム化（framed）メディアに当てはまるであろう。
【００１０】
この問題に取り組むことが要望されている。
【課題を解決するための手段】
【００１１】
本発明の第１の態様に従えば、プッシュツートーク型サービスで使用する方法が提供される。この方法は、プッシュツートーク型セッションにクライアント端末とともに参加する少なくとも１つの他の端末にメディア項目を配信するために、クライアント端末に対して要求されるフロアが、そのメディア項目のサイズに関する情報に依存して管理される。
【００１２】
このフロアは、メディア項目の種類に関する情報に依存して管理されてもよい。
【００１３】
このフロアは、メディア項目に対する期待転送レートに関する情報に依存して管理されてもよい。
【００１４】
このメディア項目は優先度が割り当てられてもよく、このフロアはその優先度に関する情報に依存して管理されてもよい。
【００１５】
このフロアの管理は、このフロアの授与、維持、監視および解放の少なくとも１つを備えてもよい。
【００１６】
この方法は、フロアを要求するクライアント端末からのメッセージに応じて、情報に依存してクライアント端末へのフロアを承諾または拒否する工程を備えてもよい。
【００１７】
この方法は、メディア項目が所定のサイズを超える場合、そのフロアを拒否する工程を備えてもよい。
【００１８】
この方法は、そのフロアが与えられる場合、そのメディア項目を転送する最小転送レートを指定する工程と、そのフロアが開いている所定の期間にわたってこの最小転送レートが達成されない場合、そのフロアを取り消す工程を備えてもよい。
【００１９】
この方法は、そのフロアを要求するメッセージで、そのクライアント端末から情報を送信する工程を備えてもよい。
【００２０】
この方法は、そのセッションに参加する少なくとも１つの他の端末に、その情報の少なくとも一部を送信する工程を備えてもよい。
【００２１】
この方法は、セッション中にメディア項目の取得の進捗を示すために、受信側の端末において情報を使用する工程を備えてもよい。
【００２２】
この方法は、メディア項目を記憶するメモリを割り当てるために、受信側の端末において情報を使用する工程を備えてもよい。
【００２３】
情報の少なくとも一部は、メディア項目のサイズに関する情報を備えてもよい。
【００２４】
プッシュツートーク型サービスは、プッシュツートークオーバーセルラーサービスであってもよい。
【００２５】
このプッシュツートーク型サービスは、会議サービスでもよい。
【００２６】
このメディア項目は、フレーム化メディア項目でもよい。
【００２７】
このメディア項目は、所定のサイズ、または少なくとも所定のサイズの範囲内でもよく、情報はそのサイズまたはサイズの範囲に関連してもよい。本発明の第２の態様に従えば、プッシュツートーク型サービスで使用するサーバが提供される。このサーバは、プッシュツートーク型セッションにクライアント端末とともに参加する少なくとも１つの他の端末にメディア項目を配信するためにクライアント端末に対して要求されるフロアを、そのメディア項目のサイズに関する情報に依存して管理する手段を備える。
【００２８】
本発明の第３の態様に従えば、プッシュツートーク型サービスで使用する方法が提供される。この方法は、プッシュツートーク型セッションに参加する少なくとも１つの他の端末にメディア項目を配信するためにフロアが要求される。この方法は、セッションを制御するために指定されているサーバへ、フロアを管理するためにサーバによって使用される、そのメディア項目のサイズに関する情報を送信する工程を備える。
【００２９】
本発明の第４の態様に従えば、プッシュツートーク型サービスで使用するクライアント端末が提供される。このクライアント端末は、プッシュツートーク型セッションに参加する少なくとも１つの他の端末にメディア項目を配信するためにフロアが要求される。このクライアント端末は、セッションを制御するために指定されているサーバへ、フロアを管理するためにそのサーバによって使用される、そのメディア項目のサイズに関する情報を送信する手段を備える。
【００３０】
本発明の第５の態様に従えば、装置にロードされる場合に、装置を本発明の第２または第４の態様に従う装置を実現するオペレーティングプログラムが提供される。
【００３１】
本発明の第６の態様に従えば、装置で動作する場合に、装置に本発明の第１または第３の態様に従う方法を実行させるオペレーティングプログラムが提供される。
【００３２】
このオペレーティングプログラムは、搬送媒体で搬送されてもよい。搬送媒体は、伝送媒体でもよい。搬送媒体は、記憶媒体でもよい。
【００３３】
本発明の実施形態は、ＰｏＣ２の新規のフレーム化メディアタイプ用の、メディアサイズに基づくフロア制御メカニズムを提供する。この実施形態は、遅すぎることが判明する場合、ＰｏＣサーバに対してメディアの送信を取り消すことも可能にする（例えば、５Ｇｂファイルの１ｋだけを受信しているが、１０分経過しているので、これ以上のデータの送信の取り消しを考慮してください」）。また、ＰｏＣサーバは、受信側にサイズ情報を搬送することができるので、この受信側に適切な量のメモリを割り当てて、ユーザにメディアを要望するかどうかを決定させ、ユーザに転送の進捗表示を提供することができる。
【００３４】
本発明の一実施形態は、配信するメディアのサイズに基づくフロア制御メカニズムを提供する。本発明の一実施形態は、フロア制御を通じて送信されるコンテンツに基づいて、送信側のクライアントに対してフロアを要求する方法を提供する。本発明の一実施形態は、送信するコンテンツのサイズに基づいて、フロア制御機能を扱うサーバに対して、フロア要求を承諾または拒否する方法を提供する。本発明の一実施形態は、コンテンツのサイズ情報および長時間のアップロードがどのように進捗しているかの経過時間に基づくことによって、ユーザビリティとサービスプロバイダのポリシーの視点の両方から転送レートが十分であるかどうかを判定することにより、フロア制御を扱うサーバに対してクライアントからのアップロード形式を制御する方法を提供する。本発明の一実施形態は、例えば、ソフトウェアの一部でメモリを割り当てることによってコンテンツに備えるために、フレーム化コンテンツの配信を含む通信セッションに係わる他のエンティティに、フロア制御を扱うサーバに対して、そのコンテンツの期待サイズを通知する方法を提供する。本発明の一実施形態は、よりユーザフレンドリなサービスを可能にするために、フロア制御を扱うサーバに対して、通信セッションに係わる他のエンティティに配信の進捗を通知する方法を提供する。
【発明を実施するための最良の形態】
【００３５】
実施形態の詳細説明
本発明を具体化する一方法では、ＰｏＣセッションにクライアント端末とともに参加する他の端末にメディア項目（media item）を配信するために、クライアント端末に対して要求されるフロアが、そのメディア項目のサイズに関する情報に基づいてセットアップおよび制御される。このことは、ＰｏＣサービスで使用するサイズ適応フロア制御メカニズムを効果的に提供する。フロアを要求するユーザは、フロア要求にＰｏＣセッションで配信することを要望するメディア項目のサイズを含めることができる。次いで、ＰｏＣサーバは、この情報に基づいて、フロアへのアクセスを承諾または拒否することができる。承諾される場合、要求されるサイズまでのメディアデータが配信されるまで、ユーザはフロアを有し得る。
【００３６】
本発明を具体化する方法および装置を図１に示す。図１に示すのは、ＰｏＣサーバ２０と通信するＰｏＣクライアント１０である。図２は、ＰｏＣクライアント１０およびＰｏＣサーバ２０の構成要素を概略的に示すブロック図である。ＰｏＣクライアント１０は、記憶部Ｃ１、要求生成部Ｃ３及び要求送信部Ｃ５を備え、これらの構成要素は管理部Ｃ７の全体的な制御の下で動作する。ＰｏＣサーバ２０は、要求受信部Ｓ１、要求処理部Ｓ３及び要求応答部Ｓ５を備え、これらの構成要素は管理部Ｓ７の全体的な制御の下で動作する。
【００３７】
ステップ１で、ＰｏＣクライアント１０がＰｏＣセッションに参加している他のクライアントに配信することを要望するメディア項目（記憶部Ｃ１に記憶されているメディア項目）が要求生成部Ｃ３から利用可能になる。要求生成部Ｃ３は、メディア項目のサイズを判定し、メディア項目のサイズを有するトークバースト要求を生成する。次いで、トークバースト要求は、ＰｏＣクライアント１０の要求送信部Ｃ５からＰｏＣサーバ２０へ送信される。このトークバースト要求は、メディア項目を送信するための許可をＰｏＣサーバ２０に要求するために、ＰｏＣクライアント１０によって使用される。
【００３８】
トークバースト要求は、ＰｏＣサーバ２０の要求受信部Ｓ１で受信され、要求処理部Ｓ３に渡される。この要求処理部Ｓ３は、次のトークバーストでＰｏＣサーバ１０にフロアを与えるか否かを判定するために、トークバースト要求に含まれるメディアサイズ情報を調査する。メディア項目が所定のサイズ未満である場合、ＰｏＣサーバ２０は、トークバーストを承諾することを決定し、要求されているサイズのメディア項目を送信するための許可が与えられていることをＰｏＣクライアント１０に通知するために、ステップ２で、ＰｏＣサーバ２０の要求応答部Ｓ５からＰｏＣクライアント１０へ、メッセージが送信される。一方、メディア項目が所定のサイズを超える場合、ＰｏＣサーバ２０は、トークバーストを拒否することを決定し、要求されているサイズのメディア項目を送信するための許可が拒否されていることをＰｏＣクライアント１０に通知するために、ステップ２のメッセージを使用することができる。
【００３９】
トークバースト要求が承諾される場合、ステップ３で、メディア項目のＰｏＣサーバ２０への転送が、承諾されているフロアを通じて実行される。次いで、ＰｏＣサーバ２０は、他のセッション参加者にメディア項目を配信することになる（不図示）。
【００４０】
ＰｏＣクライアント１０がメディア項目を転送するためにフロアを要求する場合、ＰｏＣサーバ２０の要求処理部Ｓ３が転送のためにフロアを許可するか否かの決定を行なうことを支援できる他のパラメータを含めるために、ＰｏＣクライアント１０は、要求生成部Ｃ３を使用しても良い。他のパラメータには、期待転送速度、メディア項目に関連する優先度、クライアントがトークバーストに使用し得る最大時間、およびメディアのコンテンツ、フォーマット、タイプ等の情報を含んでもよい。決定のためにＰｏＣサーバ２０によって使用される主な基準は、この実施形態では、フレーム化コンテンツ（framed content）であろう。しかしながら、決定を行なうために種々の種類の情報が、サイズ情報との組み合わせで使用することができる。例えば、フロアは、第１の所定のサイズを超える任意のメディア項目に対しても無条件に拒否されてもよく、第１の所定のサイズ未満で第２の所定のサイズを超える任意の映像項目に対して拒否されてもよく、高優先度でない限り第２の所定のサイズ未満で第３の所定のサイズを超える任意の画像項目に対して拒否されてもよく、それ以外は承諾されてもよい。他の種類のルールは、容易に可能であろう。
【００４１】
ステップ２でＰｏＣクライアント１０にフロアを与える場合、ＰｏＣサーバ２０の要求処理部Ｓ３は、最小転送レート（ＰｏＣクライアント１０は、これを超えるレートでコンテンツを送信することが必要となるであろう、あるいはフロアは取り消されるであろう）、および最大時間（この時間を過ぎると、フロアは取り消されるであろう）等のパラメータも含めてもよい。
【００４２】
ＰｏＣサーバ２０の要求処理部Ｓ３は、ＰｏＣクライアント１０および基礎をなすネットワーク等の他のソースから受信している情報に基づいて、ＰｏＣセッションの他の参加者にこの情報を伝えてもよい。この情報は、メディア項目への十分なメモリの割当や、エンドユーザへのメディア項目の取得の進捗についての情報の提供等の種々の目的のために、受信側の参加者で使用することができる。
【００４３】
ＰｏＣ１は、ＰｏＣサーバがＰｏＣクライアントにフロアが満了しようとしていることを通知することになる（これは、順にＰｏＣクライアントのユーザに通知してもよい）取消手順を有している。ユーザがフロアを失うまでにどのくらいの時間が残っているかをユーザに示すために、猶予期間タイマを使用することができる。同一の時間に基づくメカニズムは、本発明の一実施形態のように、フレーム化コンテンツを送信する場合に、クライアントに対する有用性は限られたものになるであろう。本発明を具体化するサイズに基づくフロア制御メカニズムに関しては、転送レートがより重要であり、ネゴシエーションされているレートまたはサービスプロバイダのポリシーに従うレートと比べて、転送レートが低すぎることをＰｏＣサーバ２０が気付く場合、取消手順を実行することができる。
【００４４】
この説明では、「フレーム化」メディア項目は、識別可能な開始と終了を有するメディア項目と理解されるべきである。例えば、画像、映画、音声ファイルまたは任意の他の種類のデータファイルも「フレーム化」メディア項目であるであろう。これは、通常は、コンテンツが前もって知られていることになるが、どのような種類の修正が適用され、それがメディア項目のサイズにどのように影響を及ぼすかが前もってわかっている場合、送信する端末が要求し、フロアが与えられた後で、（例えば、ＰｏＣサーバまたはそれと同等のものにおいて）メディア項目のコンテンツを修正することが可能となるであろう。例えば、ＰｏＣサーバは、例えば、任意の画像若しくは映像に企業ロゴまたは機密警告を付加することによって、通過するメディア項目のサイズを変更することができる。しかしながら、何が話されるか前もってわからず、それ故にどのくらいのデータが音声をコード化するために要求されるか前もってわからない音声データストリームを送信するためのフロアに対する要求は、「フレーム化」メディア項目を転送するための要求は見なされることはないであろう。一方では、確保されている時間またはユーザが話を完了しているかどうかに無関係に、フロアを与えられているユーザがその限界に達するまで話すことが可能となるように、話の内容を前もって知ることなしに、一定のサイズの限界まで音声データを送信するためのフロアを要求することは可能であろう。それゆえ、本発明の一実施形態は、メディア「項目」が所定のコンテンツを有する実行されているフレーム化メディアファイルの場合だけでなく、一般に指定されているまたは予測可能なデータのサイズ、若しくは量を有するが指定されていないコンテンツ（メディアコンテンツの転送のためのフロアを要求する時点で）を有するメディアコンテンツにも及ぶと見なしてもよい。
【００４５】
本発明の一実施形態は、ＰｏＣとの関連で説明しているが、本発明は、ＰｏＣに限定されないことは理解されるであろう。通信セッションにおけるフレーム化メディアを配信する任意の他の種類のサービスも、送信者のアップロードする割合（レート）を制御するために、加えて、皆が同時に送信しそれによってエアインタフェース若しくは他の限られたリソースに負担をかけ過ぎる状況を避けるために、サイズに基づくフロア制御から利益を得るだろう。「プッシュツートーク」サービスという用語は、本明細書では、本質的にトランシーバ的サービスを特定するために使用されている。これらのサービスは、トークバーストの交換のために、２人以上のユーザを一緒に素早く接続することを可能にするサービスである。プッシュツートークサービスは、これらのサービスが所与の時間に１人だけが話すことを可能にする点で、従来の音声通話とは異なる。話すためには、ユーザは、「フロア」の制御を持たなければならない。制御は、通常、１人のユーザがフロア制御を解放するためにトークボタンを解放し、別のユーザがフロア制御を引き受けるためにトークボタンを押すことによって達成される。添付の特許請求の範囲で使用される用語「プッシュツートーク」は、特定のプロトコルの使用を含意する意図がないことが理解されるべきである。本発明を具体化する方法を使用して、ＰｏＣサーバの関与なしに、２人のクライアントが相互間でＰｏＣセッションを管理することも可能である。
【００４６】
本発明の範囲は、トークセッションでのトークデータあるいは音声データの転送に制限されず、添付の特許請求の範囲は、データ転送セッションにおける音声データを含むがそれに限定されない、任意の種類のデータの転送も網羅すると解釈されることも、理解されるべきである。そのようなものであるから、「トークバースト要求」および「トークバースト」等の用語は、トークデータすなわち音声データだけに限定されると解釈されるべきではないが、ＰｏＣ１の用語と一貫性を持たせるために使用されている。このような語句は、その意味内に任意の種類のデータの転送も含み得る。ＰｏＣ２では、ＰｏＣ１のコンセプトに直接対応するコンセプトに対して、異なる用語が使用されても良い。例えば、語句「メディアバースト要求」および「メディアバースト」が代わりに使用されても良い。
【００４７】
本発明の範囲は、参加者がフロア制御を与えられ、それによって会議での発言権または他の参加者へデータを転送する権利を与えられる会議システムを含むことを意図していることも理解されるべきである。
【００４８】
上記構成要素の１つ以上の動作が機器または装置で動作するプログラムによって制御されてもよいことは理解されるだろう。このようなオペレーティングプログラムは、コンピュータ可読媒体に記憶することができ、また、例えば、インターネットウェブサイトから提供されるダウンロード可能なデータ信号等の信号で実現することができる。添付の特許請求の範囲は、オペレーティングプログラム自体で、またはキャリヤ上のレコードとして、または信号として、または他の形態で、オペレーティングプログラムを含んでいると解釈されるべきである。
【図面の簡単な説明】
【００４９】
【図１】本発明を具体化する方法および装置を概略的に示すメッセージ交換図である。
【図２】本発明の一実施形態のＰｏＣクライアントおよびＰｏＣサーバの構成要素を概略的に示すブロック図である。
【図１】
2009514289.tif 000003
【図２】
2009514289.tif 000004
【国際調査報告】
2009514289.tif 000005
2009514289.tif 000006