(57)【要約】  共有フロアを介して通信する第１ユーザ装置及び第２ユーザ装置と，前記共有フロアを管理するサーバ手段を含む通信システムである。本システムによれば，前記サーバ手段は前記第１ユーザ装置からの匿名性要求を検出し，該匿名性要求に応答して，前記第１ユーザ装置から前記第２ユーザ装置に送信されるユーザプレーンメッセージによって，前記第２ユーザ装置が前記第１ユーザ装置を識別することを防ぐように構成される。前記共有フロアは，セルラネットワークを介したプッシュ−ツ−トーク（ＰｏＣ）サービスに関連してもよい。
2008502252.tif 000002
【特許請求の範囲】
【請求項１】
通信システムであって，
共有フロアを介して通信を行う第１ユーザ装置及び第２ユーザ装置と，
前記共有フロアを管理するサーバ手段とを備え，
前記第１ユーザ装置からの匿名性要求を検知するように前記サーバ手段を構成し，かつ
前記匿名性要求に応答して，前記第１ユーザ装置から前記第２ユーザ装置へ送信される少なくとも１つのユーザプレーンメッセージによって前記第２ユーザ装置が前記第１ユーザ装置を識別することを防ぐように前記サーバ手段を構成する通信システム。
【請求項２】
前記第１ユーザ装置を，第１プロトコルを用い，前記サーバ手段を介して前記第２ユーザ装置とのコネクションを開始するように構成する請求項１に記載のシステム。
【請求項３】
前記第１プロトコルが，セッション開始プロトコル（ＳＩＰ）を構成する請求項２に記載の通信システム。
【請求項４】
前記第１ユーザ装置が，第１プロトコルを用い，前記サーバ手段を介して既存のコネクション上で前記第２ユーザ装置と通信するように構成する請求項１に記載のシステム。
【請求項５】
前記第２プロトコルが，ＲＴＰ制御プロトコル（ＲＴＣＰ）を構成する請求項４に記載のシステム。
【請求項６】
前記少なくとも１つのユーザプレーンメッセージを，前記第２プロトコルを用いて送信する請求項４に記載のシステム。
【請求項７】
前記通信システムが，セルラネットワークを介したプッシュ−ツ−トーク通信システムを構成する請求項１に記載のシステム。
【請求項８】
前記少なくとも１つのユーザプレーンメッセージが，フロア制御メッセージを構成する請求項７に記載のシステム。
【請求項９】
前記少なくとも１つのユーザプレーンメッセージが，フロア取得メッセージを構成する請求項８に記載のシステム。
【請求項１０】
前記少なくとも１つのユーザプレーンメッセージが，メディアメッセージを構成する請求項７に記載のシステム。
【請求項１１】
前記サーバ手段を，前記少なくとも１つのユーザプレーンメッセージから前記第１ユーザの識別情報を削除するように構成する請求項８に記載のシステム。
【請求項１２】
前記サーバ手段を，前記少なくとも１つのユーザプレーンメッセージにユニーク匿名トークンを挿入するように更に構成する請求項１１に記載のシステム。
【請求項１３】
前記ユニーク匿名トークンを，少なくとも情報源記述アイテムの一部分として前記少なくとも１つのユーザプレーンメッセージ内に格納する請求項１２に記載のシステム。
【請求項１４】
前記少なくとも１つのユーザプレーンメッセージを前記第２ユーザ装置に送信する前に，前記少なくとも１つのユーザプレーンメッセージから前記第１ユーザの識別情報を削除するように前記サーバ手段を構成する請求項１に記載のシステム。
【請求項１５】
前記第１ユーザ装置からの前記少なくとも１つのユーザプレーンメッセージが，前記第１ユーザ装置の統一リソース識別子（ＵＲＩ）と，前記第１ユーザ装置の表示用名称とを含む識別情報を含む請求項１に記載のシステム。
【請求項１６】
前記少なくとも１つのユーザプレーンメッセージのサブタイプと，
前記少なくとも１つのユーザプレーンメッセージのペイロードタイプと，
前記少なくとも１つのユーザプレーンメッセージ内の追加情報源記述（ＳＤＥＳ）フィールドと，
追加専用フィールドとのうち少なくとも１つに前記匿名性要求を含む請求項１に記載のシステム。
【請求項１７】
前記少なくとも１つのユーザプレーンメッセージが，フロア要求メッセージ又は発言要求メッセージを構成する請求項１に記載のシステム。
【請求項１８】
前記サーバ手段が，
制御サーバと，
参加サーバとを含み，前記制御サーバを第１ユーザ装置からの前記匿名性要求を受信するように構成し，かつ前記参加サーバを前記少なくとも１つのユーザプレーンメッセージを送信するように構成する請求項１に記載のシステム。
【請求項１９】
前記制御サーバを，前記第１ユーザ装置の識別情報とプライバシ指示情報とを含む第２ユーザプレーンメッセージを前記参加サーバへ送信するように構成し，前記第２ユーザ装置が前記第２ユーザプレーンメッセージを受信し，かつ前記プライバシ指示情報に応答して前記第１ユーザ装置を識別することを防ぐように構成する請求項１８に記載のシステム。
【請求項２０】
前記第２ユーザプレーンメッセージのサブタイプと，
前記第２ユーザプレーンメッセージのペイロードタイプと，
前記第２ユーザプレーンメッセージ内の追加ＳＤＥＳフィールドと，
追加専用フィールドとのうち少なくとも１つによって，前記第２ユーザプレーンメッセージプライバシ指示情報を提供する請求項１８に記載のシステム。
【請求項２１】
通信システム内で動作するように構成したサーバ手段であって，前記通信システムが更に共有フロアを介して通信する第１ユーザ装置と第２ユーザ装置とを備え，
前記サーバ手段を，共有フロアを管理し，前記第１ユーザ装置からの匿名性要求を検知し,かつ前記匿名性要求に応答して，前記第１ユーザ装置から前記第２ユーザ装置へ送信される少なくとも１つのユーザプレーンメッセージによって前記第１ユーザ装置を識別することを防ぐように構成するサーバ手段。
【請求項２２】
共有フロアを介した通信システムにおいて動作するように構成されたユーザ装置であって，前記通信システムは，
前記ユーザ装置と，
前記共有フロアを管理するように構成したサーバ手段とを備え，
前記ユーザ装置の少なくとも１つを，前記少なくとも１つのユーザ装置が少なくとも１つのほかのユーザ装置を識別するのを防ぐユーザプレーンメッセージを前記サーバ手段から受信するように構成するユーザ装置。
【請求項２３】
共有フロアを介して通信する第１ユーザ装置及び第２ユーザ装置と，前記共有フロアを管理するように構成されたサーバ手段とを備える通信システム内の通信方法であって，
前記サーバ手段において前記第１ユーザ装置からの匿名性要求を受信するステップと，
前記第１ユーザ装置から前記第２ユーザ装置へ送信される少なくとも１つのユーザプレーンメッセージによって，前記第２ユーザ装置が前記第１ユーザ装置を識別することを防ぐステップとを有する方法。
【請求項２４】
共有フロアを介して通信する第１ユーザ装置及び第２ユーザ装置と，
前記共有フロアを管理する制御サーバと，
前記第２ユーザ装置にサービスを提供する少なくとも１つの参加サーバとを備え，
前記制御サーバを，前記第１ユーザ装置からの匿名性要求を検知し，プライバシ指示情報を前記第１ユーザ装置からのユーザプレーンメッセージに挿入し，かつ前記少なくとも１つの参加サーバが前記プライバシ指示情報に応答するとき，前記第２ユーザ装置が前記第１ユーザ装置を識別することを防ぐように構成する通信システム。
【請求項２５】
通信システム内で動作するように構成したサーバであって，前記通信システムが共有フロアを介して通信する第１ユーザ装置及び第２ユーザ装置を更に備え，
前記サーバを，共有フロアを管理し，前記第１ユーザ装置からの匿名性要求を検出し，かつ前記匿名性要求に応答して，前記第１ユーザ装置から前記第２ユーザ装置へ送信される少なくとも１つのユーザプレーンメッセージによって，前記第２ユーザ装置が前記第１ユーザ装置を識別することを防ぐように構成するサーバ。
【請求項２６】
共有フロアを介する通信システム内で動作するように構成したユーザ装置であって，前記通信システムが，
前記共有フロアを管理するように構成したサーバであって，前記ユーザ装置の前記少なくとも１つが少なくとも１つのほかのユーザ装置を識別することを防ぐユーザプレーンメッセージを，前記ユーザ装置の少なくとも１つが前記サーバから受信するように構成するユーザ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信システムに関連し，特にセルラネットワークを介したプッシュ−ツ−トークサービスに用いる通信システムに関連するが，それ以外を排除するわけではない。
【背景技術】
【０００２】
通信システムは，該通信システムに関連するユーザ装置及び／又はほかのノードのような２以上のエンティティ間で通信セッションを可能にする機能として見ることができる。通信は，例えば音声，データ，マルチメディア，及びそれらの類似物の通信を含む。セッションは，例えばユーザ間の電話呼タイプのセッション，多元会議セッション，又はユーザ装置とサービス提供者サーバのようなアプリケーションサーバ（ＡＳ）との間の通信セッションであってもよい。
【０００３】
典型的には通信システムは，その通信システムに関連するさまざまなエンティティが何を実行できるか，及びどのようにそれを達成するのが望ましいか，を規定する特定の標準又は仕様に従って動作する。例えば標準又は仕様は，ユーザ，又はより詳細にいえばユーザ装置が回線交換サービス及び／又はパケット交換サービスを利用できるかどうかを定義することができる。接続のために用いるべき通信プロトコル及び／又はパラメータも定義してよい。換言すれば，通信を可能にするために通信が基準とすることができる特定の規則の組が定義される。
【０００４】
ユーザ装置に無線通信を提供する通信システムが知られている。無線システムの一例は，公衆陸上移動体ネットワーク（ＰＬＭＮ）である。ＰＬＭＮは通常セルラ技術に基づく。セルラシステムにおいては，基地局（ＢＴＳ）又は類似の接続エンティティが，移動体ユーザ装置（ＵＥ）にそれらエンティティ間の無線インタフェースを介してサービスを提供する。ユーザ装置と通信ネットワークの要素との間の無線インタフェース上の通信は，適当な通信プロトコルに基づくことができる。通信に必要とされる基地局装置及びほかの装置の動作は，１又は数個の制御エンティティによって制御することができる。さまざまな制御エンティティを相互接続することができる。
【０００５】
セルラ接続ネットワークを，例えば公衆交換電話ネットワーク（ＰＳＴＮ），及び／又はＩＰ（インターネットプロトコル）のようなほかの通信ネットワーク，及び／又はほかのパケット交換データネットワークなどほかのネットワークに接続するために，１以上のゲートウェイノードを用いることができる。そのような構成においては，無線ユーザ装置を持ったユーザが外部のネットワーク，ホスト又は特定のサービス提供事業者が提供するサービスに接続することができるように，移動体通信ネットワークが接続ネットワークを提供する。
【０００６】
通信システムの加入者のようなユーザに提供されるサービスタイプの一例は，いわゆるマルチメディアサービスである。マルチメディアサービスを提供することができるいくつかの通信システムは，インターネットプロトコルマルチメディアネットワークとして知られている。ＩＰマルチメディア機能は，ＩＰマルチメディアサブシステム（ＩＭＳ）によって提供できる。ＩＭＳは，マルチメディアサービスの提供のためのさまざまなネットワークエンティティを含んでいる。ＩＭＳサービスは，サービスの中でも移動体ユーザ装置間にＩＰに基づくパケットデータ通信セッションを提供することを意図している。
【０００７】
パケットデータネットワークにおいては，ネットワークを介してトラヒック流を搬送するためにパケットデータキャリアを確立することができる。そのようなパケットデータキャリアの一例は，パケットデータプロトコル（ＰＤＰ）コンテキストである。
【０００８】
ＩＭＳを介してさまざまなアプリケーションサーバ（ＡＳ）によってさまざまな種類のサービスが提供される。これらサービスのいくつかは時間が重要である。ＩＭＳを介して提供することができる時間が重要なサービスの一例は，いわゆる直接音声通信サービスである。この種のサービスの一例は，ＰＴＴ（プッシュ−ツ−トークサービス）としても知られる「セルラネットワークを介するプッシュ−ツ−トーク」（ＰｏＣ）サービスである。直接音声通信サービスは，ユーザ装置とほかのユーザ装置又はネットワークに関連するエンティティのようなほかの通信相手との間でＩＰ接続ができるように，ＩＭＳの能力を利用することを意図している。このサービスは，ユーザが１人以上のユーザと即時通信を行えるようにする。
【０００９】
セルラネットワークを介するプッシュ−ツ−トーク（ＰｏＣ）通信システムの背景にある原則は，ウォーキートーキーの能力を標準の携帯電話機に実装することにある。単にユーザは，自分の携帯電話機から話をしたい人又は人のグループを選択し，自分の携帯電話機のプッシュ−ツ−トークキーを押下して話をすればよい。操作は，特定のボタン，スティック（ｔａｎｇｅｎｔ）又はキーボードの任意のほかの適当なキーを用いて行うことができる。タッチセンサ又は音声によるユーザインタフェースを備えるデバイスにも類似の原則が適用される。１人のユーザが話をすると，ほかのユーザが聞くことができる。通信セッションのすべての参加者も類似してＰｏＣアプリケーションサーバと音声データを送受することができるので，双方向通信が提供される。発言の順番は，プッシュ−ツートークボタン又はその類似物を操作することによって要求される。接続応答時間はほとんど瞬時である。
【００１０】
典型的にはプッシュ−ツ−トーク呼は半二重通信である。すなわち１人のユーザが話している間，ほかのユーザは聞くだけである。発言の順番は，プッシュ−ツートークキーを押下することによって先着順又は優先度に基づいて許可される。プッシュ−ツ−トーク呼は通常受信者の応答なしに接続され，典型的には携帯電話機に内蔵されたスピーカから聞こえる。
【００１１】
このシステムはセルラ通信システムに組み込まれているので，伝統的な双方向無線システムよりも広いカバー範囲が得られる。プッシュ−ツ−トークサービスは，ＩＰマルチメディアサブシステム（ＩＭＳ）内のプッシュ−ツ−トークサーバを用いて実装することができる。プッシュ−ツ−トークサービスは，マルチユニキャストに基づく。各送信携帯電話機は，専用のプッシュ−ツ−トークサーバ（参加サーバ）にパケットデータトラヒックを送信する。制御サーバはトラヒックを受信し，グループ呼のための共有フロアを管理する。制御サーバは，トラヒックをすべての受信者が受信できるように複製する。ＧＰＲＳ接続ネットワーク又は無線接続ネットワークいずれにおいてもマルチキャストは行われない。
【００１２】
セルラ通信システムを介するプッシュ−ツ−トークは，"OMA Push to talk over Cellular （PoC) - Architecture"のようなセルラ通信システムを介するプッシュ−ツ−トーク暫定規定に記載されている。
【００１３】
ＰｏＣシステムを用いて通信するユーザ装置のグループは，さまざまな方法で生成される。インターネット技術委員会（ＩＥＴＦ）はそのようなセッション開始プロトコル（ＳＩＰ）又は会議ポリシ制御プロトコル（ＣＰＣＰ）を用いる１つのそのようなシステムを定義している。いったんグループが設定されると，リアルタイム転送プロトコル（ＲＴＰ）ストリーミングベアラによって音声及びデータ制御トラヒックが搬送される。ＰｏＣシステムはＩＥＴＦ  ＲＦＣ  ３５５０の規定に基づいた転送プロトコルを用いる。ＲＴＰは，データパケットのアーキテクチャと，ユーザからユーザへ音声及びデータ情報を回送するパケット内に格納されるデータの構文とを記述する。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
ＰｏＣネットワーク上のプライバシ及び匿名性の問題は，これまで扱われてこなかった。ＰｏＣネットワークのユーザは，メッセージを送信し，最終あて先には自分の識別情報を与えず，それでもなお１人以上の仲介者には識別情報を通知したいかもしれない。
【００１５】
例えばＩＥＴＦ  ＲＦＣ  ３３２３及び３３２５など，ＩＭＳ接続を設定しつつユーザが自分の識別情報を保留できるいくつかのＳＩＰプロトコルは存在するが，Ｐｏｃネットワークにおけるデータがどうやってユーザの匿名性を維持するかについては，何の議論もされていない。
【００１６】
更に，グループに参加したユーザがグループに話ができるように要求する一方で，グループのほかのメンバには自分の識別情報を秘匿するように要求することもできる方法はない。これは，一方ではなお自分の識別情報をセルラネットワークを介したプッシュ−ツ−トーク（ＰｏＣ）システムの参加サーバ及び制御サーバに送信しつつ，行わなければならない。ユーザの識別情報が秘匿されているときに違法行為が行われないようにするため，識別情報の回送によって当局がグループを監視できるようにする。
【００１７】
本発明の実施例の目的は，上述の課題を処理又は少なくとも軽減することにある。
【課題を解決するための手段】
【００１８】
本発明に従って，共有フロアを介して通信を行う第１ユーザ装置及び第２ユーザ装置と，前記共有フロアを管理するサーバ手段とを備え，前記第１ユーザ装置からの匿名性要求を検知するように前記サーバ手段を構成し，かつ前記匿名性要求に応答して，前記第１ユーザ装置から前記第２ユーザ装置へ送信される少なくとも１つのユーザプレーンメッセージによって前記第２ユーザ装置が前記第１ユーザ装置を識別することを防ぐように前記サーバ手段を構成する通信システムが提供される。
【００１９】
前記第１ユーザ装置を，第１プロトコルを用い，前記サーバ手段を介して前記第２ユーザ装置とのコネクションを開始するように構成してもよい。
【００２０】
前記第１プロトコルは，セッション開始プロトコル（ＳＩＰ）であってもよい。
【００２１】
前記第１ユーザ装置は，好ましくは第２プロトコルを用い，前記サーバ手段を介して既存のコネクション上で前記第２ユーザ装置と通信するように構成される。
【００２２】
前記第２プロトコルは，ＲＴＰ制御プロトコル（ＲＴＣＰ）であってもよい。
【００２３】
前記少なくとも１つのユーザプレーンメッセージは，好ましくは前記第２プロトコルを用いて送信される。
【００２４】
前記通信システムは，セルラネットワークを介したプッシュ−ツ−トーク通信システムを構成してもよい。
【００２５】
ユーザプレーンメッセージは，好ましくはフロア制御メッセージとする。
【００２６】
ユーザプレーンメッセージは，好ましくはフロア取得メッセージとする。
【００２７】
ユーザプレーンメッセージは，好ましくはメディアメッセージとする。
【００２８】
前記サーバ手段を，前記少なくとも１つのユーザプレーンメッセージから前記第１ユーザの識別情報を削除するように構成してもよい。
【００２９】
前記サーバ手段を，前記少なくとも１つのユーザプレーンメッセージにユニーク匿名トークンを挿入するように更に構成してもよい。
【００３０】
前記ユニーク匿名トークンは，好ましくは少なくとも情報源記述アイテムの一部分として前記少なくとも１つのユーザプレーンメッセージ内に格納する。
【００３１】
好ましくは，前記少なくとも１つのユーザプレーンメッセージを前記第２ユーザ装置に送信する前に，前記少なくとも１つのユーザプレーンメッセージから前記第１ユーザの識別情報を削除するように前記サーバ手段を構成する。
【００３２】
前記第１ユーザ装置からの前記少なくとも１つのユーザプレーンメッセージが，前記ユーザ装置の統一リソース識別子（ＵＲＩ）と，前記ユーザ装置の表示用名称とを含む識別情報を含んでもよい。
【００３３】
好ましくは，前記少なくとも１つのユーザプレーンメッセージのサブタイプと，前記少なくとも１つのユーザプレーンメッセージのペイロードタイプと，前記少なくとも１つのユーザプレーンメッセージ内の追加情報源記述（ＳＤＥＳ）フィールドと，追加専用フィールドとのうち少なくとも１つに前記匿名性要求を含む。
【００３４】
ユーザプレーンメッセージは，好ましくはフロア要求メッセージ又は発言要求メッセージとする。
【００３５】
前記サーバ手段が，制御サーバと，参加サーバとを含み，前記制御サーバを第１ユーザ装置からの前記匿名性要求を受信するように構成し，かつ前記参加サーバを前記少なくとも１つのユーザプレーンメッセージを送信するように構成してもよい。
【００３６】
好ましくは，前記制御サーバを，前記第１ユーザ装置の識別情報とプライバシ指示情報とを含む第２ユーザプレーンメッセージを前記参加サーバへ送信するように構成し，前記第２ユーザ装置が前記第２ユーザプレーンメッセージを受信し，かつ前記プライバシ指示情報に応答して前記第１ユーザ装置を識別することを防ぐように構成する。
【００３７】
好ましくは，前記第２ユーザプレーンメッセージのサブタイプと，前記第２ユーザプレーンメッセージのペイロードタイプと，前記第２ユーザプレーンメッセージ内の追加ＳＤＥＳフィールドと，追加専用フィールドとのうち少なくとも１つによって前記第２ユーザプレーンメッセージプライバシ指示情報を提供する。
【００３８】
本発明の第２態様によれば，通信システム内で動作するように構成したサーバ手段であって，前記通信システムが更に共有フロアを介して通信する第１ユーザ装置と第２ユーザ装置とを備え，前記サーバ手段を，共有フロアを管理し，前記第１ユーザ装置からの匿名性要求を検知し，かつ前記匿名性要求に応答して，前記第１ユーザ装置から前記第２ユーザ装置へ送信される少なくとも１つのユーザプレーンメッセージによって前記第１ユーザ装置を識別することを防ぐように構成するサーバ手段が提供される。
【００３９】
本発明の第３態様によれば，共有フロアを介した通信システムにおいて動作するように構成されたユーザ装置であって，前記通信システムは，前記ユーザ装置と，前記共有フロアを管理するように構成したサーバ手段とを備え，前記ユーザ装置の少なくとも１つを，前記少なくとも１つのユーザ装置が少なくとも１つのほかのユーザ装置を識別するのを防ぐユーザプレーンメッセージを前記サーバ手段から受信するように構成するユーザ装置が提供される。
【００４０】
本発明の第４態様によれば，共有フロアを介して通信する第１ユーザ装置及び第２ユーザ装置と，前記共有フロアを管理するように構成されたサーバ手段とを備える通信システム内の通信方法であって，前記サーバ手段において前記第１ユーザ装置からの匿名性要求を受信するステップと，前記第１ユーザ装置から前記第２ユーザ装置へ送信される少なくとも１つのユーザプレーンメッセージによって，前記第２ユーザ装置が前記第１ユーザ装置を識別することを防ぐステップとを有する方法が提供される。
【００４１】
本発明の第５態様によれば，共有フロアを介して通信する第１ユーザ装置及び第２ユーザ装置と，前記共有フロアを管理する制御サーバと，前記第２ユーザ装置にサービスを提供する少なくとも１つの参加サーバとを備え，前記制御サーバを，前記第１ユーザ装置からの匿名性要求を検知し，プライバシ指示情報を前記第１ユーザ装置からのユーザプレーンメッセージに挿入し，かつ前記少なくとも１つの参加サーバが前記プライバシ指示情報に応答するとき，前記第２ユーザ装置が前記第１ユーザ装置を識別することを防ぐように構成する通信システムが提供される。
【発明を実施するための最良の形態】
【００４２】
本発明及びどのようにして同一の効果が得られるかをより良く理解するために，ここで付随する図面を例示の目的のみで参照することとする。
【００４３】
例示として第３世代（３Ｇ移動体通信システム）のアーキテクチャを参照して，例として本発明のある実施例を説明する。しかしながら，実施例は任意のほかの適当な形態の通信システムにも適用できることを理解されたい。
【００４４】
第３世代パートナシッププロジェクト（３ＧＰＰ）は，ユーザ装置のユーザがマルチメディアサービスに接続できるようにする第３世代（３Ｇ）コアネットワークのための参照アーキテクチャを定義した。このコアネットワークは三つの主要な領域に分割される。それは，回線交換（ＣＳ）領域と，パケット交換（ＰＳ）領域と，インターネットプロトコルマルチメディアサブシステム（ＩＭＳ）領域とである。
【００４５】
図１に，ＩＰマルチメディアサービスをＩＰマルチメディアネットワーク加入者に提供するＩＰマルチメディアネットワーク４５を示す。ＩＰマルチメディアサブシステム（ＩＭＳ）機能は，サービス提供のためのさまざまなエンティティを含むコアネットワーク（ＣＮ）サブシステムによって提供することができる。第３世代パートナシッププロジェクト（３ＧＰＰ）は，ＩＰ接続性をＩＭＳサービスに提供する一般パケット無線サービス（ＧＰＲＳ）の利用を定義した。したがって，ＩＭＳサービスを可能にする可能性のあるバックボーン通信ネットワークの例として，以下ではＧＰＲＳシステムを用いる。
【００４６】
通常３Ｇセルラシステムのような移動体通信システムは，ユーザ装置と通信システムの基地局との間の無線インタフェースを介して，典型的には複数のユーザ装置にサービスを提供するように構成される。移動体通信システムは，論理的に無線接続ネットワーク（ＲＡＮ）とコアネットワーク（ＣＮ）とに分割できる。典型的にはコアネットワークエンティティは，さまざまな制御エンティティと，複数の無線接続ネットワークを介する通信を可能にし，また１つの通信システムをほかのセルラシステム及び／又は固定回線通信システムのような１以上の通信システムとインタフェースできるようにするゲートウェイとを含む。
【００４７】
図１において，仲介移動体通信ネットワークはサポートノード３３，４２と移動体ユーザ装置３０，４４との間の，パケット交換領域におけるパケット交換データ伝送を提供する。次に，例えばゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）３４，４０を介してパケット交換データネットワーク（ＰＳＤＮ）へ接続するように，外部データネットワークにはさまざまなサブネットワークが接続される。このようにしてＧＰＲＳサービスは，移動体データ端末及び／又は外部データネットワークの間でパケットデータの伝送を可能にする。より特定すれば，例示する一般パケット無線サービスの運用環境は１以上のサブネットワークサービス範囲を含み，各サービス範囲はＧＰＲＳバックボーンネットワーク３２及び４１によって相互接続される。サブネットワークは，いくつかのパケットデータサービスノード（ＳＮ）を含む。本実施例においては，サービスノードはサービス提供ＧＰＲＳサポートノード（ＳＧＳＮ）と呼ぶ。ＳＧＳＮ３３，４２は，それぞれ少なくとも１つの移動体通信ネットワーク，典型的には基地局システム３１，４３に接続される。明りょうにするために図示していないが，無線ネットワークコントローラ，又は基地局コントローラのようなほかの接続システムコントローラによって，パケットサービスをいくつかの基地局を介して移動体ユーザ装置に提供できるように，その接続を提供することができる。
【００４８】
基地局３１及び４３は，それぞれの無線インタフェースを介して，移動体ユーザ，すなわち加入者の移動体ユーザ装置３０及び４４との間で信号を送受信するように構成される。したがって移動体ユーザ装置は，それぞれ無線インタフェースを介して基地局との間で信号を送受信できる。簡略表現された図１において，基地局３１及び４３はそれぞれの無線接続ネットワーク（ＲＡＮ）に属する。図示された構成において，ユーザ装置３０及び４４は，それぞれ基地局３１及び４３と関連付けられた二つの接続ネットワークを介してＩＭＳネットワーク４５に接続することができる。図１は二つの無線接続ネットワークの基地局だけを示しているが，典型的な移動体通信ネットワークは通常いくつかの無線接続ネットワークを含むことを認識されたい。
【００４９】
ＩＭＳ領域は，マルチメディアサービスが適切に管理されていることを保証するためのものである。ＩＭＳ領域は通常，インターネット技術委員会（ＩＥＴＦ）が開発したとおりのセッション開始プロトコル（ＳＩＰ）をサポートする。セッション開始プロトコル（ＳＩＰ）は，１以上の参加者（端点）とのセッションを生成，修正及び終了するためのアプリケーション層制御プロトコルである。一般的にＳＩＰは，これら端点にセッションの意味を気付かせることによって，インターネット内の２以上の端点間でセッションを開始できるように開発されたものである。ＳＩＰに基づく通信システムに接続したユーザは，標準化されたＳＩＰメッセージに基づいて，通信システムのさまざまなエンティティと通信することができる。ユーザ装置上であるアプリケーションを動作させているユーザ装置，すなわちユーザは，特定のセッションへの招待が正しくそれらの端点に配信されるように，ＳＩＰバックボーンに登録される。ＳＩＰはデバイスとユーザとに登録機構を提供し，セッション招待を適切に届けることができるように，位置サーバ及び登録簿のような機構を提供する。適切な可能なセッションの例は，インターネットマルチメディア会議と，インターネット電話呼と，マルチメディア配信とを含むＳＩＰ信号通知によって提供することができる。
【００５０】
無線接続ネットワーク内のユーザ装置は，典型的には無線ベアラと呼ばれる無線ネットワークチャネルを介して無線ネットワークコントローラと通信することができる。各ユーザ装置は，無線ネットワークコントローラとの間にいつでも同時に１以上の無線チャネルを利用できる。インターネットプロトコル（ＩＰ）通信に適合させた任意の適切な移動体ユーザ装置を，ネットワークに接続するために用いることができる。例えばユーザは，パーソナル計算機，パーソナルデジタルアシスタント（ＰＤＡ），移動機（ＭＳ），可搬型計算機，これらの組合せ又はその類似物のようなユーザ装置によって，セルラネットワークに接続することができる。
【００５１】
ユーザ装置は，電話の発呼及び着呼と，ネットワークとのデータの送受信と，例えばマルチメディアコンテンツの体験と，のような処理に用いられる。典型的にはユーザ装置は，これらの処理を行うためのプロセッサ及びメモリを備える。ユーザ装置は，移動体通信ネットワークの基地局との間で信号を無線で送受信するためのアンテナを含んでもよい。ユーザ装置はまた，移動体ユーザ装置のユーザに画像及びほかの図形情報を表示するためのディスプレイを備えてもよい。スピーカを備えてもよい。ユーザ装置の動作は，キーパッド，音声コマンド，タッチスクリーン又はタッチパッド，これらの組合せ，又はその類似物のような適当なユーザインタフェースによって制御できる。
【００５２】
図１のユーザ装置３０及び４４は，プッシュ−ツ−トークタイプのサービスを利用できるように構成されている。プッシュ−ツ−トークサービスに必要な操作機能は，移動機３０及び４４のキーパッドボタンの１つ，若しくは特定のキー又は「ウォーキートーキー」デバイスで知られている種類のボタンによって提供できる。
【００５３】
図１は，明りょうにするために２つのユーザ装置だけを示していること認識されたい。実際にはいくつかのユーザ装置が同時に，各基地局と通信をすることができる。ユーザ装置は，例えばいくつかのＳＩＰセッション及び活性化されたＰＤＰコンテキストなど，いくつかの同時セッションを有することができる。例えばユーザは，通話をしながら同時に少なくとも１つのほかのサービスに接続することができる。
【００５４】
接続エンティティ内のユーザ装置とＧＧＳＮとの間の全体の通信は，ＰＤＰコンテキストによって提供される。各ＰＤＰコンテキストは，特定のユーザとＧＧＳＮとの間の通信経路を提供する。いったんＰＤＰコンテキストが確立されると，典型的にはそれは複数のフローを搬送できる。各フローは通常，例えば特定サービス及び／又は特定サービスのメディア成分を意味する。したがってしばしばＰＤＰコンテキストは，ネットワークを通過する１以上のフローの論理通信経路を意味する。ユーザ装置とサービス提供ＧＰＲＳサポートノードとの間でＰＤＰコンテキストを実装するために，通常ユーザ装置のデータ転送を可能にする無線接続ベアラを確立する必要がある。
【００５５】
通信システムは，ネットワークエンティティによって処理され，サーバによってサービス提供を受けるＩＭＳネットワーク４５のさまざまな機能によって，ユーザ装置にサービスを提供できるように開発されている。現在の３Ｇ無線マルチメディアネットワークアーキテクチャにおいては，いくつかの違うサーバが違う機能を処理するものと考えられている。これらには，呼セッション制御機能（ＣＳＣＦ）のような機能が含まれる。呼セッション制御機能は，プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）３５，３９と，問い合わせ（interrogating）呼セッション制御機能（Ｉ−ＣＳＣＦ）３７と，サービス提供呼セッション制御機能（Ｓ−ＣＳＣＦ）３６，３８とのようなさまざまな範ちゅうに分割できる。
【００５６】
ユーザ装置３０，４４は，ＧＰＲＳネットワークを介して，一般的にはＩＭＳに接続されているアプリケーションサーバに接続することができる。図１においてそのようなアプリケーションサーバは，セルラネットワークを介したプッシュ−ツ−トーク（ＰｏＣ）サービスサーバ５０である。本発明のいくつかの実施例においては，ＰｏＣサーバは制御ＰｏＣサーバに接続された一連の参加ＰｏＣサーバを構成するサーバ手段として実装することができる。参加ＰｏＣサーバは，ユーザ装置との間でデータトラヒックを送受信し，また制御ＰｏＣサーバとの間でもデータトラヒックを送受信する。制御ＰｏＣサーバは，参加ＰｏＣサーバとの間でデータトラヒックを送受信し，参加サーバから受信した情報に従って，ＰｏＣ共有フロアへの接続を制御する。本発明の更なる実施例においては，１つの参加ＰｏＣサーバが制御ＰｏＣサーバとしても働く。
【００５７】
図２に，セルラネットワークを介したプッシュ−ツ−トーク（ＰｏＣ）システムに関する図１の通信システムの更なる図を示す。図２は，セルラネットワークを介したプッシュ−ツ−トーク通信システムを介して通信するユーザ装置ＵＥ１ ３０，ＵＥ２ ４４，ＵＥ３ １０２，ＵＥ４ １０４のネットワークを示している。ＵＥ１ ３０は第１参加ＰｏＣサーバ１０１に接続され，第１参加ＰｏＣサーバは制御ＰｏＣサーバ５０に接続されている。ＵＥ２ ４４は第２参加ＰｏＣサーバ１０３に接続され，第２参加ＰｏＣサーバは制御ＰｏＣサーバ５０に接続されている。ＵＥ３ １０２は第３参加ＰｏＣサーバ１０５に接続され，第３参加ＰｏＣサーバは制御ＰｏＣサーバ５０に接続されている。ＵＥ４ １０４は第４参加ＰｏＣサーバ１０７に接続され，第４参加ＰｏＣサーバは制御ＰｏＣサーバ５０に接続されている。このようなシステムにおいて，移動体ユーザ装置ＵＥ１，ＵＥ２，ＵＥ３，ＵＥ４は，４つの違うＩＭＳネットワークに属するものであってもよい。
【００５８】
ＰｏＣ参加サーバ１０１，１０３，１０５，１０７と，制御ＰｏＣサーバ５０とは，ＩＭＳネットワーク４５を介してセルラネットワークを介したプッシュ−ツ−トーク（ＰｏＣ）サービスを提供する。プッシュ−ツ−トークサービスは，いわゆる直接音声通信サービスの一例である。ＰｏＣサービスを利用したいユーザは，適当なＰｏＣサーバに加入する必要がある。
【００５９】
直接音声通信サービスは，ユーザ装置ＵＥ１ ３０，ＵＥ２ ４４，ＵＥ３ １０２，ＵＥ４ １０４の間でＩＰ接続を可能にするために，ＧＰＲＳバックボーンの能力及びマルチメディアサブシステムの制御機能を利用するように意図されている。ＰｏＣサーバは，ＩＭＳシステムの運用事業者が運用してもよいし，又は第三者サービス提供事業者が運用してもよい。
【００６０】
例えばユーザは，ユーザ装置ＵＥ１ ３０の特定の操作ボタンを押下することによって，通信リンクを開くことができる。ＵＥ１ ３０のユーザが話している間は，ＵＥ２ ４４，ＵＥ３ １０２，ＵＥ４ １０４の各ユーザは聞くだけである。ユーザ装置ＵＥ２ ４４のユーザは，次に類似の方法で答えることができる。ユーザ装置と適当な呼セッション制御機能との間の信号通知は，ＧＰＲＳネットワークを介して届けられる。ユーザプレーンセッションはユーザ装置の信号通知を設定し，参加ＰｏＣサーバ１０１，１０３，１０５，１０７を介して届けられ，制御ＰｏＣサーバ５０によって制御される。換言すれば，ＰｏＣサーバは制御プレーン（信号通知用）及びＰｏＣユーザのユーザプレーン（ユーザデータ用）双方を制御する。参加ＰｏＣサーバとユーザ装置との間の制御プレーントラヒックは，ＩＭＳを介して届けられ，その間ユーザ装置とＰｏＣサーバとの間のユーザプレーントラヒックは，インタフェース５４及び５６上でＧＰＲＳシステムからＰｏＣサーバへ届けられる（図１参照）。
【００６１】
前に記したように，プッシュ−ツ−トークサービスはマルチユニキャストに基づいている。各送信ユーザ装置ＵＥ１ ３０，ＵＥ２ ４４，ＵＥ３ １０２，ＵＥ４ １０４は，パケットデータトラヒックを専用プッシュ−ツ−トークサーバへ送信し，グループ呼のときは次にサーバがトラヒックをすべての受信者向けに複製する。通信システムを制御するために，「ユーザプレーン」メッセージは１人のユーザからシステムの残りのユーザへ，及びその逆に回送することができる。ユーザプレーンの１つのタイプのデータ通信パケットは，どのユーザが送信しているか，又はどのユーザがフロアを利用する許可を受信したかを通知するためのものである。この情報は，「フロア取得」メッセージであってもよい。この「フロア取得」情報は，フロアの制御を取得したユーザからＲＴＰトラヒックを受信するユーザ装置が受信する。これらの制御パケットは，前に記したリアルタイム転送プロトコル（ＲＴＰ）と対を成すＲＴＰ制御プロトコル（ＲＴＣＰ）のパケットに基づく。
【００６２】
本発明の理解を助けるために，ユーザ装置ＵＥ１ ３０，ＵＥ２ ４４，ＵＥ３ １０２，ＵＥ４ １０４がグループ通信にかかわっており，ユーザ装置ＵＥ４ １０４を用いるユーザが，一方で自分の識別情報が他人から秘匿されることを要求しつつ，発言したいと願う状況を説明する。
【００６３】
図３は，動作中の本発明の実施例を説明するフロー図である。明りょうにするためにいえば，この例においてＰｏＣクライアントＡはユーザ装置ＵＥ４ １０４を指し，参加ＰｏＣサーバＡは参加ＰｏＣサーバ１０７を指し，制御ＰｏＣサーバＸは制御ＰｏＣサーバ５０を指し，ＰｏＣサーバＢは，第１参加ＰｏＣサーバ１０１を指し，そしてＰｏＣクライアントＢは，対応するユーザ装置ＵＥ１ ３０を指している。１対１通信はこの例の中に記載されているが，同じ方法を制御ＰｏＣサーバがメッセージを各受信者に複製する１対多コミュニケーションにも適用できる。
【００６４】
第１ステップ２０１において，ＰｏＣクライアントＡ １０４は「発言要求」メッセージを参加ＰｏＣサーバＡ １０７に送信する。この「発言要求」メッセージは発言者，すなわちクライアントＡのユーザ識別情報及び匿名性要求を含む。
【００６５】
第２ステップ２０３は，参加ＰｏＣサーバＡ １０７が発言要求を受信した後に起こる。このステップにおいて，参加ＰｏＣサーバＡ １０７は発言者識別情報及び匿名性要求を含む「発言要求」を制御ＰｏＣサーバＸ ５０へ転送する。
【００６６】
制御ＰｏＣサーバＸ ５０は，クライアントがＰｏＣ通信グループに参加を許可されていることを判定するために，クライアントの許可を行うことができる。ＰｏＣクライアントＡ １０４が発言を許可されている，すなわちほかにフロアを占有しているユーザがいないとき，制御ＰｏＣサーバＸ ５０は第１ステップ２０５及び第２ステップ２０７を開始する。
【００６７】
制御ＰｏＣサーバが開始する第１ステップ２０５では，制御ＰｏＣサーバＸ ５０が「フロア取得」メッセージを参加ＰｏＣサーバＢ １０１に転送する。「フロア取得」メッセージは，発言者識別情報及びクライアントＡ １０４からの匿名性要求を含む。
【００６８】
制御ＰｏＣサーバが開始する第２ステップ２０７では，制御ＰｏＣサーバＸ ５０が「発言許可」メッセージを参加ＰｏＣサーバＡ １０７へ送信する。本発明のほかの実施例においては，制御ＰｏＣサーバＸ ５０が「発言許可」メッセージに類似した方法でシステムが処理する「フロア許可」メッセージを送信する。次のステップ２０９においては，参加ＰｏＣサーバＡが前のステップから受信した「発言許可」メッセージをＰｏＣクライアントＡ １０４へ送信する。この「発言許可」メッセージは，クライアントＡが発言バーストをグループ内に送信すること，すなわち送信を希望する任意のメッセージを同報すること，を許可する。
【００６９】
参加ＰｏＣサーバＢ １０１は，制御ＰｏＣサーバＸ ５０から発言者識別情報及び匿名性要求を含む「フロア取得」メッセージを受信する。参加ＰｏＣサーバＢ １０１は，匿名性要求を認識し，「フロア取得」メッセージから発言者の識別情報を削除する。参加ＰｏＣサーバＢ １０１は，ステップ２５１で新たな「フロア取得」メッセージを生成する。次に参加ＰｏＣサーバＢ １０１はステップ２１１で，ユーザを識別する特徴を含まないこの新たな「フロア取得」メッセージをＰｏＣクライアントＢ ３０に送信する。
【００７０】
図４及び５に，発言者識別情報及び匿名性要求を含む「発言要求」メッセージ，並びに「フロア取得」メッセージの例を示す。
【００７１】
図４に，本発明の第１実施例を実装した，「発言要求」データパケットを回送するステップを利用するようなＲＴＰ制御プロトコル（ＲＴＣＰ）に基づくパケットを示す。
【００７２】
「発言要求」ＲＴＣＰパケットはＰｏＣクライアントＡ １０４から参加ＰｏＣサーバＡ １０７へ送信され，制御サーバに発言をほかのユーザへ送信する許可を要求するために，参加ＰｏＣサーバＡ １０７によって制御ＰｏＣサーバＸ ５０へ転送される。
【００７３】
「発言要求」ＲＴＣＰパケットは，３２ビット幅のデータグラムを含む。データグラムの第１行目は，バージョン指示子（Ｖ）３０３（２ビット）と，パディングビット（Ｐ）３０５（１ビット）と，情報源数３０７ａ（５ビット）と，ペイロードタイプ（ＰＴ）３０９（８ビット）と，長さ指示子（ＬＥＮＧＴＨ）３１１である一連の情報値を含む。
【００７４】
ＩＥＴＦ  ＲＦＣ３５５０  ６．５章に規定されているように，バージョン指示子３０３は使用されているＲＴＰのバージョンを示し，この例ではバージョン２である。パディングビット３０５は，パケットが１以上のパディングオクテットを含んでいるかどうかを示す。情報源数は，さまざまなＲＴＣＰパケットのうちこのパケットがどれかを定義するサブタイプを識別するために用いられる。図４に示す例では，値１００００は修正された「発言要求」ＲＴＣＰパケットであることを示し，その修正は，発言要求をしたユーザが，グループのほかのユーザに対して匿名性を維持したいことを示すものである。ペイロードタイプ（ＰＴ）１０７は，ＲＴＣＰペイロードの形式を規定するものであり，示した例においては，ペイロードタイプはＡＰＰ又は２０４である。長さ指示子（ＬＥＮＧＴＨ）３１１は，パケット長を３２ビット語単位で記述し，第１語は含めない。この例では長さは２（３２ビット）語である。
【００７５】
データグラムの第２行目は同期情報源識別子（ＳＳＲＣ）３１３であり，パケットの発信源の同期情報源を識別する。示した例ではパケットは「発言要求」パケットであり，ＳＳＲＣ３１３は，ＰｏＣクライアントＡ １０４を示すものである。
【００７６】
ＲＴＣＰパケットの第３行目及び最終行は，ユーザ装置の表示用アドレス「名称」３１５を含む。「名称」フィールドはまた，アプリケーションのリリースバージョンを示すためにも用いられる。
【００７７】
参加サーバがステップ２０１の終わりでこのパケットをいったん受信すると，次にステップ２０３において制御ＰｏＣサーバＸ ５０へ転送される。
【００７８】
図５に，本発明の第１実施例を実装した，「フロア取得」データパケットを回送するステップを利用するようなＲＴＰ制御プロトコル（ＲＴＣＰ）に基づくパケットを示す。
【００７９】
前に記した方法に従って，２種類の「フロア取得」メッセージが用いられる。第１種の「フロア取得」ＲＴＣＰパケットは，制御ＰｏＣサーバ５０からネットワークを介して参加ＰｏＣサーバ，例えば第１参加ＰｏＣサーバ１０３へ送信される。第２種は，参加ＰｏＣサーバからユーザ装置，例えばＵＥ１ ３０へ送信され，ユーザ装置がフロアを許可されたユーザ装置からＲＴＰパケットを受信する準備をさせる。第１種及び第２種双方とも図５で説明される。
【００８０】
「フロア取得」ＲＴＣＰパケットは３２ビット幅のデータグラムを含む。
【００８１】
データグラムの第１行目は，バージョン指示子（Ｖ）３０３（２ビット）と，パディングビット（Ｐ）３０５（１ビット）と，情報源数３０７ｂ（５ビット）と，ペイロードタイプ（ＰＴ）３０９（８ビット）と，長さ指示子（ＬＥＮＧＴＨ）３１１ｂである一連の情報値を含む。
【００８２】
ＩＥＴＦ  ＲＦＣ３５５０  ６．５章に規定されているように，バージョン指示子３０３は使用されているＲＴＰのバージョンを示し，この例ではバージョン２である。パディングビット３０５は，パケットが１以上のパディングオクテットを含んでいるかどうかを示す。情報源数３０７ｂは，さまざまなＲＴＣＰパケットのうちこのパケットがどれかを定義するサブタイプを識別するために用いられる。図５に示す例では，値１００１０は修正された「フロア取得」ＲＴＣＰパケットであり，（通常の「フロア取得」ＲＴＣＰパケットを示すサブタイプ０００１０と異なり）ユーザが匿名性を要求していることを示している。ペイロードタイプ（ＰＴ）３０９は，ＲＴＣＰペイロードの形式を規定するものであり，示した例においては，ペイロードタイプはＡＰＰ又は２０４である。長さ指示子（ＬＥＮＧＴＨ）３１１ｂは，パケット長を３２ビット語単位で記述し，第１語は含めない。
【００８３】
データグラムの第２行目は同期情報源識別子（ＳＳＲＣ）３１３ｂであり，パケットの発信源の同期情報源を識別する。示した例ではパケットは修正された「フロア取得」パケットであり，ＳＳＲＣ３１３ｂは，制御ＰｏＣサーバ５０を示すものである。
【００８４】
ＲＴＣＰパケットの第３行目は，セルラネットワークを介したプッシュ−ツ−トーク（ＰｏＣ）サーバの表示用アドレス（名称）３１５ｂを含む。「名称」フィールドはまた，アプリケーションのリリースバージョンを示すためにも用いられる。
【００８５】
パケットの第４行目及びそれ以降の行は，情報ブロック３１７を含む。
【００８６】
第１種の「フロア取得」メッセージに対しては，情報ブロックは２つの情報源記述（ＳＤＥＳ）アイテムを含む。
【００８７】
第１情報源記述アイテム３２１は，標準形（ｃａｎｏｎｉｃａｌ）名称（ＣＮＡＭＥ）を含む。標準形名称は，ユーザ３２３の標準形名称を含む。ユーザ３２３の標準形名称は，ユーザとユーザ装置との組合せに対して指定されたユニークな識別子として定義される。そのようなユニークな識別子の一例は，図５に示す"dave.bowman@poc.operator.com"のようなＳＩＰ統一リソース識別子（ＵＲＩ）である。
【００８８】
第２情報源記述アイテム３２５は，表示用名称（名称）を含む。表示用名称はユーザ３２７の表示用名称を含む。ユーザ３２７の表示用名称は，ユーザとユーザ装置との組合せを示す，ユーザ装置が表示する識別子である。そのような識別子の一例は，図５に示す"DaveB"のような英数文字列である。
【００８９】
参加ＰｏＣサーバＢ １０３がいったんフロア取得匿名パケットを受信すると，参加ＰｏＣサーバＢは「フロア取得」メッセージを処理して，ユーザの標準形名称（ＣＮＡＭＥ）及び表示用名称（ＮＡＭＥ）を削除する。本発明のいくつかの実施例においては，ＣＮＡＭＥ及びＮＡＭＥの値は，特定のユニークな匿名名称でもよい。そのような場合，ユーザは自分の匿名性を維持することができるが，ユニークな匿名名称とユーザ名との間に特定の関係があることを条件に，当局はなおメッセージと特定のユーザとを結びつけることができる。
【００９０】
本発明の更なる実施例においては，「フロア取得」メッセージのサブタイプを通常の「フロア取得」メッセージのサブタイプに戻す。したがってそのような実施例においては，したがって受信ユーザ装置が，送信ユーザ装置が匿名性を要求したことを検出できないようにすることができる。
【００９１】
上記のような状況においては，ユーザはほかのクライアント，すなわちユーザ装置の目前で要求したときでも匿名性を維持できるが，それでもなおコントローラにおいて当局が監視することはできる。
【００９２】
上記の例は，ＲＴＣＰフロア制御パケットのサブタイプフィールド内で匿名性要求を提供する意味で記述されたが，本発明のほかの実施例においては，フロア制御メッセージのほかの場所に指示子を配置することもできることを認識されたい。
【００９３】
１つの更なる実施例においては，匿名性要求は修正されたペイロードタイプを利用して指示される。制御ＰｏＣサーバ及び参加ＰｏＣサーバは，この修正されたペイロードタイプを認識して要求された匿名性を提供することができる。
【００９４】
もう１つの更なる実施例においては，匿名性要求はユーザの匿名識別情報又は代替識別情報を組み込んだ追加ＳＥＤＳフィールドを提供することによって指示することができる。
【００９５】
本発明の更なる実施例においては，フロア制御メッセージ内の匿名性要求はパケットに追加の専用フィールドを加えることによって指示することができる。
【００９６】
匿名識別情報を含む追加ＳＤＥＳフィールドを加える例において，制御ＰｏＣサーバ５０から参加ＰｏＣサーバＢ １０３へ送信される第１種「フロア取得」メッセージは，匿名情報と共にユーザの匿名ＩＤを含むＳＤＥＳフィールドを搬送する。参加ＰｏＣサーバ１０３から受信ＰｏＣクライアントＢ ３０へ送信される第２種「フロア取得」メッセージは匿名情報だけを含む。すなわち，ユーザのＩＤはＰｏＣクライアントＢ ３０へ転送する前に削除される。
【００９７】
本発明の更なる実施例においては，復号ＳＤＥＳフィールドを形成するために，匿名識別情報又は代替識別情報が追加ＳＤＥＳフィールドとしてではなく，元のＳＤＥＳフィールド情報に連結して提供される。例えば，第１種「フロア取得」メッセージの表示用名称は，"name+++anonymousID"というデータを含むことができ，ここで"name"はユーザの表示用名称であり，"+++"はセパレータ，そして"anonymousID"は第２種「フロア取得」メッセージにおいてほかのユーザに回送される名称である。
【００９８】
本発明の更なる実施例においては，匿名情報，又はパケット，又は要素は，既知の「フロア取得」パケットに乗せて運ばれる。そのような実施例においては，標準形ユーザ名称及び表示用ユーザ名称を含む情報源記述情報を含む第１の「フロア取得」パケットに，匿名情報を含む第２のパケットが連結されて複合ＲＴＣＰパケットを形成する。
【００９９】
本発明の更なる実施例においては，先行技術において既知の「フロア取得」ＲＴＣＰパケットに直接匿名情報を含む第２のＲＴＣＰパケットが続く。この第２のパケットは所定のＲＴＰ制御プロトコル（ＲＴＣＰ）アプリケーション（ＡＰＰ）パケットである。
【０１００】
更なる実施例においては，匿名識別子情報源記述アイテムＰＲＩＶが匿名情報を転送するＰｏＣ特定の専用拡張を成す。
【０１０１】
図６に，匿名情報を含むＰＲＩＶメッセージパケットの一例を示す。ＰＲＩＶパケット５０１は匿名情報，すなわち指示子及び／又は任意の匿名ＩＤを含む数値文字列５０３を含む。
【０１０２】
本発明の更なる実施例においては，ユーザの標準形名称はユーザのＴＥＬ  ＵＲＬ／ＵＲＩであってもよい。ＴＥＬ  ＵＲＬ／ＵＲＩは，公衆交換電話ネットワーク（ＰＳＴＮ）において用いられるユーザ装置の電話番号に相当する，ＳＩＰにおける均等物である。
【０１０３】
本発明の更なる実施例においては，制御ＰｏＣサーバは，ユーザが匿名性を要求するユーザの初期化中にインスタンスを記憶する。この要求はＩＥＴＦ  ＲＦＣ  ３３２５及び／又はＩＥＴＦ  ＲＦＣ  ３３２３に記載されているＳＩＰプロトコルを用いて実行される。この実施例においては，制御ＰｏＣサーバはどの発言要求メッセージ又はフロア要求メッセージも検査し，ユーザが要求するとおりのプライバシを適用する。すなわち，制御ＰｏＣサーバは，匿名性要求を含む「発言要求」メッセージを受信したかのように「フロア取得」メッセージを送信する。
【０１０４】
本発明の実施例は，ほかの種類のフロア制御メッセージ又は実にほかの種類のメッセージを用いて記述された情報を提供することができる。ほかの種類のメッセージの例にはメディアメッセージが含まれる。
【０１０５】
本発明の実施例は更に，ユーザプレーンメッセージ又は制御プレーンメッセージを送信するために，ＲＴＣＰ以外のプロトコルを用いることもできる。
【０１０６】
本発明の更なる実施例においては，制御ＰｏＣサーバが信頼できないネットワーク内の参加ＰｏＣサーバがサービスを提供するユーザ装置に送信するときに，制御ＰｏＣサーバがメッセージを信頼できないネットワークの参加ＰｏＣサーバに転送する前に，転送メッセージからどの識別に関わる特徴も削除する処理を実行する。
【０１０７】
本発明のほかの実施例においては，ユーザ装置が匿名数値をユーザの表示用名称として送信することができる。これらの実施例においては，システムは匿名数値を削除せずに単純に数値を転送するように構成される。このようにしてユーザはなお自分のプライバシをそのようなシステム内で維持することができる。
【図面の簡単な説明】
【０１０８】
【図１】本発明の実施例を組み込んだ典型的な通信ネットワークの概略図である。
【図２】図１の通信ネットワーク内に実装されたプッシュ−ツ−トーク通信ネットワークの概略図である。
【図３】本発明の第１実施例を組み込んだフロア制御手続を示すフロー図である。
【図４】本発明の第１実施例を組み込んだＲＴＣＰ「発言要求」データパケットの概略図である。
【図５】本発明の第１実施例を組み込んだＲＴＣＰ「フロア取得」データパケットの概略図である。
【図６】本発明の更なる実施例を組み込んだ「ＰＲＩＶ」情報源記述データパケットの概略図である。
【図１】
2008502252.tif 000003
【図２】
2008502252.tif 000004
【図３】
2008502252.tif 000005
【図４】
2008502252.tif 000006
【図５】
2008502252.tif 000007
【図６】
2008502252.tif 000008
【国際調査報告】
2008502252.tif 000009
2008502252.tif 000010