(57)【要約】  ＰｏＣシステムのセッション管理サーバーは、発言権管理リストをリセット、すなわち、すべての予約された発言権を一挙に取り消すことができる機能を有し、任意のユーザーから発言権リセットが要請されると、認証可否によって発言権をリセットするＰｏＣユーザー発言権除去方法及びそのシステムを提供する。前記システムは、予約された発言権除去要請を試みるＰｏＣクライアント; 及び前記ＰｏＣクライアントから発言権除去要請メッセージを受信して、予約された発言権を除去するセッション管理サーバーを含む。前記方法は、任意のグループに属するＰｏＣクライアントがセッション管理サーバーに発言権管理リストに予約された発言権の除去を要請するステップ; 及び前記ＰｏＣクライアントから発言権除去要請メッセージが受信されると、セッション管理サーバーで予約された発言権を除去するステップを含む。
2008527942.tif 000002
【特許請求の範囲】
【請求項１】
ＰｏＣシステムの発言権除去方法であって、
ＰｏＣクライアントがセッション管理サーバーに発言権管理リストに予約された発言権除去要請メッセージを送信するステップと、
前記セッション管理サーバーが前記ＰｏＣクライアントから前記発言権除去要請メッセージを受信して、前記予約された発言権を除去するステップと、
を含むことを特徴とするＰｏＣシステムの発言権除去方法。
【請求項２】
前記予約された発言権を除去するステップは、
前記セッション管理サーバーが、前記発言権除去要請メッセージを送信したＰｏＣクライアントが発言権除去権限がある否かを判断するステップと、
前記ＰｏＣクライアントが前記発言権除去権限がある場合、前記予約された発言権を除去するステップと、
を含むことを特徴とする請求項１に記載のＰｏＣシステムの発言権除去方法 。
【請求項３】
ＰｏＣシステムの予約された発言権除去方法であって、
ＰｏＣクライアントがセッション管理サーバーに発言権管理リストに予約された発言権の除去を要請するステップと、
前記セッション管理サーバーが前記ＰｏＣクライアントから発言権除去要請メッセージを受信して、前記ＰｏＣクライアントが発言権除去権限があるか否かを判断するステップと、
前記ＰｏＣクライアントが前記発言権除去権限がない場合、前記予約された発言権の除去要請を拒絶するステップと、
を含むことを特徴とするＰｏＣシステムの予約された発言権除去方法。
【請求項４】
前記ＰｏＣクライアントが発言権管理リストに予約された発言権の除去を要請するステップは、前記セッション管理サーバーから前記発言権除去権限の承認を受けるステップを含むことを特徴とする請求項３に記載のＰｏＣシステムの予約された発言権除去方法。
【請求項５】
前記発言権除去権限の承認を受けるステップは、発言権除去要請前と前記発言権除去要請時の中でいずれの一時点で実行されることを特徴とする請求項４に記載のＰｏＣシステムの予約された発言権除去方法。
【請求項６】
前記発言権除去要請メッセージは、ＲＴＣＰ(ｒｅａｌ-ｔｉｍｅ ｔｒａｎｓｐｏｒｔ  ｃｏｎｔｒｏｌ  ｐｒｏｔｏｃｏｌ)ＡＰＰ(ａｐｐｌｉｃａｔｉｏｎ)パケットのＴＢＣＰ(Ｔａｌｋ  Ｂｕｒｓｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ)メッセージを利用することを特徴とする請求項３に記載のＰｏＣシステムの予約された発言権除去方法。
【請求項７】
前記ＴＢＣＰメッセージは、ＲＴＣＰ  ＡＰＰパケットのサブタイプ(ｓｕｂｔｙｐｅ)フィールドの値として予備(ｒｅｓｅｒｖｅｄ)値の中でいずれの一つを選択することを特徴とする請求項６に記載のＰｏＣシステムの予約された発言権除去方法。
【請求項８】
ＰｏＣシステムであって、
予約された発言権の除去要請メッセージを送信するＰｏＣクライアントと、
前記ＰｏＣクライアントから予約された発言権の除去要請メッセージを受信して、前記予約された発言権を除去するセッション管理サーバーと、
を含むことを特徴とするＰｏＣシステム。
【請求項９】
前記セッション管理サーバーは、前記ＰｏＣクライアントが発言権除去権限がある否かを判断して、前記発言権除去権限がある場合、前記予約された発言権を除去することを特徴とする請求項８に記載のＰｏＣシステム。
【請求項１０】
ＰｏＣシステムであって、
予約された発言権の除去要請メッセージを送信するＰｏＣクライアントと、
前記ＰｏＣクライアントから前記予約された発言権の制御要請メッセージを受信して、前記ＰｏＣクライアントが発言権除去権限があるが否かを判断して、前記発言権除去権限がない場合、前記予約された発言権の除去要請を拒絶するセッション管理サーバーと、
を含むことを特徴とするＰｏＣシステム。
【請求項１１】
前記発言権除去要請メッセージは、ＲＴＣＰ(ｒｅａｌ-ｔｉｍｅ ｔｒａｎｓｐｏｒｔ  ｃｏｎｔｒｏｌ  ｐｒｏｔｏｃｏｌ)ＡＰＰ(ａｐｐｌｉｃａｔｉｏｎ)パケットのＴＢＣＰ(Ｔａｌｋ  Ｂｕｒｓｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ)メッセージを利用することを特徴とする請求項１０に記載のＰｏＣシステム。
【請求項１２】
前記ＴＢＣＰメッセージは、ＲＴＣＰ  ＡＰＰパケットのサブタイプ(ｓｕｂｔｙｐｅ)フィールド値として予備(ｒｅｓｅｒｖｅｄ)値の中でいずれの一つを選択することを特徴とする請求項１１に記載のＰｏＣシステム。
【請求項１３】
ＰｏＣ端末であって、
セッション管理サーバーから発言権除去要請前と発言権除去要請時の中でいずれの一時点で発言権除去権限の承認を受ける手段と、
前記セッション管理サーバーに発言権除去要請メッセージを送信する手段と、
を含むことを特徴とするＰｏＣ端末。
【請求項１４】
前記発言権除去要請メッセージは、ＲＴＣＰ(ｒｅａｌ−ｔｉｍｅ  ｔｒａｎｓｐｏｒｔ  ｃｏｎｔｒｏｌ  ｐｒｏｔｏｃｏｌ)ＡＰＰ(ａｐｐｌｉｃａｔｉｏｎ)パケットのＴＢＣＰ(Ｔａｌｋ  Ｂｕｒｓｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ)メッセージであることを特徴とする請求項１３に記載のＰｏＣ端末。
【請求項１５】
前記ＴＢＣＰメッセージは、ＲＴＣＰ  ＡＰＰパケットのサブタイプ(ｓｕｂｔｙｐｅ)フィールドの値として予備(ｒｅｓｅｒｖｅｄ)値の中でいずれの一つを定義することを特徴とする請求項１４に記載のＰｏＣ端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＰｏＣ(Ｐｕｓｈ ｔｏ ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ)システムに関し、より詳しくは、ＰｏＣシステムの発言権管理機能が提供される環境で発言権をリセットする技術に関する。
【背景技術】
【０００２】
移動通信の画期的な発展と通信網の拡大にしたがって、携帯電話を用いた多様な付加サービスやアプリケーションが提供されている。しかも、携帯電話のユーザーの要求も多様化され、単純な通話サービスから外れて位置サービス、マルチメディアサービス、ＰＴＴ(Ｐｕｓｈ ｔｏ Ｔａｌｋ)サービスなどに拡大されている。特にＰＴＴサービスは、無線機(Ｅｘｉｓｔｉｎｇ  Ｒａｄｉｏ  Ｓｙｓｔｅｍ)やＴＲＳ(Ｔｒｕｎｋ Ｒａｄｉｏ Ｓｙｓｔｅｍ)により提供されるグループ通話と音声通話はもちろん、インスタントメッセンジャー、状態表示などの多様な付加機能をサポートする。
【０００３】
現在、このようなＰＴＴ機能を移動通信網を用いてサービスするＰｏＣ(Ｐｕｓｈ-ｔｏ-ｔａｌｋ ｏｖｅｒ ｃｅｌｌｕｌａｒ:以下、ＰｏＣと称する)サービスに対する標準制定が活発に論議されている。ＰｏＣサービスの特徴のうち１つは、ユーザーが複数のＰｏＣセッションに参加でき、必要に応じてＰｏＣセッション間を移動しつつ通話することができるという点である。ユーザーが複数のＰｏＣセッションを移動しつつ通話することができなければならないという要求事項は、移動通信サービスを定義する団体であるＯＭＡ(Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ)に明示されている。
【０００４】
一般的なＰｏＣサービスシステムの構造は、図１の概念図を参照して説明する。図１を参照すれば、ＰｏＣクライアント１０は、移動端末内に設けられるサービス要請者であり、アクセス網２０を介してＳＩＰ(Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ)及びＩＰ(Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ)マルチメディア機能をサポートするＳＩＰ／ＩＰコア網３０に連結される。
【０００５】
ＰｏＣクライアント１０は、ＰｏＣサービスへの接続のためにＰｏＣユーザー端末機に常駐する。ＰｏＣセッションを開始するためのＰｏＣクライアント１０の主なサービスは、現在進行中のＰｏＣセッションに参加し、ＰｏＣセッションを終了することである。また、前記ＰｏＣクライアント１０は、トークバーストを形成して伝達し、インスタントパーソナルアラート(Ｉｎｓｔａｎｔ Ｐｅｒｓｏｎａｌ ａｌｅｒｔ)をサポートし、ＰｏＣサービスに接続する時、認証を実行する。以下、別の言及がない限り、ＰｏＣユーザーとＰｏＣクライアント１０は、ＰＴＴサービス加入者と同一に見なす。
【０００６】
ＳＩＰ／ＩＰコア網３０は、ＰｏＣサービスをサポートするために、ＰｏＣサーバー６０と、ＧＬＭＳ(Ｇｒｏｕｐ Ｌｉｓｔ ａｎｄ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ)５０、及びプレゼンスサーバー７０と連結される。
【０００７】
このとき、ＰｏＣサーバー６０は、ＰｏＣセッションを維持・管理するＣｏｎｔｒｏｌｌｉｎｇ ＰｏＣ Ｆｕｎｃｔｉｏｎ(ＣＦ)機能を実行するか、一対一のＰｏＣ通話や一対多通話(又はグループ通話)のためにＰｏＣセッションに参加するためのＰａｒｔｉｃｉｐａｔｉｎｇ ＰｏＣ Ｆｕｎｃｔｉｏｎ(ＰＦ)機能を実行する。
【０００８】
以下、前記ＰｏＣサーバーの機能別ブロックは、図２の概念図を参照して説明する。
【０００９】
前記ＰｏＣサーバーは、ＰｏＣセッションを全般的に維持・管理するＣｏｎｔｒｏｌｌｉｎｇ ＰｏＣ Ｆｕｎｃｔｉｏｎ(以下、‘ＣＦ’と称する)と、各ＰｏＣセッション間の維持・管理を担当するＰａｒｔｉｃｉｐａｔｉｎｇ ＰｏＣ Ｆｕｎｃｔｉｏｎ(以下、‘ＰＦ’と称する)とに分けられ、下記の表を参照して詳細に説明する。
【００１０】
【表１】
2008527942.tif 000003
【００１１】
前記表１のように、ＣＦはＰｏＣサーバーの機能のうちＰｏＣセッションを総体的に維持管理する役目をする。ＰｏＣサーバーは、ＰｏＣクライアントの発言権(ｆｌｏｏｒ)要請を受け入れて、クライアントの順序を定めて権限を付与する。また、ＰｏＣサーバーは、任意のＰｏＣクライアントが要請したトークバースト(Ｔａｌｋ  Ｂｕｒｓｔ)をグループＰｏＣ呼出に参加した全ての他のＰｏＣクライアントに分配し、グループＰｏＣ呼出に参加したＰｏＣクライアントの情報を提供する。
【００１２】
下記の表２から分かるように、ＰＦは、ＣＦと各ＰｏＣクライアント間のＰｏＣセッションを管理する。特に、ＰＦは、ＰｏＣクライアントが発言権を要求するか、ＣＦがクライアントに発言権を付与する時、ＣＦとＰｏＣクライアントとの間に発言権を中継する役目をする。また、ＰＦは、ＣＦとクライアントとの間にメディアを中継し、ＣＦとＰｏＣクライアントとの間で異なるコーデックを使用したい場合にはトランスコーディングし、同時セッションの場合には、１つのＰｏＣセッションをフィルタリングする役目を実行する。
【００１３】
【表２】
2008527942.tif 000004
【００１４】
上述したように、ＰｏＣサービスシステムにおいてＰｏＣユーザーは、自分のＰｏＣ端末機を介してＧＬＭＳ 50にグループ及びグループメンバーに関する情報を入力することができ、ＧＬＭＳ50から伝送された個人またはグループリストを通じて自分が呼び出すことができるＰｏＣユーザーに関する情報を確認することができる。選択的に、ＰｏＣサービス提供者が信頼できるインターネットやイントラネットのような通信網を介して情報を入力することで、ＧＬＭＳ50にグループ及びグループメンバーに関する情報を修正及び管理することができる。
【００１５】
ＰｏＣ呼出サービスを利用するために、ＰｏＣユーザーは、前記ＳＩＰ／ＩＰコア網３０に自分のＰｏＣアドレスを登録する。ＳＩＰ／ＩＰコア網３０では、ＰｏＣユーザーの要請に応じてＰｏＣユーザーに関する情報を格納する。したがって、他のＰｏＣユーザーがＰｏＣグループ呼出を要請しようとする場合には、上述したように、自分の情報を前記ＳＩＰ／ＩＰコア網３０に登録し、ＧＬＭＳ５０から転送されたグループ識別情報を利用して自分のＳＩＰ／ＩＰコア網３０にグループＰｏＣ呼出を要請する。この時、ＳＩＰ／ＩＰコア網３０は、呼出を要請するＰｏＣユーザー情報を利用してアドレス決定とドメイン位置決定過程を実行し、呼び出しを要請するＰｏＣユーザーが登録されたホームＰｏＣサーバーにＰｏＣ通話要請を伝達する。このＰｏＣ通話要請に対してＰｏＣサーバーは、ＰｏＣセッション開設を準備し、ＧＬＭＳ５０サーバーから各々のユーザー情報を獲得した後、該当ＳＩＰ／ＩＰコア網３０にＰｏＣ通話要請信号を伝達する。この時、イントラドメイン内のユーザーに対するＰｏＣ通話要請である場合、ＰｏＣサーバーは、ＰＦ及びＣＦの機能を共に実行する。通話要請されたＰｏＣユーザーを管理するＰｏＣサーバーは、自分に伝達されたＰｏＣユーザーの情報を利用してＳＩＰ／ＩＰコア網３０の位置決定過程を実行した後、ＰｏＣユーザーにＰｏＣ通話を要請する。
【００１６】
図３は、ＰｏＣサーバーのＣＦブロックとＰＦブロックを説明するための概念図である。
【００１７】
図３を参照すれば、ＰｏＣクライアント１１１、１２１、１３１、１４１はＰＦ１１０、１２０、１３０、１４０を介してＣＦ１００に接続してＰｏＣセッションを開設する。ここで、ＣＦ１００で許可した発言要請者に発言権が付与されると、該当ＰｏＣクライアントの発言を基盤としたメディアが各ＰｏＣクライアントに伝送される。
【００１８】
図４は、ＰｏＣユーザーが発言権を獲得する一般的な手続きを示すフローチャートである。
【００１９】
図４を参照すれば、発言権を獲得するため、ＰｏＣセッションがＰｏＣクライアントＡ１１１とＰｏＣクライアントＢ１２１を連結した状態で、ＰｏＣセッション内でどのＰｏＣクライアントも言っていないとき、ＰｏＣクライアントＡ１１１が端末機に設置されたＰｏＣトークボタンを押す。
【００２０】
それによって、ＰｏＣクライアントＡ１１１は発言権を要請するメッセージであるトークバースト要求メッセージをＰａｒｔｉｃｉｐａｔｉｎｇ ＰｏＣ Ｆｕｎｃｔｉｏｎの役目をするＰＦ Ａ１１０に伝送し(ステップＳ１０１)、このトークバースト要請メッセージを受信したＰＦ Ａ１１０はこのＰｏＣセッションのＣｏｎｔｒｏｌｌｉｎｇ ＰｏＣ ｆｕｎｃｔｉｏｎの役目をするＰｏＣサーバー、すなわち、ＣＦ１００にメッセージを伝送する(ステップＳ１０１)。
【００２１】
発言権要請メッセージを受信した後、ＣＦ１００はＰｏＣクライアントＡ１１１に発言権を付与するメッセージであるトークバースト確認応答メッセージを伝送し(ステップＳ１０２)、ＰｏＣクライアントＢ１２１にはユーザーＡからＰｏＣクライアントＡ１１１に発言権を付与したと受信トークバーストメッセージを伝送する(ステップＳ１０３)。このメッセージは話者、すなわち、ＰｏＣクライアントＡ１１１のＩＤを含んでいるのでＰｏＣクライアントＢ１２１は誰が話者であるかが分かる。
【００２２】
以後、メディアセッションがオープンされてＰｏＣクライアントＡ１１１からトークバーストがＰｏＣクライアントＢ１２１に伝達される(ステップＳ１０４)。
【００２３】
以上、ＰｏＣセッションが連結された時の発言権を要請する手続きについて説明した。ＰｏＣセッションが連結されなかった場合、ＰｏＣクライアントＡ１１１がＰｏＣクライアントＢ１２１にＰｏＣセッション設定を要請すれば、その中間でＣｏｎｔｒｏｌｌｉｎｇ  ＰｏＣ  ｆｕｎｃｔｉｏｎの役目をするＰｏＣサーバーがＰｏＣクライアントＢ１２１にＰｏＣセッション開設に関するメッセージを伝送する。それによって、ＰｏＣクライアントＢ１２１は承認応答をＣｏｎｔｒｏｌｌｉｎｇ  ＰｏＣ  ｆｕｎｃｔｉｏｎの役目をするＰｏＣサーバーのＣＦ１００に伝送し、ＣＦ１００はＰｏＣクライアントＡ１１１にトークバースト確認応答メッセージを伝送する。このように発言権を受けたＰｏＣクライアントＡ１１１は、このときからＰｏＣトークボタンを押したまま話し始めると、オープンされたメディアセッションを通じて言葉(音声信号に変われたデータファイル)を伝送する。
【００２４】
図５は、端末機で発言権を予約する一般的な手続きを示すフローチャートである。
【００２５】
図５を参照すれば、ＰｏＣユーザーはＰｏＣセッションに参加し、そのＰｏＣセッションに参加している他の参加者の中で少なくとも一名の参加者からトークバースト(ｔａｌｋ ｂｕｒｓｔ)を受信する(ステップＳ２０１)。そのＰｏＣユーザーが通話するためにはＰｏＣ端末機に具現されたトークボタン(ｔａｌｋ ｂｕｔｔｏｎ)を押す。ＰｏＣユーザーがトークボタンを押したか否かを判断して(ステップＳ２０２)、ステップＳ２０２で、ＰｏＣユーザーがトークボタンを押したと判断されると、他の参加者がトークバーストを伝送中であるか否かを判断する(ステップＳ２０３)。
【００２６】
ステップＳ２０３で、他の参加者がトークバーストを伝送中ではないと判断されると、他の参加者は発言権を要請してトークバースト付与メッセージ(Ｔａｌｋ ｂｕｒｓｔ Ｇｒａｎｔ ｍｅｓｓａｇｅ)を受信した後にトークバーストを伝送する(ステップＳ２１０)。
【００２７】
ステップＳ２０３で、もし、他の参加者がトークバーストを伝送中である場合には、発言権管理機能(例えば、‘キュー’機能)をサポートするか否かを判断する(ステップＳ２２０)。他の参加者がトークバーストを伝送中で発言権管理機能がサポートされると、発言権要請時に発言権が発言権管理者で予約される(ステップＳ２３０)。この発言権はＣｏｎｔｒｏｌｌｉｎｇ ＰｏＣ ｆｕｎｃｔｉｏｎの役目をするＰｏＣサーバーのキューに予約される。
【００２８】
ステップＳ２２０で、キュー機能がサポートされないと判断されると、端末機で発言権を要請しない場合もある。そして、端末機で発言権を要請してもＣｏｎｔｒｏｌｌｉｎｇ ＰｏＣ ｆｕｎｃｔｉｏｎの役目をするＰｏＣサーバーで発言権の予約を拒絶するようになる(ステップＳ２４０)。
【００２９】
図６は、ＰｏＣサーバーで発言権を管理する一般的な過程を示すフローチャートである。
【００３０】
図６を参照すれば、ＰｏＣセッションでのＰｏＣサーバーの状態は、アイドル(ｉｄｌｅ)あるいはＰｏＣユーザーのトークバーストを伝送する二つの状態に分けることができる(ステップＳ３０１)。ＣＦの役目をするＰｏＣサーバーが発言権要請を受けた時(ステップＳ３０２)、発言権管理機能(例えば、‘キュー’機能)をサポートして(ステップＳ３０３)、他の参加者がトークバーストを伝送中であれば(ステップＳ３１０)、発言権管理リストに要請を受けた発言権を予約する(ステップＳ３１１)。ステップＳ３１０で、他の参加者がトークバーストを伝送していないと判断されると、発言権を要請したＰｏＣクライアントの端末にＴａｌｋ ｂｕｒｓｔ Ｇｒａｎｔ ｍｅｓｓａｇｅを伝送し、ＰｏＣユーザーから受信されたトークバーストをＰｏＣセッションに参加している他の聴取者に伝送(中継)する(ステップＳ３１２)。
【００３１】
ＣＦの役目をするＰｏＣサーバーが発言権要請を受けた時、発言権管理機能をサポートしないで他の参加者がトークバーストを伝送中であれば(ステップＳ３２０)、要請された発言権を拒絶する(ステップＳ３２１)。発言権管理機能をサポートしないで他の参加者がトークバーストを伝送しないと、発言権を要請したＰｏＣクライアントの端末にＴａｌｋ ｂｕｒｓｔ Ｇｒａｎｔ ｍｅｓｓａｇｅを伝送し、ＰｏＣユーザーから受信されるトークバーストをＰｏＣセッションに参加している他の聴取者に伝送(中継)する(ステップＳ３２２)。
【００３２】
図７は、一般的なＰｏＣシステムで発言権を予約する過程を示すフローチャートである。
【００３３】
図７を参照すれば、ＰｏＣクライアントＢ１２１がトークバーストを伝送している中に(ステップＳ４０１)、ＰｏＣクライアントＡ１１１がＴａｌｋ  ｂｕｒｓｔ  ｒｅｑｕｅｓｔ、すなわち、発言権を要請する(ステップＳ４０２)。この場合、ＣＦの役目をするＰｏＣサーバーＸ１００が発言権管理リスト(例えば、‘キュー’)に発言権を予約して(ステップＳ４０３)、その予約された発言権に関する位置情報(発言手順)をＰｏＣクライアントＡ１１１に伝送する(ステップＳ４０４)。
【００３４】
この時、予約された発言権位置情報はＲＴＣＰ  ＡＰＰパケットのＴａｌｋ  ｂｕｒｓｔ  Ｑｕｅｕｅ  Ｐｏｓｉｔｉｏｎ  Ｓｔａｔｕｓメッセージを通じて報知できる。このような方式でＰｏＣユーザーは自分が要請した発言権が発言権管理リストに予約されたか否かが分かる。
【００３５】
図８は、一般的なＰｏＣシステムで発言権管理リストに予約された発言権がある場合、他の参加者が発言を終了した時に他の発言権を有した参加者がトークバーストを伝送する過程を示すフローチャートである。
【００３６】
図８を参照すれば、ＰｏＣクライアントＡ１１１がトークバーストを伝送して(ステップＳ５０１)、ＰｏＣユーザーは通話が終わってＰｏＣ端末機に具現されたトークボタンを外す。それでは、ＰｏＣクライアントＡ１１１は最後に伝送する必要があるパケットをＣＦを実行するＰｏＣサーバーＸ１００に伝送し(ステップＳ５０２)、トークバースト伝送が終わったという完了メッセージであるＴａｌｋ  ｂｕｒｓｔ  Ｃｏｍｐｌｅｔｅ  Ｍｅｓｓａｇｅを伝送する(ステップＳ５０３)。この時、ＰｏＣサーバーＸ１００は最後受信したパケットをＰｏＣクライアントＢ１２１に伝送し(ステップＳ５０２)、ＰｏＣクライアントＡ１１１から受けたＴａｌｋ  ｂｕｒｓｔ  Ｃｏｍｐｌｅｔｅ  Ｍｅｓｓａｇｅを通じて伝送が終了したことを認知して、次の発言権を有したＰｏＣクライアントＢ１２１に発言しても良いという許可のＴａｌｋ  ｂｕｒｓｔ  Ｃｏｎｆｉｒｍ Ｍｅｓｓａｇｅを伝送する(ステップＳ５０４)。前記Ｔａｌｋ  ｂｕｒｓｔ  Ｃｏｎｆｉｒｍ  Ｍｅｓｓａｇｅを受信したＰｏＣクライアントＢ１２１は、ＰｏＣユーザーＢの端末機の表示部に発言しても良いという内容を表示する。この時からＰｏＣユーザーＢはトークボタンを押したまま話す(ステップＳ５０５)。
【００３７】
前記のように発言権管理リスト(例えば、‘キュー’)に発言権を予約する従来の技術は、ＰｏＣセッションがアイドル状態である場合にだけトークバースト要請(Ｔａｌｋ  ｂｕｒｓｔ  ｒｅｑｕｅｓｔ)が可能な機能と比較して効果的にＰｏＣシステムを運用することができる。
【００３８】
しかし、前記従来技術は、ＰｏＣシステム環境で会議(ｃｏｎｆｅｒｅｎｃｅ  ｃａｌｌ)する場合は、次のような問題点が導出される。
【００３９】
電話会議(ｃｏｎｆｅｒｅｎｃｅ  ｃａｌｌ)の場合、一つの主題に対して多いＰｏＣユーザーが発言しようとトークバーストを要請するようになる。例えば、予約された発言権が２０個程度になった状態で、おおよそ３人のＰｏＣユーザーが発言した時、結論が容易に出たか、あるいは緊急に他の案件に対して論議しなければならない事態が発生する場合、前記従来技術方式では仕方なく残った１７人のＰｏＣユーザーが全部発言権を受けて発言した後こそ新しい案件に移ることができる。これはＰｏＣシステムにおいて時間と有/無線資源を浪費する原因になる。
【発明の開示】
【発明が解決しようとする課題】
【００４０】
本発明の目的は、ＰｏＣシステムのセッション管理サーバーに発言権管理リストをリセットするための機能、すなわち、すべての予約された発言権を一挙に取り消すことができる機能を提供し、任意のＰｏＣユーザーから発言権リセットが要請されると、認証可否によって発言権をリセットするＰｏＣシステムでの発言権除去方法及びそのシステムを提供することにある。
【００４１】
本発明の他の目的は、セッション管理サーバーに発言権リセットを要請できるように発言権リセットを意味するフィールドが定義されたメッセージフォーマットを提供することにある。
【課題を解決するための手段】
【００４２】
本発明の一側面によれば、ＰｏＣシステムの発言権除去方法は、ＰｏＣクライアントがセッション管理サーバーに発言権管理リストに予約された発言権除去要請メッセージを送信するステップと、前記セッション管理サーバーが前記ＰｏＣクライアントから前記発言権除去要請メッセージを受信して、前記予約された発言権を除去するステップと、を含む。
【００４３】
本発明の他の側面によれば、ＰｏＣシステムで予約された発言権を除去方法は、ＰｏＣクライアントがセッション管理サーバーに発言権管理リストに予約された発言権の除去を要請するステップと、前記セッション管理サーバーが前記ＰｏＣクライアントから発言権除去要請メッセージを受信して、前記ＰｏＣクライアントが発言権除去権限があるか否かを判断するステップと、前記ＰｏＣクライアントが前記発言権除去権限がないと判断された場合、前記予約された発言権除去要請を拒絶するステップと、を含む。
【００４４】
本発明のまた他の側面によれば、ＰｏＣシステムは、予約された発言権の除去要請メッセージを送信するＰｏＣクライアントと、前記ＰｏＣクライアントから前記発言権除去要請メッセージを受信して、前記予約された発言権を除去するセッション管理サーバーと、を含む。
【００４５】
本発明のまた他の側面によれば、ＰｏＣシステムは、予約された発言権の除去要請メッセージを送信するＰｏＣクライアントと、前記ＰｏＣクライアントから前記メッセージを受信して、前記ＰｏＣクライアントが発言権除去権限があるか否かを判断し、その判断結果、前記発言権除去権限がない場合、前記予約された発言権の除去要請を拒絶するセッション管理サーバーと、を含む。
【００４６】
本発明のまた他の側面によれば、ＰｏＣ端末は、セッション管理サーバーから発言権除去要請前と発言権除去要請時の中でいずれの一時点で発言権除去権限の承認を受けて、前記セッション管理サーバーに発言権除去要請メッセージを送信する。
【発明の効果】
【００４７】
本発明によれば、ＰｏＣユーザーが参加しているセッションで非常に多い発言権が予約されているので通話及び会議が進行されない場合、予約された発言権を全部取り消すようにする。したがって、ＰｏＣセッションで行われている対話(Ｃａｌｌｓ)を効果的に管理することができる。
【発明を実施するための最良の形態】
【００４８】
以下、本発明の属する分野における通常の知識を有する者が本発明を容易に実施できるように本発明の好ましい実施例を添付の図面を参照して詳細に説明する。
【００４９】
ＯＭＡ（Ｏｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ)で定義したＰｏＣ(Ｐｕｓｈ−ｔｏ−ｔａｌｋ−ｏｖｅｒ−ｃｅｌｌｕｌａｒ)システムでは、ＲＴＣＰ  ＡＰＰ(Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ  ＡＰＰｌｉｃａｔｉｏｎ)パケットを利用したＴＢＣＰ(Ｔａｌｋ  Ｂｕｒｓｔ  Ｃｏｎｔｒｏｌ  ｐｒｏｔｏｃｏｌ)が使用される。このＴＢＣＰは発言権を要請する時、発言権を付与する時、発言権を拒絶する時などのメッセージを伝送する役目をする。
【００５０】
前記ＴＢＣＰの機能は、図面を参照して詳しく説明する。
【００５１】
図９は、本発明を具現するためのＲＴＣＰ ＡＰＰパケットを利用したトークバースト発言権リセット要請メッセージフォーマットを示す図で、図１０は、図９のメッセージフォーマットを詳細に示す図である。
【００５２】
図９及び図１０を参照すれば(ＩＥＴＦ(Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ  Ｆｏｒｃｅ)で定義しているＲＦＣ ３５５０参照)、ＲＴＣＰ  ＡＰＰパケットで一番目の２ビットフィールドは、ＲＴＰのバージョン(ｖｅｒｓｉｏｎ)用である(本発明ではｖｅｒｓｉｏｎ＝２を示す)。
【００５３】
二番目のビットフィールドは、パッディングビット(ｐａｄｄｉｎｇ  ｂｉｔ)用である。パッディングビットが与えられると、ペイロードに含まれない１または２個のパッディングオクテット(ｐａｄｄｉｎｇ  ｏｃｔｅｔ)が付加されたこが分かる。
【００５４】
三番目の５ビットフィールドは、サブタイプ(ｓｕｂｔｙｐｅ)を示す(ＯＭＡ ＰｏＣ Ｕｓｅｒ  ｐｌａｎｅ  ｓｐｅｃｉｆｉｃａｔｉｏｎ文書参照)。このサブタイプを利用してＲＴＣＰ  ＡＰＰパケットがどのようなＴＢＣＰの機能を実行しているかが分かる。
【００５５】
例えば、現在ＯＭＡでドラフトされているスペックでは、サブタイプがＴＢＣＰトークバースト要請メッセージ(Ｔａｌｋ  ｂｕｒｓｔ  ｒｅｑｕｅｓｔ  ｍｅｓｓａｇｅ)である場合には、サブタイプの値が０００００で定義されており、ＴＢＣＰトークバースト付与メッセージ(Ｔａｌｋ  ｂｕｒｓｔ  Ｇｒａｎｔｅｄ  ｍｅｓｓａｇｅ)である場合には、００００１で定義されている。現在まで１６個のＴＢＣＰトークバースト制御メッセージ(Ｔａｌｋ  ｂｕｒｓｔ  ｃｏｎｔｒｏｌ  ｍｅｓｓａｇｅ)を定義しているので、前記サブタイプの値は０１１１１までに定義される。残りの１６個の値は新しく発生するＴＢＣＰトークバースト制御メッセージ(Ｔａｌｋ  ｂｕｒｓｔ  ｃｏｎｔｒｏｌ  ｍｅｓｓａｇｅ)のために予備(ｒｅｓｅｒｖｅｄ)状態になっている。
【００５６】
したがって、本発明では、１００００〜１１１１１の値の中でいずれの一つを選択してサブタイプ値を付与して他のＴＢＣＰトークバースト制御メッセージ値と区分することができる。ここで、前記残っているサブタイプ値１００００を使用して他のＴＢＣＰトークバースト制御メッセージ値と区分する。
【００５７】
しかし、この値が残ったどんな値を有するかに関係なくメッセージの内容が発言権管理リスト(Ｑｕｅｕｅ)に予約された発言権を全部削除する機能を示す場合には、同一なＴＢＣＰトークバースト制御メッセージと見なす。 四番目の１バイトフィールドはペイロードタイム用である。それはよく知られたプロトコルである“ＲＴＣＰ”を示すためのフォーマットの中で一つである。“２０４”は“ＲＴＣＰ”ＡＰＰの制御フォーマットを意味する。“２０１”は“ＴＲＣＰ”の“Ｒｅｃｅｉｖｅ  Ｒｅｐｏｒｔ”を意味することのように多様なタイプがある。
【００５８】
五番目の２バイトフィールドはＬｅｎｇｔｈフィールドである。このフィールドに２の値が使用されると、このメッセージが４バイトオクテット(ｏｃｔｅｔ)２個があることを示す。後にペイロードが付いたらペイロードフィールドで全体４バイトオクテットがいくつあるかそのペイロード長さを示す。六番目の４バイトフィールドは同期化ソース(Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ＳｏｕＲＣｅ)フィールドである。前記ＳＳＲＣ識別子はＲＴＰヘッダーに載せて運ばれ、ＲＴＣＰパケットの多様なフィールドはＲＴＰセッション内で唯一に国際的に要求されるランダムな３２ビット数である。同一な数を選択するためには、同一ネットワークに参加するか、同一な時間に開始することより、手順によって注意して数を選択することが一番重要である。
【００５９】
このフィールドは、発言権管理リストに予約されたすべての発言権の削除を要請するＰｏＣクライアントの同期化ソースを含んでいるので、誰が要請したかを区分可能にする。
【００６０】
七番目の４バイトフィールドはＡＳＣＩＩで表現され、前記パケットがＰｏＣバージョン１で使用されていることを示すフィールドである。
【００６１】
図１１は、本発明による発言権を除去する過程を示すフローチャートである。
【００６２】
図１１を参照すれば、先に予約された発言権を削除するためには発言権削除権限を有している必要がある。例えば、参加しているＰｏＣセッションの開設者、すべての参加者が認定したＰｏＣセッション議長、またはサービス提供者などがこのような権限を有することができる。
【００６３】
もし、誰もこの機能を使用可能にする場合、意思を発言するための発言権を何の理由もなく削除する場合が発生できるので、これを防止するためには権限認証手続きが隋伴されなければならない。
【００６４】
このために、任意のユーザー(ここでは、‘ＰｏＣクライアントＡ’とする)が自分が発言権管理機能を使用するための権限を有するため、それに適当なユーザーであることをＣｏｎｔｒｏｌｌｉｎｇ  ＰｏＣ  ｆｕｎｃｔｉｏｎの役目をするＰｏＣサーバーであるＣＦ１００に登録する(ステップＳ１００１、ステップＳ１００２)。
【００６５】
権限登録はＰｏＣセッション開設時のＩＮＶＩＴＥ  ＆  ＯＫ方法を利用するかあるいは新しいＴＢＣＰを利用して実行することができる。
【００６６】
一つの実施例として、初めてＰｏＣセッションを開設する時、ＣＦはＩＮＶＩＴＥメッセージを通じて誰がそのセッションを開設したか分かるようになる。これによって、ＣＦはＰｏＣセッション開設者のＳＩＰ  ＵＲＩを格納する。“ＵRL”はＰｏＣセッション開設者の“ＵＲＩ”の中で一つである。ＰｏＣクライアントが発言権リセット要請メッセージを伝送した場合に、ＣＦでは要請したＰｏＣクライアントがＰｏＣセッション開設者であるか否かをＳＩＰ  ＵＲＩを通じてチェックしてトークバーストリセット要請を実行する。
【００６７】
他の実施例として、新しいＴＢＣＰを利用することができる。
【００６８】
ＲＴＣＰ  ＡＰＰフォーマットでサブタイプ番号を１０００１あるいは１０００１から１１１１１の間の番号の中で一つを付与して、ＴＢＣＰメッセージ、すなわち、権限登録要請(Ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｇｉｓｔｒａｔｉｏｎ ｒｅｑｕｅｓｔ)メッセージを作り出す。
【００６９】
ＰｏＣクライアントが前記ＴＢＣＰメッセージをＣＦに送信すれば、ＣＦでは前記ＴＢＣＰメッセージを受信した後、ＰｏＣサービス提供者の政策によって適当なユーザーであるか否かを判断して(ステップＳ１１００)、要請したＰｏＣクライアントに承認(Ｐｅｒｍｉｓｓｉｏｎ)メッセージを伝送する(ステップ１２００)。
【００７０】
発言権管理リストに予約された発言権を全部削除することを希望して、それに適当な権利を有したＰｏＣクライアントが、Ｔａｌｋ  ｂｕｒｓｔ  Ｑｕｅｕｅ  ＲｅｓｅｔをＣＦ１０００に要請すれば(ステップＳ１３００)、ＣＦ１０００では発言権をリセットできる権限を有しているか否かに対する認証過程を実行する(ステップＳ１４００)。
【００７１】
ステップＳ１４００で、認証されると、ＣＦはＴａｌｋ  ｂｕｒｓｔ  Ｑｕｅｕｅをリセットさせて(ステップＳ１５００)、これに対する結果をＴａｌｋ  ｂｕｒｓｔ  Ｑｕｅｕｅ  Ｒｅｓｅｔを要請したＰｏＣクライアントに通知する(ステップＳ１６００)。
【００７２】
本発明は、ＰｏＣシステムに限定されない。例えば、３ＧＰＰや３ＧＰＰ２で標準化中であるか完成されたＩＭＳ(ＩＰ  ｍｕｌｔｉｍｅｄｉａ  ＣＮ)網を利用してｈａｌｆ  ｄｕｐｌｅｘの通話形態を利用して発言権を制御するサーバーを有した全てのシステムの適用することができる。
【００７３】
以上において説明した本発明は、本発明が属する技術の分野における通常の知識を有する者であれば、本発明の技術的思想を逸脱しない範囲内で、様々な置換、変形及び変更が可能であるので、上述した実施例及び添付された図面に限定されるものではない。
【図面の簡単な説明】
【００７４】
【図１】図１は、一般的なＰｏＣサービスシステムを説明するための概念図である。
【図２】図２は、一般的なＰｏＣサーバーの構造を示す概念図である。
【図３】図３は、ＰｏＣサーバーのＣＦブロックとＰＦブロックを説明するための概念図である。
【図４】図４は、ＰｏＣユーザーが発言権を獲得する一般的な手続きを示すフローチャートである。
【図５】図５は、端末機で発言権を予約する一般的な手続きを示すフローチャートである。
【図６】図６は、ＰｏＣサーバーで発言権を管理するための一般的な手続きを示すフローチャートである。
【図７】図７は、一般的なＰｏＣシステムで発言権を予約するための過程を示すフローチャートである。
【図８】図８は、一般的なＰｏＣシステムで発言権管理リストに予約された発言権がある場合、ほかの参加者のうち一人が発言を終了したときに、その次の発言権を有した参加者がトークバーストを伝送する過程を示すフローチャートである。
【図９】図９は、本発明を具現するためのＲＴＣＰ  ＡＰＰパケットを利用したトークバースト発言権リセット要請メッセージフォーマットを示す図である。
【図１０】図１０は、図９のメッセージフォーマットを詳細に示す図である。
【図１１】図１１は、本発明によって発言権を除去する過程を示すフローチャートである。
【符号の説明】
【００７５】
Ｓ１００１  権限登録
Ｓ１１００  承認可否判断
Ｓ１２００  承認
Ｓ１３００  発言権予約リセット要請
Ｓ１４００  認証判断
Ｓ１５００  発言権予約リセット
Ｓ１６００  結果通知
【図１】
2008527942.tif 000005
【図２】
2008527942.tif 000006
【図３】
2008527942.tif 000007
【図４】
2008527942.tif 000008
【図５】
2008527942.tif 000009
【図６】
2008527942.tif 000010
【図７】
2008527942.tif 000011
【図８】
2008527942.tif 000012
【図９】
2008527942.tif 000013
【図１０】
2008527942.tif 000014
【図１１】
2008527942.tif 000015
【国際調査報告】
2008527942.tif 000016