JP5219820B2 - プッシュツートーク型サービスのための方法および装置 - Google Patents

Description

本発明の背景
１．本発明の分野
本発明は、いわゆるプッシュツートークオーバーセルラサービスで使用する方法および装置に関するものである。

２．関連技術の詳細
トランシーバ（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）メッセージを送信することによって、または単にユーザのメディアを転送しないことによって、ユーザを遮断するいくつかのメカニズムを使用する。このコントローラによって遮断されるユーザは、いくつかの方法で、例えば、一定期間発言権を与えないことによって、そのコントローラによって通常ペナルティが科される。

ＯＭＡ ＰｏＣの次のバージョン（本明細書では、「ＰｏＣ２」と呼び、前のバージョンは「ＰｏＣ１」と呼ぶ）が、ＯＭＡで開発されている。ＰｏＣ２の新機能の一部は、新規のメディアタイプを含めることになっていて、ＰｏＣセッションで、画像、映像等の送信を可能にする。しかしながら、エンドユーザまたはクライアントは、利用可能な全メディアの中のサブセットを扱う（選ぶ）ことだけが許容される場合がある。これを考慮すると、メディア除外（media barring）機能を含めることは必要条件になるであろう。以下は、ＯＭＡ ＰｏＣ２要件文書、［ＯＭＡ−ＲＤ−ＰｏＣ−Ｖ２＿０−２００５０９０２−Ｄ「プッシュツートークオーバーセルラー２ 要件」、ドラフトバージョン２．０、２００５年９月２日］からの抜粋である。「ＰｏＣ１．０で仕様化されているものに加えて、着信メディア除外機能は、受信ＰｏＣユーザがある時点にあるメディアの受信を望まない場合に必要とされる。ユーザは、残りのグループ内の変換およびメディア共有を干渉することなしに、この除外を要求することができる」。また、ＯＭＡ ＰｏＣ２要件文書から、「ＰｏＣクライアントは、各メディアタイプに対して個別に着信メディア除外をサポートしてもよい」、「ＰｏＣクライアントは、各メディアタイプに対して異なる受諾および拒否のルールをサポートしてもよい」、「ＰｏＣサービスインフラストラクチャは、各メディアタイプに対して個別の着信ＰｏＣメディア除外をサポートしなければならない」、「ＰｏＣサービスインフラストラクチャは、映像がメディアの場合、ＰｏＣセッションに対するデフォルト応答モードとして、手動応答モードを使用しなければならない（ＰｏＣユーザは、ユーザの要望に応じて、この応答モードを設定することができる）」、「ＰｏＣサービスインフラストラクチャは、メッセージングメディアだけのＰｏＣセッションに対して、または進行中のＰｏＣセッションにメッセージングを追加する場合に、デフォルト応答モードとして自動応答モードを使用しなければならない」、「ＰｏＣサービスインフラストラクチャは、ＰｏＣ１の指定と同一の応答モード設定方法に従って、応答モードを使用しなければならない」、「ＰｏＣサービスインフラストラクチャは、ＰｏＣクライアントによって設定される場合、各メディアタイプに対して異なる受諾および拒否のルールを使用しなければならない」。

ＰｏＣ１は、メディア除外機能を含んでいない。これは、ＰｏＣ２で新規に提案されている機能である。ＰｏＣ２は、音声／トークバーストだけが可能なＰｏＣ１と比較して、ＰｏＣセッションの通信を、映像、テキストメッセージング等の新規のメディアタイプで充実させることになる。ＰｏＣ２セッションは、例えば、音声／トークバーストに並行して、映像を使用することができる。エンドユーザの視点からは、ＰｏＣセッションで使用される様々なメディアをユーザが制限することを要望する状況があり得る。例えば、ユーザは、音声／トークバーストメディアだけの受諾を要望し、映像メディアは要望しない場合がある。この理由は、映像の使用が適切でない環境若しくは状況にいる、または恐らく制限された帯域幅の範囲に存在する、またはバッテリレベルが低く映像表示が電力を消費し過ぎることがあることが分かっていることを含んでいる。受信者（すなわち、ＰｏＣ呼の着信ユーザ）こそが、発信ユーザのセッションで提案されるメディアを除外することを選択するのであり、ある種のメディアを送信しないことを選択する送信者ではない。

ＰｏＣ（そして、一般にＩＭＳ）は、ＳＩＰシグナリングが使用される制御プレーンと、ペイロード（音声、映像等）がＲＴＰ、ＭＳＲＰ等の種々のプロトコルを使用して転送されるメディアプレーンに分けられる。ＰｏＣセッション（または他のいずれかのＳＩＰセッション）をセットアップする場合、そのセッションにどのメディアが使用されるかについての情報は、ＳＩＰメッセージの一部である、マルチメディアセッション用のセッション記述プロトコルＳＤＰ（Session Description Protocol）［ＲＦＣ ２３２７］で転送される。これは、送信者から受信者へのメディアストリームをそろえるために使用される。送信者は、セッションで使用することを要望する各メディアタイプについての情報を送信し、受信者は、提案されているメディアのすべてまたはサブセットで返答することになる。

基本動作は、発信クライアントおよび着信クライアントがどの機能をともに可能であるかを判定することである。例えば、発信クライアントは、映像通信を可能にする高性能なカラー画面付きのカメラを有することがあるが、受信端末は、画面なしのロー年度端末である場合もあり、この場合は、映像セッションを開始する必要性がない。しかしながら、同一の機能がエンドユーザに示されることも可能であり、このエンドユーザは、通信相手とどの種類の通信で確立することを要望するかを判定することができる。

通常の場合、受信クライアントは、ＳＤＰで提案されるメディアのどれをセッションに対して受諾し得るかまたはすることになるかを着信セッションそれぞれに対して応答することになる。これには、いくつかの制約がある。

第１に、モバイル環境では、発信者によって提案されるメディアのいずれも受信者が受諾することができない場合は、エアインタフェース上では無駄な往復（ラウンドトリップ）が存在している。

第２に、メディア除外の概念は、誰からの呼に依存して異なるメディア除外を提供することを可能にする（例えば、「仕事の同僚には映像メディアを許可しないが、家族には許可する」）ように将来拡大されても良い。その場合、各クライアントは、すべてのアクセスルールを追跡する必要がある。これは、普通、ネットワークが扱うことである。

第３に、ＰｏＣには、自動応答機能が存在し、ＰｏＣセッションは自動的に応答され、セッションセットアップの高速化とユーザビリティのために、ユーザは明示的に応答は行わない。ＰｏＣ２の映像メディアに関しては、プライバシーの理由から自動応答を決して使用しないことが提案されている。この意味することは、映像を含むセッションはすべて、ユーザが映像を扱いたくない場合でさえも、ユーザからの手動応答を要求することである。一例としては、受信者が自動応答＝ＴＲＵＥ（真）、且つ映像メディア＝ＦＡＬＳＥ（偽）に設定している場合がある。これらの設定で受信者が音声と映像の両方を有するＰｏＣセッションへの招待を受ける場合、セッションメディアにおける映像は自動応答を無効にすることを意味するので、自動応答機能は使用され得ない。

上記の問題の１つ以上に取り組むことが要望されている。

メディア除外の１つのオプションは、各ＰｏＣクライアントに関してＰｏＣサーバにそのクライアントがどのメディアを扱うことを選んでいるかを提示するパラメータを設定し、次いで、このＰｏＣサーバがメディアプレーンで要望されないメディアを除外することである。この解決策では、ＰｏＣ用の制御プレーンは、ユーザが扱うことを要望しないメディアに関して不要なメディアパラメータ（ＳＤＰ）を依然として含むことになる。また、これは、ＰｏＣクライアントを実装する場合に、ＰｏＣクライアントが、どのメディア除外がＰｏＣサーバにすでに設定されているかについてと、制御プレーンに対して使用されているシグナリングとを相互に関係させる手段である必要があるだろうから、困難をもたらすだろう。

本発明の要約
本発明の第１の態様に従えば、プッシュツートークオーバセルラーサービスで使用する方法が提供される。この方法は、プッシュツートーク型のセッションを確立するために、第２の端末からの第１の端末を招待するメッセージであって、そのセッション中に第２の端末が第１の端末に送信することができるメディアタイプのリストを備えるメッセージを受信する工程と、そのメッセージの受信に応じて、少なくとも１つのメディアタイプの中の１つまたは各メディアタイプに関して、仮にそうであるとしたら、どの状況でも第１の端末がプッシュツートーク型のセッションで受諾するであろうメディアタイプを特定する情報に基づいて、第１の端末が第２の端末から受諾しないメディアタイプを除外するためにリストを検査し、適切な場合、第１の端末に検査したリストを備えるメッセージを転送する工程と、拡張マークアップ言語であるＸＭＬの文書形式で、前記情報の少なくとも一部を、遠隔サーバである、ＰｏＣ ＸＭＬ文書管理サーバであるＸＤＭＳから受信する工程とを備える。

この方法は、この情報から、第２の端末によって提案されるメディアタイプに第１の端末が受諾するであろうメディアタイプがないと判定される場合、第１の端末にメッセージを転送せず、第２の端末にセッションの招待を拒否するメッセージを送信する工程を備えてもよい。

この方法は、第１の端末から送信される、セッションを受諾し、検査したリストのメディアタイプを受諾可能と確認する応答メッセージを受信する工程と、第２の端末に応答メッセージを転送する工程とを備えてもよい。

この方法は、応答メッセージで受諾可能と確認されるメディアタイプに基づいって、セッションをセットアップする工程を備えてもよい。

この応答メッセージは、セッション開始プロトコルの２００ ＯＫメッセージでもよい。

この方法は、招待するメッセージの受信の前に、セッション開始プロトコルのＰＵＢＬＩＳＨメッセージで第１の端末から情報の少なくとも一部を受信する工程を備えてもよい。

この方法は、ＰＵＢＬＩＳＨメッセージを、セッション開始プロトコルの２００ ＯＫメッセージで応答確認する工程を備えてもよい。

この方法は、ＰｏＣ ＸＤＭＳである遠隔サーバから、この情報の少なくとも一部を送信する工程を備えてもよい。

この方法は、第１の端末の少なくとも１つの所定の機能に基づいて、この情報の少なくとも一部を判定する工程を備えてもよい。

第１の端末の少なくとも１つの所定の機能は、動作中のプッシュツートーク型サービスに関連してもよい。

この情報は、少なくとも１つのメディアタイプに関して、メディアタイプ自体だけでなく、少なくとも１つの他の所定の条件にも基づいて、第１の端末がプッシュツートーク型のセッションでそのメディアタイプを受諾するであろうか否かを特定してもよい。

この１つの所定の条件は、招待端末および／またはそのユーザのＩＤに関連してもよい。

この情報は、少なくとも１つのメディアタイプに関して、第１の端末がメディアタイプ自体だけに基づいて、プッシュツートーク型のセッションでそのメディアタイプを受諾するであろうか否かを特定してもよい。

デフォルトポリシーは、情報で指定されないメディアタイプに関しても参照されてもよい。

招待するメッセージは、セッション開始プロトコルのＩＮＶＩＴＥメッセージであってもよい。

セッション記述プロトコルパラメータが、メディアタイプのリストを特定するために使用されてもよい。

本発明の第２の態様に従えば、プッシュツートークオーバセルラーサービスで使用する装置が提供され、プッシュツートーク型のセッションの確立のために、第２の端末から第１の端末を招待するメッセージであって、セッション中の第２の端末が第１の端末に送信することができるメディアタイプのリストを備えるメッセージを受信する手段と、メッセージの受信に応じて、少なくとも１つのメディアタイプの中の１つまたは各メディアタイプに関して、仮にあるとしたら、どの状況でも第１の端末がプッシュツートーク型のセッションで受諾するであろうメディアタイプを指定する情報に基づいて、第１の端末が第２の端末から受諾しないメディアタイプを除外するためにリストを検査し、適切な場合、第１の端末に検査したリストを備えるメッセージを転送する手段と、拡張マークアップ言語であるＸＭＬの文書形式で、前記情報の少なくとも一部を、遠隔サーバである、ＰｏＣ ＸＭＬ文書管理サーバであるＸＤＭＳから受信する手段とを備える。

本発明の第３の態様に従えば、装置にロードされる場合に、その装置を本発明の第２の態様に従う装置として実現するオペレーティングプログラムが提供される。

本発明の第４の態様に従えば、装置で動作する場合、その装置に本発明の第１の態様に従う方法を実行させるオペレーティングプログラムが提供される。

このオペレーティングプログラムは、搬送媒体で搬送されてもよい。この搬送媒体は、伝送媒体でもよい。搬送媒体は、記憶媒体でもよい。

本発明の一実施形態は、様々なメディアを扱うクライアント（およびユーザ）がどのメディアを扱いたいかをサーバに伝えることを可能にする。この情報に基づいて、このサーバはシグナリングからその情報を取り去ることができ、かつそれによって要望するメディアの通信だけが可能になる。これは、メディアプレーンでブロックするよりもより効率的である。

本発明の一実施形態では、どのメディアを扱うかの決定ポイントは、各セッションに関してどのメディアタイプを扱い得るかをクライアントが回答する必要があることから、クライアントが別のノードに自分の代わりに動作するように命令するネットワークベースのアプローチに移行する。ネットワークのノードにおいてこの構成（コンフィグレーション）セットを用いることで、そのノード若しくは別のノードに制御シグナリングからメディアを積極的に取り去らせることが可能である。

これに基づいて、本発明の一実施形態は、次の１つ以上から恩恵を受けるであろう。それらは、（ａ）不要なメディアパラメータが取り除かれることにより、シグナリングパッケージが減少する、（ｂ）特定のセッションに対する全メディアが除外される場合、受信者への不要な制御信号トラフィックが減少する、（ｃ）クライアントは、除外設定とメディアパラメータが制御シグナリングでどのように処理されるかとを相互に関係させる必要がないので、クライアントの実装が容易になる、ならびに（ｄ）前述の自動応答と映像メディア除外との特別事例に加えて、ＰｏＣ１とＰｏＣ２とのセッション等の特定のＰｏＣの問題への解決策を提供する。

実施形態の詳細説明
本発明の一実施形態では、メディア制御パラメータの扱い（どのＳＤＰパラメータがＳＩＰ ＩＮＶＩＴＥメッセージで受諾されるか等）は、ネットワーク（例えば、ＰｏＣサーバ）に移動され、それによって、上述の制約の少なくとも一部を解消する。ＰｏＣサーバ（または他のノード）は、例えば、従前のプリファレンスおよびＰｏＣクライアントからＰｏＣサーバ（または他のノード）によって送信される設定に基づいて、制御シグナリングから除外メディアタイプに対するメディアパラメータを簡単に取り除くことができる。

本発明の一実施形態について、これより図１および２を参照して、より詳細に説明する。図１は、この実施形態のＰｏＣクライアントＡ、ＢとＰｏＣサーバＳとの間のメッセージ交換を示すメッセージ交換図である。図２は、外部サーバＥＳおよびＰｏＣクライアントＡ、ＢとＰｏＣサーバＳとの間の相互作用に加えて、ＰｏＣサーバＳの構成要素を概略的に示すブロック図である。ＰｏＣサーバＳは、招待受信部Ｓ１、招待処理部Ｓ３、招待転送部Ｓ５、およびメディアタイププリファレンスマネージャＳ７を備える。ＰｏＣサーバＳのこれらの要素は、管理部Ｓ９の全体的制御のもとで動作し、管理部Ｓ９は、Ｓ１、Ｓ３、Ｓ５、Ｓ７によって実行されないあらゆる処理および通信機能も取り扱う。

ステップ１で、ＰｏＣクライアントＡは、受諾を要望しないまたはできないメディアタイプについて、ＰｏＣサーバＳのメディアタイププリファレンスマネージャＳ７に通知する。これは、ＰｏＣクライアントが、そのメディアタイプを永続的若しくは一時的に、物理的に扱うことができないこと、またはユーザがそのメディアタイプの受信を要望しないこと、または他の理由に基づいてもよい。選択的には、ＰｏＣクライアントＡは、受諾するメディアタイプまたは上記との組み合わせをＰｏＣサーバＳに通知してもよい。この実施形態では、これは、より詳細に以下に説明するＳＩＰ ＰＵＢＬＩＳＨメッセージを使用して達成される。このメディアタイププリファレンスマネージャＳ７は、更なる参照用にこの情報を記憶する。

ステップ２で、ＰｏＣサーバＳはこのリクエストを応答確認する。これは、この実施形態では、ＳＩＰ ２００ ＯＫメッセージで達成される。

ステップ３で、ＰｏＣクライアントＢは、ＰｏＣクライアントＡとのＰｏＣセッションを確立する意向を指示し、同時にＰｏＣセッションで使用することを要望するメディアも指示する。これは、この実施形態では、ＳＩＰ ＩＮＶＩＴＥメッセージのＳＤＰ ＰＡＲＡＭＥＴＥＲＳに含められているＰｏＣセッションで使用することが意図されているメディアタイプのリストを有するＳＩＰ ＩＮＶＩＴＥメッセージを送信することによって達成される。例えば、これは、トークバースト、映像クリップ、画像等を指定してもよい。これは、招待受信部Ｓ１によってＰｏＣサーバＳで受信される。

ステップ４で、ＰｏＣサーバＳは、ＳＩＰ ＲＩＮＧＩＮＧ応答確認で応答する。

ステップ５で、ＳＩＰ ＩＮＶＩＴＥメッセージは、ＰｏＣサーバＳの招待転送部Ｓ５によってＰｏＣクライアントＡに転送される。しかしながら、そうする前に、招待処理部Ｓ３は、ＳＩＰ ＩＮＶＩＴＥメッセージのメディア項目リストを検査し、クライアントＡが受諾しないであろうメディアタイプを対象とする任意のＳＤＰ ＰＡＲＡＭＥＴＥＲＳを取り除く。この検査は、メディアタイププリファレンスマネージャＳ７からの情報を使用して実行される。

ステップ６で、ＰｏＣクライアントＡは、ＳＩＰ ２００ ＯＫメッセージで応答確認を行ない、セッションを受諾する。このメッセージは、ＳＤＰ ＰＡＲＡＭＥＴＥＲＳも含んでいて、また、ＰｏＣクライアントＡは扱うことを要望しないメディアタイプについての情報を受信していないだろうから、これらのパラメータは、ＰｏＣサーバＳおよびＰｏＣクライアントＢに決して戻されることはないであろう。

ステップ７で、２００ ＯＫ応答確認がＰｏＣクライアントＢに転送される。

ステップ８で、ＰｏＣクライアントＢは、ＰｏＣクライアントＡが応答確認しているメディアだけを使用してＰｏＣセッションをセットアップする。

ステップ９で、合意されているメディアが、ＰｏＣクライアントＢからＰｏＣクライアントＡに転送される。

ステップ１および２の代替として、あるいはこれらのステップに加えて、ＰｏＣサーバは、事前にまたはリクエスト時に、外部サーバＥＳからいくつかの所定のフォーマットでＰｏＣクライアントＡのメディアタイププリファレンスに関する情報を受信することは可能である。例えば、この情報は、ＰｏＣ ＸＤＭＳ（ＸＭＬ文書管理サーバ：XML Document Management Server）に記憶されているＸＭＬ（拡張マークアップ言語）文書で定義することができる。これは、個別ユーザ毎に除外を指定し得るより柔軟なメディア除外の使用を可能にすることになる。必然的に、この情報は、１つ以上のメディアタイプの中の１つまたは各メディアタイプに関して、仮にそうであるとしたら、どの状況でもＰｏＣクライアントＡは、プッシュツートークセッションで受諾するであろうメディアタイプを指定するであろう。これは、条件付でまたは条件なしで表現されてもよい。例えば、この情報は、ＰｏＣクライアントＡはＰｏＣクライアントＢからの映像は受諾するが、ＰｏＣクライアントＣからの映像は受諾しないと指定することができる。Ｊｏｅ Ｂｌｏｇｇｓからの画像は受諾してもよいが、Ｊｏｈｎ Ｓｍｉｔｈからの画像は受諾しなくてもよい。任意のＰｏＣクライアントまたはユーザからの音声を受諾してもよい。一定の日時に受信されるセッション招待に対してだけ、ある種のメディアタイプを受諾してもよい。他の多くのこのようなルールが明らかであろう。個々の項目が１つのメディアタイプまたは多くのメディアタイプ等に適用されてもよい。（少なくともこの柔軟性の一部は、上述のＳＩＰ ＰＵＢＬＩＳＨ方法を使用して実現することもできる）。

本発明の上記の実施形態と比較して、この課題の代替解決策（本発明を例示しない）は、ステップ３で、ＰｏＣサーバＳが要望しないメディアに関するメディア情報（ＳＤＰ）を取り去らないで、代わりにメディアプレーンだけでメディアのブロッキングを実行すること（ステップ８）であろう。しかしながら、この代替解決策は、本発明の実施形態と比較して非効率であろう。その理由は、（ａ）ＳＩＰシグナリングは、決して使用されない余計なＳＤＰ情報を運ぶ必要があるであろう。これは、場合によっては最小量のこともあるが、メディアに依存することになる。（ｂ）追加のメディア情報を受信する場合に「混乱」しないように、ＰｏＣクライアントＡは、扱うことができないメディアについての完全な知識を有することを要求されるであろう。（ｃ）いずれにしろ、ＰｏＣクライアントＡによって扱うことができないメディアをステップ８で送信すること、特に、無線で大きなメディアを送信することは無駄である。

これより、ＰｏＣクライアントＡがＰｏＣサーバＳにそのメディア除外設定の詳細をどのように発行するか（上記ステップ１および２）について、より詳細に説明する。本発明の一実施形態の提案は、どのメディアタイプを除外したいかをＰｏＣサーバＳに通知するために、ＰｏＣクライアントＡがＳＩＰ ＰＵＢＬＩＳＨメッセージを使用することである。一方法は、他のメディアは除外されると見なして、どのメディアをサポートしているかの点から除外を表現することだろう。本発明の一実施形態は、ＳＩＰ ＰＵＢＬＩＳＨ（または類似の）メッセージで、除外されるメディアが明示的に表現される明示的除外方法に基づいてもよいし、除外されないメディアが表現される暗示的除外方法に基づいてもよいし、またその組み合わせに基づいてもよい。

第１に、ＰｏＣクライアントＡは、除外情報を有するＳＤＰのボディを含むＳＩＰ ＰＵＢＬＩＳＨメッセージを構築する。この除外されるメディアタイプは、除外メディアのリストとして明示的に表現されるか、または除外されないメディアのリストとして暗示的に表現されるか、またはそれらの組み合わせで表現される。

第２に、ＳＩＰ ＰＵＢＬＩＳＨメッセージは、ユーザのＰｏＣサーバＳに送信される。

第３に、ＰｏＣサーバＳは、それを受諾する場合の２００ ＯＫ応答確認を返信し、そのユーザに対する着信セッションに対応して使用するために除外情報を記憶する。

この除外設定は、全着信セッションに対する一般設定として発行することができる、または、セッションの発信者に依存して、異なるメディアが除外されるようにユーザ毎に発行されてもよい。

メディア除外パラメータ設定の一特殊事例は、ユーザに代わってＰｏＣサーバＳ（および／またはサービスプロバイダ）がこれらのパラメータを設定する場合である。この一例は、ユーザがＰｏＣ１クライアントを有し、ＰｏＣ２システムに接続する場合である。ＰｏＣ１は、音声／トークバーストだけを扱うので、ＰｏＣ２システムは音声／トークバースト以外の全メディアタイプに対してメディア除外を設定することができる。このようにして、ＰｏＣ１クライアントとＰｏＣ２クライアントを使用するユーザは、同一のメカニズムで通信することができる。

これより、着信側がメディア除外を使用している場合のセッションセットアップについて、さらに詳細を説明する。

ＰｏＣセッションの着信側のＰｏＣサーバＳは、参加機能ＰＦ（Participating Function）と呼ばれる。ＰＦこそが、ＰｏＣセッションで使用される様々なメディアを禁止（除外）または許可するために、着信側のユーザ設定に基づいて動作する。

このＰＦが、そのユーザの中の１人宛の着信ＰｏＣセッションを受信する場合、このユーザがメディア除外設定を発行しているかどうかを判定する。この除外設定は、例えば、一般的でもよいし、発信ユーザに従って指定されてもよい。（アクセスリストのチェック等の、ＰＦがこの段階で実行することになる他のタスクが存在するが、ここでは詳述しない）。これらの設定に基づいて、ＰＦは、着信セッション内の除外メディアを差し引いたメディアに基づくサブセットに対してメディアリソースをセットアップすることになるであろう。同一の設定に基づいて、ＰＦは、そのメディアに関してＳＩＰメッセージ内のＳＤＰ情報を取り除き、受信クライアントにそのＳＩＰメッセージを送信することになる。このようにして、受信クライアントは、除外されているメディアに関連する任意の情報またはシグナリングを決して見ることはない。

一特殊事例は、着信セッションで指定されている全メディアタイプが受信ユーザで除外される場合である。この場合は、ＰｏＣサーバＳは、受信者の知識なしに、除外設定に基づいてＰｏＣセッションを拒否することができる、または、ＰｏＣセッションが要求されたが、ＰｏＣセッションの全メディアが除外されていたので確立されなかったことを受信者に通知してもよい。

別の特殊事例は、映像メディアのセッションに関するものである。上述のように、プライバシーの理由から、ＰｏＣ設定の「自動応答」は映像には決して適用されることはない。そのため、受信者は常にこのようなＰｏＣセッションを手動で受諾しなければならない。ユーザが映像を除外していると同時に「自動応答」設定にしている場合、本発明の一実施形態では、ＰｏＣサーバＳは、映像メディア情報を取り除くだろうから、この方法で、ＰｏＣセッションは映像なしのセッションとして処理することができ、これによって、自動応答機能を適用することができる。

本発明の一実施形態は、ＰｏＣとの関連でこれまで説明しているが、本発明がＰｏＣに限定されないことは理解されるだろう。「プッシュツートーク」サービスという用語は、本明細書では、本質的には、トランシーバ的サービスを識別するために使用されている。これらのサービスは、トークバーストの交換のために、２人以上のユーザを一緒に素早く接続することを可能にする。プッシュツートークサービスは、所与の時間に１人だけが話すことを可能にする点で、従来の音声通話とは異なる。話すためには、ユーザは「フロア（floor：発言権）」の制御を持たなければならない。制御は、通常、１人のユーザがフロア制御を解放するためにトークボタンを解放し、別のユーザがフロア制御を引き受けるためにトークボタンを押下することによって達成される。添付の請求の範囲で使用される用語「プッシュツートーク」は、特定のプロトコルの使用を含意することを意図するものでないことが理解されるべきである。

本発明の範囲は、トークセッションでのトークデータあるいは音声データの転送に限定されるものではなく、添付の請求の範囲は、データ転送セッションにおいて、音声データを含むがそれに限定されないあらゆる種類のデータの転送も網羅すると解釈されることも理解されるべきである。そのようなものであるから、「トークバーストリクエスト」および「トークバースト」等の用語は、トークデータすなわち音声データだけに限定されると解釈されるべきではないが、ＰｏＣ１の用語と一貫性を持たせるために使用されている。このような語句は、その意味内に、どの種類のデータの転送も含めることができる。ＰｏＣ２では、ＰｏＣ１の概念に直接対応する概念に対して、異なる用語が使用されることがある。例えば、語句「メディアバーストリクエスト」および「メディアバースト」が代わりに使用されることがある。

上記構成要素の１つ以上の動作が機器または装置で動作するプログラムによって制御されてもよいことは理解されるであろう。このオペレーティングプログラムは、コンピュータで読取可能な記憶媒体に記憶されてもよいし、または、例えば、インターネットウェブサイトから提供されるダウンロード可能なデータ信号等の信号で実現することができる。添付の請求の範囲は、オペレーティング（動作）プログラム自体で、または搬送媒体上のレコードとして、または信号として、または他の形態で、オペレーティングプログラムを含んでいると解釈されるべきである。

本発明の一実施形態で、２つのＰｏＣクライアントとＰｏＣサーバとの間のメッセージの交換を概略的に示すメッセージ交換図である。 図１のＰｏＣサーバの構成要素を概略的に示すブロック図で、且つＰｏＣサーバと図１の他の要素および外部サーバとの間の相互作用を示す図である。

Claims (21)

1. プッシュツートークオーバセルラーであるＰｏＣによるＰｏＣサービスで使用する方法であって、
   ＰｏＣサーバが、ＰｏＣセッションを確立するために、第２の端末から、第１の端末を招待するメッセージであって、前記ＰｏＣセッション中に前記第２の端末が前記第１の端末に送信することができるメディアタイプのリストを備えるメッセージを受信する工程と、
   前記ＰｏＣサーバは、適切な場合、前記メッセージを前記第１の端末へ転送する工程と、
   前記ＰｏＣサーバは、少なくとも１つのメディアタイプの中の１つまたは各メディアタイプに関して、どの状況でも前記第１の端末が前記ＰｏＣセッションで受諾するであろうメディアタイプを特定するメディアタイププリファレンス情報を受信する工程と、
   前記ＰｏＣサーバは、前記第１の端末が前記第２の端末から受諾しないメディアタイプを除外するために、前記メディアタイププリファレンス情報を参照して、前記リストを検査する工程とを備え、
   前記転送する工程において、前記ＰｏＣサーバは、適切な場合、前記第１の端末に前記検査したリストを備えるメッセージを転送し、
   前記メディアタイププリファレンス情報の少なくとも一部は、セッション開始プロトコルのＰＵＢＬＩＳＨメッセージで前記第１の端末から受信され、
   前記メディアタイププリファレンス情報の少なくとも一部は、拡張マークアップ言語であるＸＭＬの文書形式で、外部サーバである、ＰｏＣ ＸＭＬ文書管理サーバから受信される
   ことを特徴とする方法。
2. 前記メディアタイププリファレンス情報から、前記第２の端末によって提案されるメディアタイプに前記第１の端末が受諾するであろうメディアタイプがないと判定される場合、前記ＰｏＣサーバは、前記第１の端末に前記メッセージを転送せず、前記第２の端末に前記ＰｏＣセッションの招待を拒否するメッセージを送信する工程を更に備える
   ことを特徴とする請求項１に記載の方法。
3. 前記ＰｏＣサーバは、前記第１の端末から送信される、前記ＰｏＣセッションを受諾し、前記検査したリストのメディアタイプを受諾可能と確認する応答メッセージを受信する工程と、
   前記ＰｏＣサーバは、前記第２の端末に前記応答メッセージを転送する工程と
   を更に備えることを特徴とする請求項１または２に記載の方法。
4. 前記ＰｏＣサーバは、前記応答メッセージで受諾可能と確認されるメディアタイプに基づいて、前記ＰｏＣセッションをセットアップする工程を更に備える
   ことを特徴とする請求項３に記載の方法。
5. 前記応答メッセージは、前記セッション開始プロトコルの２００ ＯＫメッセージである
   ことを特徴とする請求項３または４に記載の方法。
6. 前記ＰｏＣサーバは、リクエストに応じて、前記ＰｏＣ ＸＭＬ文書管理サーバから、前記メディアタイププリファレンス情報の少なくとも一部を受信する工程を更に備える
   ことを請求項１乃至５のいずれか１項に記載の方法。
7. 前記ＰｏＣサーバは、前記ＰＵＢＬＩＳＨメッセージを、前記セッション開始プロトコルの２００ ＯＫメッセージで応答確認する工程を更に備える
   ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
8. 前記ＰｏＣ ＸＭＬ文書管理サーバから、前記メディアタイププリファレンス情報の少なくとも一部を送信する工程を更に備える
   ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
9. 前記ＰｏＣサーバは、前記第１の端末の少なくとも１つの所定の機能に基づいて、前記検査する工程において使用するための前記メディアタイププリファレンス情報の少なくとも一部を判定する工程を更に備える
   ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
10. 前記第１の端末の少なくとも１つの所定の機能は、動作中の前記ＰｏＣサービスに関連している
    ことを特徴とする請求項９に記載の方法。
11. 前記メディアタイププリファレンス情報は、少なくとも１つのメディアタイプに関して、メディアタイプ自体だけでなく、少なくとも１つの他の所定の条件にも基づいて、前記第１の端末が前記ＰｏＣセッションでそのメディアタイプを受諾するであろうか否かを特定する
    ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
12. 前記所定の条件は、前記第１の端末及びそのユーザの少なくとも一方のアイデンティティに関連している
    ことを特徴とする請求項１１に記載の方法。
13. 前記メディアタイププリファレンス情報は、少なくとも１つのメディアタイプに関して、前記第１の端末がメディアタイプ自体だけに基づいて、前記ＰｏＣセッションでそのメディアタイプを受諾するであろうか否かを特定する
    ことを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
14. デフォルトポリシーは、前記メディアタイププリファレンス情報で特定されないメディアタイプに関して参照される
    ことを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
15. 前記招待するメッセージは、前記セッション開始プロトコルのＩＮＶＩＴＥメッセージである
    ことを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
16. セッション記述プロトコルパラメータが、メディアタイプの前記リストを特定するために使用される
    ことを特徴とする請求項１乃至１５のいずれか１項に記載の方法。
17. プッシュツートークオーバセルラーであるＰｏＣによるＰｏＣサービスで使用する装置であって
    ＰｏＣセッションの確立のために、第２の端末から第１の端末を招待するメッセージであって、前記ＰｏＣセッション中に前記第２の端末が前記第１の端末に送信することができるメディアタイプのリストを備えるメッセージを受信する手段と、
    適切な場合、前記メッセージを前記第１の端末へ転送する手段と、
    少なくとも１つのメディアタイプの中の１つまたは各メディアタイプに関して、どの状況でも前記第１の端末が前記ＰｏＣセッションで受諾するであろうメディアタイプを特定するメディアタイププリファレンス情報を受信する手段と、
    前記第１の端末が前記第２の端末から受諾しないメディアタイプを除外するために、前記メディアタイププリファレンス情報を参照して、前記リストを検査する手段と、
    前記転送する手段は、適切な場合に、前記第１の端末に前記検査したリストを備えるメッセージを転送するように構成されていて、
    前記メディアタイププリファレンス情報の少なくとも一部は、セッション開始プロトコルのＰＵＢＬＩＳＨメッセージで前記第１の端末から受信され、
    前記メディアタイププリファレンス情報の少なくとも一部は、拡張マークアップ言語であるＸＭＬの文書形式で、外部サーバである、ＰｏＣ ＸＭＬ文書管理サーバから受信される
    ことを特徴とする装置。
18. 装置で動作する場合、その装置に請求項１乃至１６のいずれか１項に記載の方法を実行させるオペレーティングプログラム。
19. 搬送媒体で搬送されることを特徴とする請求項１８に記載のオペレーティングプログラム。
20. 前記搬送媒体は、伝送媒体である
    ことを特徴とする請求項１９に記載のオペレーティングプログラム。
21. 前記搬送媒体は、記憶媒体である
    ことを特徴とする請求項１９に記載のオペレーティングプログラム。

Images