(57)【要約】  プッシュツートーク型サービスで使用する方法が提供される。プッシュツートーク型のセッションを確立するために、第２の端末（Ｂ）からの第１の端末（Ａ）を招待するメッセージがサーバ（Ｓ）で受信される（３）。メッセージは、セッション中に第２の端末（Ｂ）が第１の端末（Ａ）に送信し得るメディアタイプのリストを備える。その前に、サーバ（Ｓ）は、第１の端末（Ａ）によって、少なくとも１つのメディアタイプの中の１つまたは各メディアタイプに関して、仮にあったとしたら、どの状況でも第１の端末（Ａ）がプッシュツートーク型のセッションで受諾するであろうメディアタイプを特定する情報が通知される。この招待するメッセージの受信に応じて、且つ情報に基づいて、第１の端末（Ａ）が第２の端末（Ｂ）から受諾しないであろうメディアタイプを取り除くために、メディアタイプのリストはサーバ（Ｓ）で検査される。リストの少なくとも１つのメディアタイプが残る場合、検査したリストを有する招待するメッセージが第１の端末へ転送される（５）。一実施形態では、招待するメッセージは、セッション開始プロトコル（ＳＩＰ）のＩＮＶＩＴＥメッセージであり、セッション記述プロトコル（ＳＤＰ）パラメータがメディアタイプのリストを特定するために使用される。プッシュツートーク型サービスは、プッシュツートークオーバーセルラー（ＰｏＣ）サービスでもよい。プッシュツートーク型サービスは、会議サービスでもよい。【選択図】  なし
2009514284.tif 000002
【特許請求の範囲】
【請求項１】
プッシュツートーク型サービスで使用する方法であって、
プッシュツートーク型のセッションを確立するために、第２の端末からの第１の端末を招待するメッセージであって、前記セッション中に前記第２の端末が前記第１の端末に送信することができるメディアタイプのリストを備えるメッセージを受信する工程と、
前記メッセージの受信に応じて、少なくとも１つのメディアタイプの中の１つまたは各メディアタイプに関して、仮にあるとしたら、どの状況でも前記第１の端末がプッシュツートーク型のセッションで受諾するであろうメディアタイプを特定する情報に基づいて、前記第１の端末が前記第２の端末から受諾しないメディアタイプを除外するために前記リストを検査し、適切な場合、前記第１の端末に前記検査したリストを備えるメッセージを転送する工程と
を備えることを特徴とする方法。
【請求項２】
前記情報から、前記第２の端末によって提案されるメディアタイプに前記第１の端末が受諾するであろうメディアタイプがないと判定される場合、前記第１の端末に前記メッセージを転送せず、前記第２の端末に前記セッションの招待を拒否するメッセージを送信する工程を更に備える
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記第１の端末から送信される、前記セッションを受諾し、前記検査したリストのメディアタイプを受諾可能と確認する応答メッセージを受信する工程と、
前記第２の端末に前記応答メッセージを転送する工程と
更に備えることを特徴とする請求項１または２に記載の方法。
【請求項４】
前記応答メッセージで受諾可能と確認されるメディアタイプに基づいて、前記セッションをセットアップする工程を更に備える
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記応答メッセージは、セッション開始プロトコルの２００  ＯＫメッセージである
ことを特徴とする請求項３または４に記載の方法。
【請求項６】
前記招待するメッセージの受信の前に、セッション開始プロトコルのＰＵＢＬＩＳＨメッセージで、前記第１の端末から、前記情報の少なくとも一部を受信する工程を更に備える
ことを請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記ＰＵＢＬＩＳＨメッセージを、前記セッション開始プロトコルの２００  ＯＫメッセージで応答確認する工程を更に備える
ことを特徴とする請求項６に記載の方法。
【請求項８】
遠隔サーバから、前記情報の少なくとも一部を受信する工程を更に備える
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記遠隔サーバは、ＰｏＣ拡張マークアップ言語ＸＭＬ文書管理サーバであるＸＤＭＳである
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記情報の少なくとも一部は、拡張マークアップ言語ＸＭＬ文書の形式である
ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
前記第１の端末の少なくとも１つの所定の機能に基づいて、前記情報の少なくとも一部を判定する工程を更に備える
ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
前記第１の端末の少なくとも１つの所定の機能は、動作中のプッシュツートーク型サービスに関連している
ことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記情報は、少なくとも１つのメディアタイプに関して、メディアタイプ自体だけでなく、少なくとも１つの他の所定の条件にも基づいて、第１の端末がプッシュツートーク型のセッションでそのメディアタイプを受諾するであろうか否かを特定する
ことを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
【請求項１４】
前記所定の条件は、前記招待する端末及びそのユーザの少なくとも一方のアイデンティティに関連している
ことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記情報は、少なくとも１つのメディアタイプに関して、前記第１の端末がメディアタイプ自体だけに基づいて、プッシュツートーク型のセッションでそのメディアタイプを受諾するであろうか否かを特定する
ことを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
【請求項１６】
デフォルトポリシーは、前記情報で特定されないメディアタイプに関して参照される
ことを特徴とする請求項１乃至１５のいずれか１項に記載の方法。
【請求項１７】
前記招待するメッセージは、前記セッション開始プロトコルのＩＮＶＩＴＥメッセージである
ことを特徴とする請求項１乃至１６のいずれか１項に記載の方法。
【請求項１８】
セッション記述プロトコルパラメータが、メディアタイプの前記リストを特定するために使用される
ことを特徴とする請求項１乃至１７のいずれか１項に記載の方法。
【請求項１９】
前記プッシュツートーク型サービスは、プッシュツートークオーバーセルラーサービスである
ことを特徴とする請求項１乃至１８のいずれか１項に記載の方法。
【請求項２０】
前記プッシュツートーク型サービスは、会議サービスである
ことを特徴とする請求項１乃至１９のいずれか１項に記載の方法。
【請求項２１】
プッシュツートーク型サービスで使用する装置であって
プッシュツートーク型のセッションの確立のために、第２の端末から第１の端末を招待するメッセージであって、前記セッション中に前記第２の端末が前記第１の端末に送信することができるメディアタイプのリストを備えるメッセージを受信する手段と、
前記メッセージの受信に応じて、少なくとも１つのメディアタイプの中の１つまたは各メディアタイプに関して、仮にあるとしたら、どの状況でも前記第１の端末がプッシュツートーク型のセッションで受諾するであろうメディアタイプを特定する情報に基づいて、前記第１の端末が前記第２の端末から受諾しないメディアタイプを除外するためにリストを検査し、適切な場合に、前記第１の端末にその検査したリストを備えるメッセージを転送する手段と
を備えることを特徴とする装置。
【請求項２２】
装置にロードされる場合に、その装置を請求項２１に従う装置として実現するオペレーティングプログラム。
【請求項２３】
装置で動作する場合、その装置に請求項１乃至２０のいずれか１項に記載の方法を実行させるオペレーティングプログラム。
【請求項２４】
搬送媒体で搬送されることを特徴とする請求項２２または２３に記載のオペレーティングプログラム。
【請求項２５】
前記搬送媒体は、伝送媒体である
ことを特徴とする請求項２４に記載のオペレーティングプログラム。
【請求項２６】
前記搬送媒体は、記憶媒体である
ことを特徴とする請求項２４に記載のオペレーティングプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の背景
１．本発明の分野
本発明は、例えば、いわゆるプッシュツートークオーバーセルラーサービス等の、プッシュツートーク型サービスで使用する方法および装置に関するものである。
【０００２】
２．関連技術の詳細
トランシーバ（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）［ＲＦＣ  ２３２７］で転送される。これは、送信者から受信者へのメディアストリームをそろえるために使用される。送信者は、セッションで使用することを要望する各メディアタイプについての情報を送信し、受信者は、提案されているメディアのすべてまたはサブセットで返答することになる。
【００１０】
基本動作は、発信クライアントおよび着信クライアントがどの機能をともに可能であるかを判定することである。例えば、発信クライアントは、映像通信を可能にする高性能なカラー画面付きのカメラを有することがあるが、受信端末は、画面なしのロー年度端末である場合もあり、この場合は、映像セッションを開始する必要性がない。しかしながら、同一の機能がエンドユーザに示されることも可能であり、このエンドユーザは、通信相手とどの種類の通信で確立することを要望するかを判定することができる。
【００１１】
通常の場合、受信クライアントは、ＳＤＰで提案されるメディアのどれをセッションに対して受諾し得るかまたはすることになるかを着信セッションそれぞれに対して応答することになる。これには、いくつかの制約がある。
【００１２】
第１に、モバイル環境では、発信者によって提案されるメディアのいずれも受信者が受諾することができない場合は、エアインタフェース上では無駄な往復（ラウンドトリップ）が存在している。
【００１３】
第２に、メディア除外の概念は、誰からの呼に依存して異なるメディア除外を提供することを可能にする（例えば、「仕事の同僚には映像メディアを許可しないが、家族には許可する」）ように将来拡大されても良い。その場合、各クライアントは、すべてのアクセスルールを追跡する必要がある。これは、普通、ネットワークが扱うことである。
【００１４】
第３に、ＰｏＣには、自動応答機能が存在し、ＰｏＣセッションは自動的に応答され、セッションセットアップの高速化とユーザビリティのために、ユーザは明示的に応答は行わない。ＰｏＣ２の映像メディアに関しては、プライバシーの理由から自動応答を決して使用しないことが提案されている。この意味することは、映像を含むセッションはすべて、ユーザが映像を扱いたくない場合でさえも、ユーザからの手動応答を要求することである。一例としては、受信者が自動応答＝ＴＲＵＥ（真）、且つ映像メディア＝ＦＡＬＳＥ（偽）に設定している場合がある。これらの設定で受信者が音声と映像の両方を有するＰｏＣセッションへの招待を受ける場合、セッションメディアにおける映像は自動応答を無効にすることを意味するので、自動応答機能は使用され得ない。
【００１５】
上記の問題の１つ以上に取り組むことが要望されている。
【００１６】
メディア除外の１つのオプションは、各ＰｏＣクライアントに関してＰｏＣサーバにそのクライアントがどのメディアを扱うことを選んでいるかを提示するパラメータを設定し、次いで、このＰｏＣサーバがメディアプレーンで要望されないメディアを除外することである。この解決策では、ＰｏＣ用の制御プレーンは、ユーザが扱うことを要望しないメディアに関して不要なメディアパラメータ（ＳＤＰ）を依然として含むことになる。また、これは、ＰｏＣクライアントを実装する場合に、ＰｏＣクライアントが、どのメディア除外がＰｏＣサーバにすでに設定されているかについてと、制御プレーンに対して使用されているシグナリングとを相互に関係させる手段である必要があるだろうから、困難をもたらすだろう。
【００１７】
本発明の要約
本発明の第１の態様に従えば、プッシュツートーク型サービスで使用する方法が提供される。この方法は、プッシュツートーク型のセッションを確立するために、第２の端末からの第１の端末を招待するメッセージであって、そのセッション中に第２の端末が第１の端末に送信することができるメディアタイプのリストを備えるメッセージを受信する工程と、そのメッセージの受信に応じて、少なくとも１つのメディアタイプの中の１つまたは各メディアタイプに関して、仮にそうであるとしたら、どの状況でも第１の端末がプッシュツートーク型のセッションで受諾するであろうメディアタイプを特定する情報に基づいて、第１の端末が第２の端末から受諾しないメディアタイプを除外するためにリストを検査し、適切な場合、第１の端末に検査したリストを備えるメッセージを転送する工程とを備える。
【００１８】
この方法は、この情報から、第２の端末によって提案されるメディアタイプに第１の端末が受諾するであろうメディアタイプがないと判定される場合、第１の端末にメッセージを転送せず、第２の端末にセッションの招待を拒否するメッセージを送信する工程を備えてもよい。
【００１９】
この方法は、第１の端末から送信される、セッションを受諾し、検査したリストのメディアタイプを受諾可能と確認する応答メッセージを受信する工程と、第２の端末に応答メッセージを転送する工程とを備えてもよい。
【００２０】
この方法は、応答メッセージで受諾可能と確認されるメディアタイプに基づいって、セッションをセットアップする工程を備えてもよい。
【００２１】
この応答メッセージは、セッション開始プロトコルの２００  ＯＫメッセージでもよい。
【００２２】
この方法は、招待するメッセージの受信の前に、セッション開始プロトコルのＰＵＢＬＩＳＨメッセージで第１の端末から情報の少なくとも一部を受信する工程を備えてもよい。
【００２３】
この方法は、ＰＵＢＬＩＳＨメッセージを、セッション開始プロトコルの２００  ＯＫメッセージで応答確認する工程を備えてもよい。
【００２４】
この方法は、遠隔サーバから、この情報の少なくとも一部を受信する工程を備えてもよい。
【００２５】
この遠隔サーバは、ＰｏＣ拡張マークアップ言語ＸＭＬ（Extensible Markup Language）文書管理サーバＸＤＭＳ（XML Document Management Server）であってもよい。
【００２６】
この情報の少なくとも一部は、拡張マークアップ言語ＸＭＬ文書の形式であってもよい。
【００２７】
この方法は、第１の端末の少なくとも１つの所定の機能に基づいて、この情報の少なくとも一部を判定する工程を備えてもよい。
【００２８】
第１の端末の少なくとも１つの所定の機能は、動作中のプッシュツートーク型サービスに関連してもよい。
【００２９】
この情報は、少なくとも１つのメディアタイプに関して、メディアタイプ自体だけでなく、少なくとも１つの他の所定の条件にも基づいて、第１の端末がプッシュツートーク型のセッションでそのメディアタイプを受諾するであろうか否かを特定してもよい。
【００３０】
この１つの所定の条件は、招待端末および／またはそのユーザのＩＤに関連してもよい。
【００３１】
この情報は、少なくとも１つのメディアタイプに関して、第１の端末がメディアタイプ自体だけに基づいて、プッシュツートーク型のセッションでそのメディアタイプを受諾するであろうか否かを特定してもよい。
【００３２】
デフォルトポリシーは、情報で指定されないメディアタイプに関しても参照されてもよい。
【００３３】
招待するメッセージは、セッション開始プロトコルのＩＮＶＩＴＥメッセージであってもよい。
【００３４】
セッション記述プロトコルパラメータが、メディアタイプのリストを特定するために使用されてもよい。
【００３５】
このプッシュツートーク型サービスは、プッシュツートークオーバーセルラー（ＰｏＣ）サービスであってもよい。
【００３６】
プッシュツートーク型サービスは、会議サービスであってもよい。
【００３７】
本発明の第２の態様に従えば、プッシュツートーク型サービスで使用する装置が提供され、プッシュツートーク型のセッションの確立のために、第２の端末から第１の端末を招待するメッセージであって、セッション中の第２の端末が第１の端末に送信することができるメディアタイプのリストを備えるメッセージを受信する手段と、メッセージの受信に応じて、少なくとも１つのメディアタイプの中の１つまたは各メディアタイプに関して、仮にあるとしたら、どの状況でも第１の端末がプッシュツートーク型のセッションで受諾するであろうメディアタイプを指定する情報に基づいて、第１の端末が第２の端末から受諾しないメディアタイプを除外するためにリストを検査し、適切な場合、第１の端末に検査したリストを備えるメッセージを転送する手段とを備える。
【００３８】
本発明の第３の態様に従えば、装置にロードされる場合に、その装置を本発明の第２の態様に従う装置として実現するオペレーティングプログラムが提供される。
【００３９】
本発明の第４の態様に従えば、装置で動作する場合、その装置に本発明の第１の態様に従う方法を実行させるオペレーティングプログラムが提供される。
【００４０】
このオペレーティングプログラムは、搬送媒体で搬送されてもよい。この搬送媒体は、伝送媒体でもよい。搬送媒体は、記憶媒体でもよい。
【００４１】
本発明の一実施形態は、様々なメディアを扱うクライアント（およびユーザ）がどのメディアを扱いたいかをサーバに伝えることを可能にする。この情報に基づいて、このサーバはシグナリングからその情報を取り去ることができ、かつそれによって要望するメディアの通信だけが可能になる。これは、メディアプレーンでブロックするよりもより効率的である。
【００４２】
本発明の一実施形態では、どのメディアを扱うかの決定ポイントは、各セッションに関してどのメディアタイプを扱い得るかをクライアントが回答する必要があることから、クライアントが別のノードに自分の代わりに動作するように命令するネットワークベースのアプローチに移行する。ネットワークのノードにおいてこの構成（コンフィグレーション）セットを用いることで、そのノード若しくは別のノードに制御シグナリングからメディアを積極的に取り去らせることが可能である。
【００４３】
これに基づいて、本発明の一実施形態は、次の１つ以上から恩恵を受けるであろう。それらは、（ａ）不要なメディアパラメータが取り除かれることにより、シグナリングパッケージが減少する、（ｂ）特定のセッションに対する全メディアが除外される場合、受信者への不要な制御信号トラフィックが減少する、（ｃ）クライアントは、除外設定とメディアパラメータが制御シグナリングでどのように処理されるかとを相互に関係させる必要がないので、クライアントの実装が容易になる、ならびに（ｄ）前述の自動応答と映像メディア除外との特別事例に加えて、ＰｏＣ１とＰｏＣ２とのセッション等の特定のＰｏＣの問題への解決策を提供する。
【発明を実施するための最良の形態】
【００４４】
実施形態の詳細説明
本発明の一実施形態では、メディア制御パラメータの扱い（どのＳＤＰパラメータがＳＩＰ  ＩＮＶＩＴＥメッセージで受諾されるか等）は、ネットワーク（例えば、ＰｏＣサーバ）に移動され、それによって、上述の制約の少なくとも一部を解消する。ＰｏＣサーバ（または他のノード）は、例えば、従前のプリファレンスおよびＰｏＣクライアントからＰｏＣサーバ（または他のノード）によって送信される設定に基づいて、制御シグナリングから除外メディアタイプに対するメディアパラメータを簡単に取り除くことができる。
【００４５】
本発明の一実施形態について、これより図１および２を参照して、より詳細に説明する。図１は、この実施形態のＰｏＣクライアントＡ、ＢとＰｏＣサーバＳとの間のメッセージ交換を示すメッセージ交換図である。図２は、外部サーバＥＳおよびＰｏＣクライアントＡ、ＢとＰｏＣサーバＳとの間の相互作用に加えて、ＰｏＣサーバＳの構成要素を概略的に示すブロック図である。ＰｏＣサーバＳは、招待受信部Ｓ１、招待処理部Ｓ３、招待転送部Ｓ５、およびメディアタイププリファレンスマネージャＳ７を備える。ＰｏＣサーバＳのこれらの要素は、管理部Ｓ９の全体的制御のもとで動作し、管理部Ｓ９は、Ｓ１、Ｓ３、Ｓ５、Ｓ７によって実行されないあらゆる処理および通信機能も取り扱う。
【００４６】
ステップ１で、ＰｏＣクライアントＡは、受諾を要望しないまたはできないメディアタイプについて、ＰｏＣサーバＳのメディアタイププリファレンスマネージャＳ７に通知する。これは、ＰｏＣクライアントが、そのメディアタイプを永続的若しくは一時的に、物理的に扱うことができないこと、またはユーザがそのメディアタイプの受信を要望しないこと、または他の理由に基づいてもよい。選択的には、ＰｏＣクライアントＡは、受諾するメディアタイプまたは上記との組み合わせをＰｏＣサーバＳに通知してもよい。この実施形態では、これは、より詳細に以下に説明するＳＩＰ  ＰＵＢＬＩＳＨメッセージを使用して達成される。このメディアタイププリファレンスマネージャＳ７は、更なる参照用にこの情報を記憶する。
【００４７】
ステップ２で、ＰｏＣサーバＳはこのリクエストを応答確認する。これは、この実施形態では、ＳＩＰ  ２００  ＯＫメッセージで達成される。
【００４８】
ステップ３で、ＰｏＣクライアントＢは、ＰｏＣクライアントＡとのＰｏＣセッションを確立する意向を指示し、同時にＰｏＣセッションで使用することを要望するメディアも指示する。これは、この実施形態では、ＳＩＰ  ＩＮＶＩＴＥメッセージのＳＤＰ  ＰＡＲＡＭＥＴＥＲＳに含められているＰｏＣセッションで使用することが意図されているメディアタイプのリストを有するＳＩＰ  ＩＮＶＩＴＥメッセージを送信することによって達成される。例えば、これは、トークバースト、映像クリップ、画像等を指定してもよい。これは、招待受信部Ｓ１によってＰｏＣサーバＳで受信される。
【００４９】
ステップ４で、ＰｏＣサーバＳは、ＳＩＰ  ＲＩＮＧＩＮＧ応答確認で応答する。
【００５０】
ステップ５で、ＳＩＰ  ＩＮＶＩＴＥメッセージは、ＰｏＣサーバＳの招待転送部Ｓ５によってＰｏＣクライアントＡに転送される。しかしながら、そうする前に、招待処理部Ｓ３は、ＳＩＰ  ＩＮＶＩＴＥメッセージのメディア項目リストを検査し、クライアントＡが受諾しないであろうメディアタイプを対象とする任意のＳＤＰ  ＰＡＲＡＭＥＴＥＲＳを取り除く。この検査は、メディアタイププリファレンスマネージャＳ７からの情報を使用して実行される。
【００５１】
ステップ６で、ＰｏＣクライアントＡは、ＳＩＰ  ２００  ＯＫメッセージで応答確認を行ない、セッションを受諾する。このメッセージは、ＳＤＰ  ＰＡＲＡＭＥＴＥＲＳも含んでいて、また、ＰｏＣクライアントＡは扱うことを要望しないメディアタイプについての情報を受信していないだろうから、これらのパラメータは、ＰｏＣサーバＳおよびＰｏＣクライアントＢに決して戻されることはないであろう。
【００５２】
ステップ７で、２００  ＯＫ応答確認がＰｏＣクライアントＢに転送される。
【００５３】
ステップ８で、ＰｏＣクライアントＢは、ＰｏＣクライアントＡが応答確認しているメディアだけを使用してＰｏＣセッションをセットアップする。
【００５４】
ステップ９で、合意されているメディアが、ＰｏＣクライアントＢからＰｏＣクライアントＡに転送される。
【００５５】
ステップ１および２の代替として、あるいはこれらのステップに加えて、ＰｏＣクライアントＡは、事前にまたはリクエスト時に、外部サーバＥＳからいくつかの所定のフォーマットでＰｏＣクライアントＡのメディアタイププリファレンスに関する情報を受信することは可能である。例えば、この情報は、ＰｏＣ  ＸＤＭＳ（ＸＭＬ文書管理サーバ：XML Document Management Server）に記憶されているＸＭＬ（拡張マークアップ言語）文書で定義することができる。これは、個別ユーザ毎に除外を指定し得るより柔軟なメディア除外の使用を可能にすることになる。必然的に、この情報は、１つ以上のメディアタイプの中の１つまたは各メディアタイプに関して、仮にそうであるとしたら、どの状況でもＰｏＣクライアントＡは、プッシュツートークセッションで受諾するであろうメディアタイプを指定するであろう。これは、条件付でまたは条件なしで表現されてもよい。例えば、この情報は、ＰｏＣクライアントＡはＰｏＣクライアントＢからの映像は受諾するが、ＰｏＣクライアントＣからの映像は受諾しないと指定することができる。Ｊｏｅ  Ｂｌｏｇｇｓからの画像は受諾してもよいが、Ｊｏｈｎ  Ｓｍｉｔｈからの画像は受諾しなくてもよい。任意のＰｏＣクライアントまたはユーザからの音声を受諾してもよい。一定の日時に受信されるセッション招待に対してだけ、ある種のメディアタイプを受諾してもよい。他の多くのこのようなルールが明らかであろう。個々の項目が１つのメディアタイプまたは多くのメディアタイプ等に適用されてもよい。（少なくともこの柔軟性の一部は、上述のＳＩＰ  ＰＵＢＬＩＳＨ方法を使用して実現することもできる）。
【００５６】
本発明の上記の実施形態と比較して、この課題の代替解決策（本発明を例示しない）は、ステップ３で、ＰｏＣサーバＳが要望しないメディアに関するメディア情報（ＳＤＰ）を取り去らないで、代わりにメディアプレーンだけでメディアのブロッキングを実行すること（ステップ８）であろう。しかしながら、この代替解決策は、本発明の実施形態と比較して非効率であろう。その理由は、（ａ）ＳＩＰシグナリングは、決して使用されない余計なＳＤＰ情報を運ぶ必要があるであろう。これは、場合によっては最小量のこともあるが、メディアに依存することになる。（ｂ）追加のメディア情報を受信する場合に「混乱」しないように、ＰｏＣクライアントＡは、扱うことができないメディアについての完全な知識を有することを要求されるであろう。（ｃ）いずれにしろ、ＰｏＣクライアントＡによって扱うことができないメディアをステップ８で送信すること、特に、無線で大きなメディアを送信することは無駄である。
【００５７】
これより、ＰｏＣクライアントＡがＰｏＣサーバＳにそのメディア除外設定の詳細をどのように発行するか（上記ステップ１および２）について、より詳細に説明する。本発明の一実施形態の提案は、どのメディアタイプを除外したいかをＰｏＣサーバＳに通知するために、ＰｏＣクライアントＡがＳＩＰ  ＰＵＢＬＩＳＨメッセージを使用することである。一方法は、他のメディアは除外されると見なして、どのメディアをサポートしているかの点から除外を表現することだろう。本発明の一実施形態は、ＳＩＰ  ＰＵＢＬＩＳＨ（または類似の）メッセージで、除外されるメディアが明示的に表現される明示的除外方法に基づいてもよいし、除外されないメディアが表現される暗示的除外方法に基づいてもよいし、またその組み合わせに基づいてもよい。
【００５８】
第１に、ＰｏＣクライアントＡは、除外情報を有するＳＤＰのボディを含むＳＩＰ  ＰＵＢＬＩＳＨメッセージを構築する。この除外されるメディアタイプは、除外メディアのリストとして明示的に表現されるか、または除外されないメディアのリストとして暗示的に表現されるか、またはそれらの組み合わせで表現される。
【００５９】
第２に、ＳＩＰ  ＰＵＢＬＩＳＨメッセージは、ユーザのＰｏＣサーバＳに送信される。
【００６０】
第３に、ＰｏＣサーバＳは、それを受諾する場合の２００  ＯＫ応答確認を返信し、そのユーザに対する着信セッションに対応して使用するために除外情報を記憶する。
【００６１】
この除外設定は、全着信セッションに対する一般設定として発行することができる、または、セッションの発信者に依存して、異なるメディアが除外されるようにユーザ毎に発行されてもよい。
【００６２】
メディア除外パラメータ設定の一特殊事例は、ユーザに代わってＰｏＣサーバＳ（および／またはサービスプロバイダ）がこれらのパラメータを設定する場合である。この一例は、ユーザがＰｏＣ１クライアントを有し、ＰｏＣ２システムに接続する場合である。ＰｏＣ１は、音声／トークバーストだけを扱うので、ＰｏＣ２システムは音声／トークバースト以外の全メディアタイプに対してメディア除外を設定することができる。このようにして、ＰｏＣ１クライアントとＰｏＣ２クライアントを使用するユーザは、同一のメカニズムで通信することができる。
【００６３】
これより、着信側がメディア除外を使用している場合のセッションセットアップについて、さらに詳細を説明する。
【００６４】
ＰｏＣセッションの着信側のＰｏＣサーバＳは、参加機能ＰＦ（Participating Function）と呼ばれる。ＰＦこそが、ＰｏＣセッションで使用される様々なメディアを禁止（除外）または許可するために、着信側のユーザ設定に基づいて動作する。
【００６５】
このＰＦが、そのユーザの中の１人宛の着信ＰｏＣセッションを受信する場合、このユーザがメディア除外設定を発行しているかどうかを判定する。この除外設定は、例えば、一般的でもよいし、発信ユーザに従って指定されてもよい。（アクセスリストのチェック等の、ＰＦがこの段階で実行することになる他のタスクが存在するが、ここでは詳述しない）。これらの設定に基づいて、ＰＦは、着信セッション内の除外メディアを差し引いたメディアに基づくサブセットに対してメディアリソースをセットアップすることになるであろう。同一の設定に基づいて、ＰＦは、そのメディアに関してＳＩＰメッセージ内のＳＤＰ情報を取り除き、受信クライアントにそのＳＩＰメッセージを送信することになる。このようにして、受信クライアントは、除外されているメディアに関連する任意の情報またはシグナリングを決して見ることはない。
【００６６】
一特殊事例は、着信セッションで指定されている全メディアタイプが受信ユーザで除外される場合である。この場合は、ＰｏＣサーバＳは、受信者の知識なしに、除外設定に基づいてＰｏＣセッションを拒否することができる、または、ＰｏＣセッションが要求されたが、ＰｏＣセッションの全メディアが除外されていたので確立されなかったことを受信者に通知してもよい。
【００６７】
別の特殊事例は、映像メディアのセッションに関するものである。上述のように、プライバシーの理由から、ＰｏＣ設定の「自動応答」は映像には決して適用されることはない。そのため、受信者は常にこのようなＰｏＣセッションを手動で受諾しなければならない。ユーザが映像を除外していると同時に「自動応答」設定にしている場合、本発明の一実施形態では、ＰｏＣサーバＳは、映像メディア情報を取り除くだろうから、この方法で、ＰｏＣセッションは映像なしのセッションとして処理することができ、これによって、自動応答機能を適用することができる。
【００６８】
本発明の一実施形態は、ＰｏＣとの関連でこれまで説明しているが、本発明がＰｏＣに限定されないことは理解されるだろう。「プッシュツートーク」サービスという用語は、本明細書では、本質的には、トランシーバ的サービスを識別するために使用されている。これらのサービスは、トークバーストの交換のために、２人以上のユーザを一緒に素早く接続することを可能にする。プッシュツートークサービスは、所与の時間に１人だけが話すことを可能にする点で、従来の音声通話とは異なる。話すためには、ユーザは「フロア（floor：発言権）」の制御を持たなければならない。制御は、通常、１人のユーザがフロア制御を解放するためにトークボタンを解放し、別のユーザがフロア制御を引き受けるためにトークボタンを押下することによって達成される。添付の請求の範囲で使用される用語「プッシュツートーク」は、特定のプロトコルの使用を含意することを意図するものでないことが理解されるべきである。
【００６９】
本発明の範囲は、トークセッションでのトークデータあるいは音声データの転送に限定されるものではなく、添付の請求の範囲は、データ転送セッションにおいて、音声データを含むがそれに限定されないあらゆる種類のデータの転送も網羅すると解釈されることも理解されるべきである。そのようなものであるから、「トークバーストリクエスト」および「トークバースト」等の用語は、トークデータすなわち音声データだけに限定されると解釈されるべきではないが、ＰｏＣ１の用語と一貫性を持たせるために使用されている。このような語句は、その意味内に、どの種類のデータの転送も含めることができる。ＰｏＣ２では、ＰｏＣ１の概念に直接対応する概念に対して、異なる用語が使用されることがある。例えば、語句「メディアバーストリクエスト」および「メディアバースト」が代わりに使用されることがある。
【００７０】
本発明の範囲は、参加者がフロア制御を与えられ、それによって会議での発言権または他の参加者へデータを転送する権利を与えられる会議システムを含むことを意図していることも理解されるべきである。
【００７１】
上記構成要素の１つ以上の動作が機器または装置で動作するプログラムによって制御されてもよいことは理解されるであろう。このオペレーティングプログラムは、コンピュータで読取可能な記憶媒体に記憶されてもよいし、または、例えば、インターネットウェブサイトから提供されるダウンロード可能なデータ信号等の信号で実現することができる。添付の請求の範囲は、オペレーティング（動作）プログラム自体で、または搬送媒体上のレコードとして、または信号として、または他の形態で、オペレーティングプログラムを含んでいると解釈されるべきである。
【図面の簡単な説明】
【００７２】
【図１】本発明の一実施形態で、２つのＰｏＣクライアントとＰｏＣサーバとの間のメッセージの交換を概略的に示すメッセージ交換図である。
【図２】図１のＰｏＣサーバの構成要素を概略的に示すブロック図で、且つＰｏＣサーバと図１の他の要素および外部サーバとの間の相互作用を示す図である。
【図１】
2009514284.tif 000003
【図２】
2009514284.tif 000004
【手続補正書】
【提出日】平成19年6月1日(2007.6.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
プッシュツートークオーバセルラーサービスで使用する方法であって、
プッシュツートーク型のセッションを確立するために、第２の端末からの第１の端末を招待するメッセージであって、前記セッション中に前記第２の端末が前記第１の端末に送信することができるメディアタイプのリストを備えるメッセージを受信する工程と、
前記メッセージの受信に応じて、少なくとも１つのメディアタイプの中の１つまたは各メディアタイプに関して、仮にあるとしたら、どの状況でも前記第１の端末がプッシュツートーク型のセッションで受諾するであろうメディアタイプを特定する情報に基づいて、前記第１の端末が前記第２の端末から受諾しないメディアタイプを除外するために前記リストを検査し、適切な場合、前記第１の端末に前記検査したリストを備えるメッセージを転送する工程と、
拡張マークアップ言語であるＸＭＬの文書形式で、前記情報の少なくとも一部を、遠隔サーバである、ＰｏＣ  ＸＭＬ文書管理サーバであるＸＤＭＳから受信する工程と
を備えることを特徴とする方法。
【請求項２】
前記情報から、前記第２の端末によって提案されるメディアタイプに前記第１の端末が受諾するであろうメディアタイプがないと判定される場合、前記第１の端末に前記メッセージを転送せず、前記第２の端末に前記セッションの招待を拒否するメッセージを送信する工程を更に備える
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記第１の端末から送信される、前記セッションを受諾し、前記検査したリストのメディアタイプを受諾可能と確認する応答メッセージを受信する工程と、
前記第２の端末に前記応答メッセージを転送する工程と
更に備えることを特徴とする請求項１または２に記載の方法。
【請求項４】
前記応答メッセージで受諾可能と確認されるメディアタイプに基づいて、前記セッションをセットアップする工程を更に備える
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記応答メッセージは、セッション開始プロトコルの２００  ＯＫメッセージである
ことを特徴とする請求項３または４に記載の方法。
【請求項６】
前記招待するメッセージの受信の前に、セッション開始プロトコルのＰＵＢＬＩＳＨメッセージで、前記第１の端末から、前記情報の少なくとも一部を受信する工程を更に備える
ことを請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記ＰＵＢＬＩＳＨメッセージを、前記セッション開始プロトコルの２００  ＯＫメッセージで応答確認する工程を更に備える
ことを特徴とする請求項６に記載の方法。
【請求項８】
前記遠隔サーバから、前記情報の少なくとも一部を送信する工程を更に備える
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記第１の端末の少なくとも１つの所定の機能に基づいて、前記情報の少なくとも一部を判定する工程を更に備える
ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
前記第１の端末の少なくとも１つの所定の機能は、動作中のプッシュツートーク型サービスに関連している
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記情報は、少なくとも１つのメディアタイプに関して、メディアタイプ自体だけでなく、少なくとも１つの他の所定の条件にも基づいて、第１の端末がプッシュツートーク型のセッションでそのメディアタイプを受諾するであろうか否かを特定する
ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
前記所定の条件は、前記招待する端末及びそのユーザの少なくとも一方のアイデンティティに関連している
ことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記情報は、少なくとも１つのメディアタイプに関して、前記第１の端末がメディアタイプ自体だけに基づいて、プッシュツートーク型のセッションでそのメディアタイプを受諾するであろうか否かを特定する
ことを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
【請求項１４】
デフォルトポリシーは、前記情報で特定されないメディアタイプに関して参照される
ことを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
【請求項１５】
前記招待するメッセージは、前記セッション開始プロトコルのＩＮＶＩＴＥメッセージである
ことを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
【請求項１６】
セッション記述プロトコルパラメータが、メディアタイプの前記リストを特定するために使用される
ことを特徴とする請求項１乃至１５のいずれか１項に記載の方法。
【請求項１７】
プッシュツートークオーバセルラーサービスで使用する装置であって
プッシュツートーク型のセッションの確立のために、第２の端末から第１の端末を招待するメッセージであって、前記セッション中に前記第２の端末が前記第１の端末に送信することができるメディアタイプのリストを備えるメッセージを受信する手段と、
前記メッセージの受信に応じて、少なくとも１つのメディアタイプの中の１つまたは各メディアタイプに関して、仮にあるとしたら、どの状況でも前記第１の端末がプッシュツートーク型のセッションで受諾するであろうメディアタイプを特定する情報に基づいて、前記第１の端末が前記第２の端末から受諾しないメディアタイプを除外するためにリストを検査し、適切な場合に、前記第１の端末にその検査したリストを備えるメッセージを転送する手段と、
拡張マークアップ言語であるＸＭＬの文書形式で、前記情報の少なくとも一部を、遠隔サーバである、ＰｏＣ  ＸＭＬ文書管理サーバであるＸＤＭＳから受信する手段と
を備えることを特徴とする装置。
【請求項１８】
装置にロードされる場合に、その装置を請求項１７に従う装置として実現するオペレーティングプログラム。
【請求項１９】
装置で動作する場合、その装置に請求項１乃至１６のいずれか１項に記載の方法を実行させるオペレーティングプログラム。
【請求項２０】
搬送媒体で搬送されることを特徴とする請求項１８または１９に記載のオペレーティングプログラム。
【請求項２１】
前記搬送媒体は、伝送媒体である
ことを特徴とする請求項２０に記載のオペレーティングプログラム。
【請求項２２】
前記搬送媒体は、記憶媒体である
ことを特徴とする請求項２０に記載のオペレーティングプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
本発明の背景
１．本発明の分野
本発明は、いわゆるプッシュツートークオーバーセルラサービスで使用する方法および装置に関するものである。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００５
【補正方法】変更
【補正の内容】
【０００５】
既存のプッシュツートーク（ＰＴＴ：Push-To-Talk）システムは、ユーザの１人に発言権を与え、通信中の他のユーザの発言権を拒否して、リスニングモードにすることを可能にするための、制御メカニズムを通常使用する。この制御メカニズムは、フロア制御、話者調停、トークバースト制御等と通常呼ばれる。例えば、オープンモバイルアライアンスは、トークバースト制御プロトコル（ＴＢＣＰ：Talk Burst Control Protocol）を含む、プッシュツートークオーバーセルラ（ＰｏＣ）システムの仕様に現在取り組んでいる。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１７
【補正方法】変更
【補正の内容】
【００１７】
本発明の要約
本発明の第１の態様に従えば、プッシュツートークオーバセルラーサービスで使用する方法が提供される。この方法は、プッシュツートーク型のセッションを確立するために、第２の端末からの第１の端末を招待するメッセージであって、そのセッション中に第２の端末が第１の端末に送信することができるメディアタイプのリストを備えるメッセージを受信する工程と、そのメッセージの受信に応じて、少なくとも１つのメディアタイプの中の１つまたは各メディアタイプに関して、仮にそうであるとしたら、どの状況でも第１の端末がプッシュツートーク型のセッションで受諾するであろうメディアタイプを特定する情報に基づいて、第１の端末が第２の端末から受諾しないメディアタイプを除外するためにリストを検査し、適切な場合、第１の端末に検査したリストを備えるメッセージを転送する工程と、拡張マークアップ言語であるＸＭＬの文書形式で、前記情報の少なくとも一部を、遠隔サーバである、ＰｏＣ  ＸＭＬ文書管理サーバであるＸＤＭＳから受信する工程とを備える。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００２４
【補正方法】変更
【補正の内容】
【００２４】
この方法は、ＰｏＣ  ＸＤＭＳである遠隔サーバから、この情報の少なくとも一部を送信する工程を備えてもよい。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００２５
【補正方法】削除
【補正の内容】
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００２６
【補正方法】削除
【補正の内容】
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】００３５
【補正方法】削除
【補正の内容】
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】００３６
【補正方法】削除
【補正の内容】
【手続補正１０】
【補正対象書類名】明細書
【補正対象項目名】００３７
【補正方法】変更
【補正の内容】
【００３７】
本発明の第２の態様に従えば、プッシュツートークオーバセルラーサービスで使用する装置が提供され、プッシュツートーク型のセッションの確立のために、第２の端末から第１の端末を招待するメッセージであって、セッション中の第２の端末が第１の端末に送信することができるメディアタイプのリストを備えるメッセージを受信する手段と、メッセージの受信に応じて、少なくとも１つのメディアタイプの中の１つまたは各メディアタイプに関して、仮にあるとしたら、どの状況でも第１の端末がプッシュツートーク型のセッションで受諾するであろうメディアタイプを指定する情報に基づいて、第１の端末が第２の端末から受諾しないメディアタイプを除外するためにリストを検査し、適切な場合、第１の端末に検査したリストを備えるメッセージを転送する手段と、拡張マークアップ言語であるＸＭＬの文書形式で、前記情報の少なくとも一部を、遠隔サーバである、ＰｏＣ  ＸＭＬ文書管理サーバであるＸＤＭＳから受信する手段とを備える。
【手続補正１１】
【補正対象書類名】明細書
【補正対象項目名】００５５
【補正方法】変更
【補正の内容】
【００５５】
ステップ１および２の代替として、あるいはこれらのステップに加えて、ＰｏＣサーバは、事前にまたはリクエスト時に、外部サーバＥＳからいくつかの所定のフォーマットでＰｏＣクライアントＡのメディアタイププリファレンスに関する情報を受信することは可能である。例えば、この情報は、ＰｏＣ  ＸＤＭＳ（ＸＭＬ文書管理サーバ：XML Document Management Server）に記憶されているＸＭＬ（拡張マークアップ言語）文書で定義することができる。これは、個別ユーザ毎に除外を指定し得るより柔軟なメディア除外の使用を可能にすることになる。必然的に、この情報は、１つ以上のメディアタイプの中の１つまたは各メディアタイプに関して、仮にそうであるとしたら、どの状況でもＰｏＣクライアントＡは、プッシュツートークセッションで受諾するであろうメディアタイプを指定するであろう。これは、条件付でまたは条件なしで表現されてもよい。例えば、この情報は、ＰｏＣクライアントＡはＰｏＣクライアントＢからの映像は受諾するが、ＰｏＣクライアントＣからの映像は受諾しないと指定することができる。Ｊｏｅ  Ｂｌｏｇｇｓからの画像は受諾してもよいが、Ｊｏｈｎ  Ｓｍｉｔｈからの画像は受諾しなくてもよい。任意のＰｏＣクライアントまたはユーザからの音声を受諾してもよい。一定の日時に受信されるセッション招待に対してだけ、ある種のメディアタイプを受諾してもよい。他の多くのこのようなルールが明らかであろう。個々の項目が１つのメディアタイプまたは多くのメディアタイプ等に適用されてもよい。（少なくともこの柔軟性の一部は、上述のＳＩＰ  ＰＵＢＬＩＳＨ方法を使用して実現することもできる）。
【手続補正１２】
【補正対象書類名】明細書
【補正対象項目名】００７０
【補正方法】削除
【補正の内容】
【国際調査報告】
2009514284.tif 000005
2009514284.tif 000006