(57)【要約】  セッションのセットアップおよび制御にＩＰマルチメディアサブシステムを利用して、マルチユーザ通信セッションへの招待を扱う方法が提供される。この方法では、ユーザアクセスが、ＩＰマルチメディアサブシステム内の２つ以上のユーザアクセスサーバによって制御される。この方法は、セッション開始ユーザから、潜在的な参加者として第２のユーザアクセスサーバによって所有される少なくとも１つのユーザグループを特定するセッション招待を、第１のユーザアクセスサーバで受信する工程と、このユーザグループのＩＤを有する招待を第２のユーザアクセスサーバに送信する工程と、この第２のユーザアクセスサーバにおいてグループ識別情報をグループメンバのアイデンティティのセットに解決する工程と、この第１のユーザアクセスサーバにこのグループメンバのアイデンティティを含む応答を送信する工程と、この第１のユーザアクセスサーバにおいて、この応答で識別されるグループメンバの少なくとも一部に招待を送信する工程とを備える。【選択図】  なし
2009512291.tif 000002
【特許請求の範囲】
【請求項１】
セッションのセットアップおよび制御にＩＰマルチメディアサブシステムを利用して、マルチユーザ通信セッションへの招待を扱う方法であって、
ユーザアクセスが、前記ＩＰマルチメディアサブシステム内の２つ以上のユーザアクセスサーバによって制御され、
前記方法は、
第１のユーザアクセスサーバにおいて、セッション開始ユーザから、潜在的な参加者として、第２のユーザアクセスサーバによって所有される少なくとも１つのユーザグループを識別するセッション招待を受信する工程と、
前記第２のユーザアクセスサーバに、前記ユーザグループの識別情報を含む招待を送信する工程と、
前記第２のユーザアクセスサーバにおいて、前記ユーザグループの識別情報をグループメンバのアイデンティティのセットに解決する工程と、
前記第１のユーザアクセスサーバへ、前記グループメンバのアイデンティティを含む応答を送信する工程と、
前記第１のユーザアクセスサーバにおいて、前記応答で識別されるグループメンバの少なくとも一部に招待を送信する工程と
を備えることを特徴とする方法。
【請求項２】
前記セッションは、プッシュツートークセッションであり、
前記ユーザアクセスサーバは、プッシュツートークサーバであり、
前記ユーザは、プッシュツートーククライアントであり、
前記第１のユーザアクセスサーバは、制御プッシュツートークサーバとして動作し、
前記第２のユーザアクセスサーバは、参加プッシュツートークサーバとして動作する
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記第２のユーザアクセスサーバにおいて、前記識別されるグループメンバの前記セッションへの招待を認可するための事前設定ポリシーを使用する工程を更に備える
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記第２のユーザアクセスサーバにおいて、前記識別されるグループメンバの前記セッションへの招待をリクエストするユーザを認可するための事前設定ポリシーを使用する工程を更に備える
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記事前設定ポリシーは、続行するための条件として、前記リクエストするユーザが前記事前設定グループのメンバであることを要求する
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記第１のユーザアクセスサーバにおける前記応答の受信時、事前設定ポリシーに従って前記グループメンバの１つへの招待を送信する工程を更に備える
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記事前設定ポリシーは、それ自体がグループ識別情報であるグループメンバへの招待の送信を防止する
ことを特徴とする請求項６に記載の方法。
【請求項８】
前記事前設定ポリシーは、事前設定数の入れ子になるレベルまでそれ自体がグループ識別情報であるグループメンバへの招待の送信を許容する
ことを特徴とする請求項６に記載の方法。
【請求項９】
ＩＰマルチメディアサブシステムで使用するユーザアクセスサーバであって、
セッション開始ユーザから、潜在的な参加者として、第２のユーザアクセスサーバによって所有される少なくとも１つのユーザグループを識別するセッション招待を受信する手段と、
前記第２のユーザアクセスサーバへ、前記ユーザグループの識別情報を含む招待を送信する手段と、
前記ユーザグループの識別情報から前記第２のアクセスサーバによって解決されるグループメンバのアイデンティティを有する応答を、前記第２のユーザアクセスサーバから受信する手段と、
前記応答で識別されるグループメンバの少なくとも一部へ招待を送信する手段と
を備えることを特徴とするユーザアクセスサーバ。
【請求項１０】
ＩＰマルチメディアサブシステムで使用するユーザアクセスサーバであって、
別のユーザアクセスサーバから、受信サーバによって所有されるユーザグループの識別情報を含む招待を受信する手段と、
前記ユーザグループの識別情報をグループメンバのアイデンティティのセットに解決する手段と、
前記第１のユーザアクセスサーバへ、前記グループメンバのアイデンティティを含む応答を送信する手段と
を備えることを特徴とするユーザアクセスサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の分野
本発明は、マルチユーザ通信セッションへの招待を扱う（処理する：handling）方法および装置に関するものである。本発明は、必ずしも必要ではないが、特に、プッシュツートーク等の会議タイプのセッションに適用可能である。
【０００２】
本発明の背景
トランシーバ（walkie-talkie：ウォーキートーキー）タイプのサービスは、相互間で短いメッセージを簡単に通信したいと要望するユーザの間で長い間にわたり知られているものである。従来、このようなサービスは、無線スペクトラムの専用部分を利用する双方向携帯無線によって提供されているが、この双方向携帯無線は、同種の端末を利用し、かつ比較的短距離の無線の動作範囲内に存在する事前に選択された小グループのユーザと通信することだけを可能にする。最近になって、既存のセルラー電話インフラストラクチャに便乗する（piggy-back：ピギーバックする）サービスが、米国で導入されている。しかしながら、このサービスは本質的に独自仕様であり、ユーザが異なるオペレータネットワーク間で通信することは許容されていない。
【０００３】
トランシーバタイプのサービスの使用を拡大するための試みには、セルラーネットワーク上で提供されるトランシーバサービスのネットワーク間運用（operability：オペラビリティ）を可能にする適切なプロトコルの標準化を目的として、オープンモバイルアライアンス（ｗｗｗ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｏｒｇ）として知られる産業団体が設立されている。様々な標準によって確立されているサービスは、ＰｏＣ（Push to talk over Cellular：プッシュツートークオーバセルラー）として知られている。このＰｏＣは、（ＳＩＰ  ＡＳとして動作する）ＰｏＣサーバによってＰｏＣセッションのセットアップおよび制御を扱うために、ＩＰマルチメディアサブシステム（ＩＭＳ：IP Multimedia Subsystem）を使用する。ＰｏＣは、パケット交換アクセスネットワークを通じて関連する音声データを転送することを提案している。ＧＳＭおよびＵＭＴＳの場合、これは、汎用パケット無線サービス（ＧＰＲＳ：General Packet Radio Service）アクセスネットワークとなる。他のネットワークアーキテクチャでは、類似のパケット交換アクセスネットワークは、トークデータ（talk data）を転送するために利用されることになる。プッシュツートークサービスは、回線交換アクセスネットワーク上でも提供されてもよいが、好ましい選択肢（オプション）ではない。
【０００４】
現在のＰｏＣの状態は、リリース１．０に提示されている。
【０００５】
発明の要約
ＰｏＣリリース１．０は、複数のユーザが共通のＰｏＣセッションに参加してもよい会議機能を提供する。様々なユーザが様々なオペレータネットワークに登録されているだろうから、各参加者が異なるＰｏＣサーバと関係することが可能である。このような状況では、ＰｏＣサーバの１つ、典型的には、開始ユーザに関連するサーバが、「会議ブリッジ」として動作し、フロア（floor：発言権）制御（すなわち、参加者へのトークスロットの割当）を行うＰｏＣ制御機能を実行するように設計されている。他のＰｏＣサーバは、参加ＰｏＣサーバと呼ばれる。
【０００６】
ユーザは、アドホックベースで他のユーザグループとの通信を確立することができる、すなわち、ユーザは、自身の電話帳からいくつかのユーザを選択して、自身の端末でＰｏＣボタンを押下することで、その時に応じられる全ユーザと通信を確立される。ＰｏＣは、ユーザが人のグループ（ＯＭＡ規格では「事前設定ＰｏＣグループ」と呼ばれる）を定義することも許容し、ここでは、グループと対応するＰｏＣグループアイデンティティは、ホームネットワークのユーザのＰｏＣサーバに記憶される。一旦グループが定義されると、ユーザは、グループアイデンティティを含んでいるＩＮＶＩＴＥを単に送信することによって、利用可能なグループのメンバとのＰｏＣセッションを開始することができる。
【０００７】
ここで、ユーザからアドホックＰｏＣグループセッションを確立するためのリクエストを受信するＰｏＣサーバについて検討すると、このリクエストは、招待するＰｏＣユーザのリストを含んでいる。個別のＰｏＣユーザに対応するユーザアイデンティティ（ユニバーサルリソースロケータ（Universal Resource Locator）あるいはＵＲＬの形態である）に対して、ＰｏＣサーバは、ＰｏＣリリース１．０の手順を使用して、全く問題なくＰｏＣユーザを招待することができる。これには、宛先ユーザを担当すると識別されるＰｏＣサーバへのＩＮＶＩＴＥの転送を含み、ここで、転送されるＩＮＶＩＴＥは、機能（feature）タグ「ｉｓｆｏｃｕｓ」を含んでいる。このタグは、送信ＰｏＣサーバがＰｏＣグループセッションのコントローラであることを識別する。受信サーバは、このタグを認識し、それに応じて、自装置を制御サーバとして確立することない。受信サーバは、自装置が担当する宛先ユーザ（群）にＩＮＶＩＴＥを単に転送する。
【０００８】
発信ユーザによって送信されるＩＮＶＩＴＥが制御ＰｏＣサーバによって「所有」されるＰｏＣグループに対応するアイデンティティ（ＵＲＬ）を含んでいる場合、サーバは、単にグループを展開して、グループメンバに関連するＰｏＣサーバ（群）にＩＮＶＩＴＥを転送する。本来のＩＮＶＩＴＥが制御サーバ以外のＰｏＣサーバによって所有されるＰｏＣグループアイデンティティを含んでいる場合、この制御サーバは、その所有するサーバにＩＮＶＩＴＥを転送することになる。これが、問題の始まりとなる。つまり、この状況で、ＰｏＣリリース１．０は、受信ＰｏＣサーバにＩＮＶＩＴＥを拒否することを強要するからである。この特徴は、特定のグループを所有するＰｏＣサーバで、ＰｏＣセッションの制御を維持し、それによって１つのＰｏＣセッションに対して複数の制御ＰｏＣサーバが確立することを防止することが意図されているものである。
【０００９】
複数の制御ＰｏＣサーバの問題の解決策は、どれがコントローラであるかの交渉および複数のＰｏＣサーバを連鎖させることを介在させることがある。しかしながら、このような解決策は、複雑になるだろうし、「無限」ループの設定になりかねない。ＰｏＣグループがアドホックＰｏＣセッションに招待される場合、ＰｏＣグループの状態を決定する問題もある。例えば、事前設定ＰｏＣグループのメンバ（何らかの理由でアドホックＰｏＣセッションの一部でない）がその事前設定ＰｏＣグループのＰｏＣグループセッションを開始する場合、そのメンバは、アドホックＰｏＣグループセッションに加えられるものとするか、それとも別のＰｏＣグループセッションが確立されるものとするかである。これらの「葛藤（conflict）」を扱うポリシーはどれも、どうしても複雑になる。
【００１０】
事前設定グループを介在するＰｏＣセッションの場合に生じる恐れがある更なる問題は、いくつかの「入れ子になっている（nested）」事前設定グループに属するユーザの問題である。これは、同一のセッションで複数の招待を受信するユーザを生じることになる。これは、迷惑をかけることになり、また、ネットワークリソースの無駄（アクセスネットワークがセルラーネットワークの場合に特に問題である）にもなるであろう。
【００１１】
上記の問題に類似の問題は、例えば、インスタントメッセージングサービス等のＰｏＣ以外の他のＩＭＳベースのサービスの場合にも生じることが理解されるであろう。
【００１２】
本発明の第１の態様に従えば、セッションのセットアップおよび制御にＩＰマルチメディアサブシステムを利用して、マルチユーザ通信セッションへの招待を扱う方法が提供される。ここで、ＩＰマルチメディアサブシステム内の２つ以上のユーザアクセスサーバによってユーザアクセスが制御される。この方法は、
第１のユーザアクセスサーバにおいて、セッション開始ユーザからの、潜在的な参加者として、第２のユーザアクセスサーバによって所有される少なくとも１つのユーザグループを識別するセッション招待を受信する工程と、
第２のユーザアクセスサーバに、このユーザグループの識別情報を含む招待を送信する工程と、
この第２のユーザアクセスサーバにおいて、ユーザグループの識別情報をグループメンバのアイデンティティのセットに解決する工程と、
この第１のユーザアクセスサーバへ、このグループメンバのアイデンティティを含む応答を送信する工程と、
この第１のユーザアクセスサーバにおいて、この応答で識別されるグループメンバの少なくとも一部に招待を送信する工程と
を備える。
【００１３】
本発明の特有の用途は、例えば、プッシュツートークオーバセルラー（ＰｏＣ：Push-to-talk over Cellular）等のプッシュツートークサービスの提供にある。この用途では、前述のユーザアクセスサーバはプッシュツートークサーバであり、前述のユーザはプッシュツートーククライアントである。前述の第１のユーザアクセスサーバは、制御ＰｏＣサーバとして動作し、これに対して、前述の第２のユーザアクセスサーバは、制御サーバではなく、参加ＰｏＣサーバとして動作する。制御ＰｏＣサーバから複数のＰｏＣサーバが連絡を受ける場合、他のサーバは、すべて参加ＰｏＣサーバとして動作する。
【００１４】
この方法は、第２のユーザアクセスサーバにおいて、識別されるグループメンバのセッションへの招待を認可するための事前設定ポリシーを使用することを備えてもよい。認可の失敗は、招待の拒否となる。
【００１５】
この方法は、第２のユーザアクセスサーバにおいて、識別されるグループメンバのセッションへの招待をリクエストするユーザを認可するための事前設定ポリシーの使用することを備えてもよい。この事前設定ポリシーは、続行するための条件として、リクエストするユーザが事前設定グループのメンバであることを要求してもよい。認可の失敗は、招待の拒否となる。
【００１６】
この方法は、第１のユーザアクセスサーバにおける応答の受信時、事前設定ポリシーに従ってグループのメンバへの１つへ招待を送信することを備えてもよい。このポリシーは、それ自体がグループ識別情報であるグループメンバへの招待の送信を防止してもよい。このポリシーが、それ自体がグループ識別情報であるグループメンバへの招待の送信を許容する場合、メンバのアイデンティティに解決される入れ子になっているグループ識別情報の数に上限を設けてもよい。
【００１７】
本発明の第２の態様に従えば、ＩＰマルチメディアサブシステムで使用するユーザアクセスサーバが提供される。このサーバは、
セッション開始ユーザからの、潜在的な参加者として、第２のユーザアクセスサーバによって所有される少なくとも１つのユーザグループを識別するセッション招待を受信する手段と、
第２のユーザアクセスサーバへ、このユーザグループの識別情報を含む招待を送信する手段と、
このユーザグループの識別情報から第２のアクセスサーバによって解決されるグループメンバのアイデンティティを有する応答を、この第２のユーザアクセスサーバから受信する手段と、
この応答で識別されるグループメンバの少なくとも一部へ招待を送信する手段と
を備える。
【００１８】
本発明の第３の態様に従えば、ＩＰマルチメディアサブシステムで使用するユーザアクセスサーバが提供される。このサーバは、
別のユーザアクセスサーバから、自サーバによって所有されるユーザグループの識別情報を含む招待を受信する手段と、
前記ユーザグループの識別情報をグループメンバのアイデンティティのセットに解決する手段と、
前述の第１のユーザアクセスサーバへ、このグループメンバのアイデンティティを含む応答を送信する手段と
を備える。
【発明を実施するための最良の形態】
【００１９】
プッシュツートークオーバセルラー（ＰｏＣ：Push-to-talk over Cellular）クライアント（クライアントＡ）は、ＯＭＡ  ＰｏＣによって定義される手順を使用して、ＰｏＣグループセッションを開始する。ＰｏＣグループセッションは、事前設定セッションを使用することができる、またオンデマンドセッションを使用することができる。事前設定セッションの場合、ＰｏＣクライアントは、ＩＮＶＩＴＥを使用して（通常ＰｏＣクライアントがＩＭＳに登録する場合に）、ホームネットワークの自身のＰｏＣサーバとのＳＩＰセッションを確立する。ＳＩＰセッションが一旦確立されると、ＰｏＣクライアントは、事前設定セッションおよびＳＩＰ  ＲＥＦＥＲリクエストを使用して、ＰｏＣセッションを開始することができる。オンデマンドセッションの場合、ＰｏＣクライアントは、最初に、事前設定セッションを確立することなしに、ＳＩＰ  ＩＮＶＩＴＥリクエストを直接使用して、ＰｏＣセッションを開始する。
【００２０】
招待対象のユーザのリストは、開始者のホームＰＯＣサーバに送信されるＳＩＰリクエスト（典型的には、ＳＩＰ  ＩＮＶＩＴＥ）に含まれる。ここで検討する例では、招待するユーザのリストは、個別ＰｏＣユーザのＰｏＣアドレス（ＵＲＩ）と事前設定ＰｏＣグループのＰｏＣグループアイデンティティとの混合で構成される。図１は、例としてオンデマンドシグナリングを使用する、アドホックＰｏＣグループセッションを想定して、ＰｏＣセッション確立に関連するシグナリングフローを示している。同一の原理を、事前設定セッションシグナリングを使用するアドホックＰｏＣグループセッション、ならびにオンデマンドシグナリング若しくは事前設定セッションシグナリングを使用する事前設定ＰｏＣグループセッションにも適用される。
【００２１】
シグナリングのステップは、以下の通りである。
【００２２】
１．ＰｏＣクライアントＡは、会議ＵＲＩ（典型的には、クライアントでの「出荷時」設定）によって識別されるそのホームＰｏＣサーバにＳＩＰ  ＩＮＶＩＴＥリクエストを送信する。このＳＩＰ  ＩＮＶＩＴＥリクエストは、ＰｏＣユーザと、事前設定グループであるグループＸおよびグループＹを識別する２つのＰｏＣグループアイデンティティとを含んでいる。
【００２３】
２＆４．ＰｏＣサーバＡ／Ｘ１は、ＳＩＰ  ＩＮＶＩＴＥリクエストをアドホックＰｏＣグループセッションの初期設定であることを識別し、招待リストに従って招待を送信することを開始する。この招待は、ＰｏＣサーバＡ／Ｘ１が確立されるＰｏＣグループセッションのコントローラであることを示すために機能タグ「ｉｓｆｏｃｕｓ」を含んでいる。個別のＰｏＣユーザへの招待の送信は、ステップ４で代表され、ここで、参加サーバは、個々のサーバＢ１〜Ｂｎで示される。
【００２４】
３．受信サーバの１つは、グループＸの所有者であるＰｏＣサーバＸ２である。ＰｏＣサーバＸ２（事前設定ＰｏＣグループを扱うＰｏＣサーバ）は、ＩＮＶＩＴＥに含まれる機能タグ「ｉｎｆｏｃｕｓ」を検出し、以下のステップを実行する。
【００２５】
ａ）自装置のポリシーに従って、グループＸを別のＰｏＣセッションに招待することを許可しているかどうかをチェックする。このポリシーは、事前設定ＰｏＣグループ毎であってもよいし、包括的なＰｏＣサービスポリシーであってもよい。この例では、招待は許可されている。
【００２６】
ｂ）次いで、開始者を認可する。これは、招待側のＰｏＣユーザがグループＸのメンバであるかどうかをチェックすることによって実行することができる。この例では、ＰｏＣユーザはメンバである。これは、Ｐ−Ａｓｓｅｒｔｅｄ−ＩｄｅｎｔｉｔｙヘッダまたはＩＮＶＩＴＥのＦｒｏｍヘッダを使用して実行することができる。選択的には、認可は、グループ所有者によって定義されるグループポリシー（例えば、「ホワイト」リスト）に基づいてもよいし、または、オペレータ定義のポリシーに基づいてもよい。
【００２７】
ｃ）ＰｏＣグループのメンバのリストを含むＳＩＰ  ３ｘｘ応答またはＳＩＰ  ４ｘｘ応答をＰｏＣサーバＡ／Ｘ１へ返信する。図では、ＳＩＰ  ３００「Ｍｕｌｔｉｐｌｅ  Ｃｈｏｉｃｅｓ（複数選択）」応答が、ＰｏＣサーバＡ／Ｘ１へ送信される。このメンバのリストは、個別のＰｏＣユーザと別のＰｏＣグループの両方を含んでいてもよい。
［  チェックａ）に従って、グループが別のＰｏＣセッションに招待され得ない場合、ＩＮＶＩＴＥは拒否される。同様に、チェックｂ）に従って、招待側のユーザがグループのメンバでない場合、ＩＮＶＩＴＥは拒否される。もちろん、このような状況でどのような行動を取るべきかを判定するために、代替ポリシーが定義されてもよい。］
４．ＰｏＣサーバＡ／Ｘ１は、リストを受信し、以下を実行する。
【００２８】
ａ）自身のポリシーをチェックし、ＳＩＰ  ３００に含まれるＰｏＣユーザのセットを招待することを決定する。応答に含まれるグループアイデンティティはすべて拒否する。
【００２９】
ｂ）個別のクライアント（およびグループ）にＩＮＶＩＴＥを重複して送信することを回避するために、リストから既に招待しているユーザを除去する。
【００３０】
ｃ）リスト上の残りのユーザを招待することにし、また、各アドレスにＩＮＶＩＴＥリクエストを送信する。
【００３１】
５＆６．本来のＩＮＶＩＴＥの別の受信者は、グループＹの所有者であるＰｏＣサーバＸ３である。ＰｏＣサーバＸ３は、サーバＸ２が実行したチェックと同じチェックを実行し、ＩＮＶＩＴＥを受け入れると想定すると、グループＹの全メンバを含むＳＩＰ  ３００「Ｍｕｌｔｉｐｌｅ  Ｃｈｏｉｃｅｓ」応答を返信する。この場合もやはり、メンバのリストは、個別のＰｏＣユーザと他のＰｏＣグループの両方を含むことができる。ＰｏＣサーバは、上記のチェックａ）〜ｃ）を繰り返す。
【００３２】
この例では、制御ＰｏＣは、応答メッセージで識別される追加のグループを拒否する。すなわち、グループアイデンティティ解決のただ１つのレベルだけを実行する。これは、長ったらしいグループ解決プロセスと、潜在的な無限ループ交換とを防止するために実行される。しかしながら、ある有限数レベルの解決が、制御ＰｏＣサーバで実現されるポリシーに依存して容認されてもよい。
【００３３】
本発明の範囲から逸脱することなしに、様々な変形を実行することができることが、当業者なら理解するであろう。
【図面の簡単な説明】
【００３４】
【図１】ＰｏＣ会議のセットアップに関連するＰｏＣアーキテクチャのシグナリングフローを示す図である。
【図１】
2009512291.tif 000003
【国際調査報告】
2009512291.tif 000004
2009512291.tif 000005