JP2008527942A

JP2008527942A - ＰｏＣシステムの発言権除去方法及びそのシステム

Info

Publication number: JP2008527942A
Application number: JP2007552062A
Authority: JP
Inventors: スン−ジン・パク; ジュン−グ・パク; サン−キュン・スン
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2005-01-21
Filing date: 2006-01-19
Publication date: 2008-07-24
Anticipated expiration: 2026-01-19
Also published as: US20060189339A1; CN101107827A; KR20060085051A; WO2006078128A8; CN102176716A; EP1839419B1; WO2006078128A1; US7522932B2; EP1839419A1; CN102176716B; JP4772802B2; KR101085704B1; EP1839419A4

Abstract

ＰｏＣシステムのセッション管理サーバーは、発言権管理リストをリセット、すなわち、すべての予約された発言権を一挙に取り消すことができる機能を有し、任意のユーザーから発言権リセットが要請されると、認証可否によって発言権をリセットするＰｏＣユーザー発言権除去方法及びそのシステムを提供する。前記システムは、予約された発言権除去要請を試みるＰｏＣクライアント; 及び前記ＰｏＣクライアントから発言権除去要請メッセージを受信して、予約された発言権を除去するセッション管理サーバーを含む。前記方法は、任意のグループに属するＰｏＣクライアントがセッション管理サーバーに発言権管理リストに予約された発言権の除去を要請するステップ; 及び前記ＰｏＣクライアントから発言権除去要請メッセージが受信されると、セッション管理サーバーで予約された発言権を除去するステップを含む。

Description

本発明は、ＰｏＣ(ＰｕｓｈｔｏｔａｌｋｏｖｅｒＣｅｌｌｕｌａｒ)システムに関し、より詳しくは、ＰｏＣシステムの発言権管理機能が提供される環境で発言権をリセットする技術に関する。

移動通信の画期的な発展と通信網の拡大にしたがって、携帯電話を用いた多様な付加サービスやアプリケーションが提供されている。しかも、携帯電話のユーザーの要求も多様化され、単純な通話サービスから外れて位置サービス、マルチメディアサービス、ＰＴＴ(ＰｕｓｈｔｏＴａｌｋ)サービスなどに拡大されている。特にＰＴＴサービスは、無線機(ＥｘｉｓｔｉｎｇＲａｄｉｏＳｙｓｔｅｍ)やＴＲＳ(ＴｒｕｎｋＲａｄｉｏＳｙｓｔｅｍ)により提供されるグループ通話と音声通話はもちろん、インスタントメッセンジャー、状態表示などの多様な付加機能をサポートする。

現在、このようなＰＴＴ機能を移動通信網を用いてサービスするＰｏＣ(Ｐｕｓｈ-ｔｏ-ｔａｌｋｏｖｅｒｃｅｌｌｕｌａｒ:以下、ＰｏＣと称する)サービスに対する標準制定が活発に論議されている。ＰｏＣサービスの特徴のうち１つは、ユーザーが複数のＰｏＣセッションに参加でき、必要に応じてＰｏＣセッション間を移動しつつ通話することができるという点である。ユーザーが複数のＰｏＣセッションを移動しつつ通話することができなければならないという要求事項は、移動通信サービスを定義する団体であるＯＭＡ(ＯｐｅｎＭｏｂｉｌｅＡｌｌｉａｎｃｅ)に明示されている。

一般的なＰｏＣサービスシステムの構造は、図１の概念図を参照して説明する。図１を参照すれば、ＰｏＣクライアント１０は、移動端末内に設けられるサービス要請者であり、アクセス網２０を介してＳＩＰ(ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ)及びＩＰ(ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ)マルチメディア機能をサポートするＳＩＰ／ＩＰコア網３０に連結される。

ＰｏＣクライアント１０は、ＰｏＣサービスへの接続のためにＰｏＣユーザー端末機に常駐する。ＰｏＣセッションを開始するためのＰｏＣクライアント１０の主なサービスは、現在進行中のＰｏＣセッションに参加し、ＰｏＣセッションを終了することである。また、前記ＰｏＣクライアント１０は、トークバーストを形成して伝達し、インスタントパーソナルアラート(ＩｎｓｔａｎｔＰｅｒｓｏｎａｌａｌｅｒｔ)をサポートし、ＰｏＣサービスに接続する時、認証を実行する。以下、別の言及がない限り、ＰｏＣユーザーとＰｏＣクライアント１０は、ＰＴＴサービス加入者と同一に見なす。

ＳＩＰ／ＩＰコア網３０は、ＰｏＣサービスをサポートするために、ＰｏＣサーバー６０と、ＧＬＭＳ(ＧｒｏｕｐＬｉｓｔａｎｄＭａｎａｇｅｍｅｎｔＳｙｓｔｅｍ)５０、及びプレゼンスサーバー７０と連結される。

このとき、ＰｏＣサーバー６０は、ＰｏＣセッションを維持・管理するＣｏｎｔｒｏｌｌｉｎｇＰｏＣＦｕｎｃｔｉｏｎ(ＣＦ)機能を実行するか、一対一のＰｏＣ通話や一対多通話(又はグループ通話)のためにＰｏＣセッションに参加するためのＰａｒｔｉｃｉｐａｔｉｎｇＰｏＣＦｕｎｃｔｉｏｎ(ＰＦ)機能を実行する。

以下、前記ＰｏＣサーバーの機能別ブロックは、図２の概念図を参照して説明する。

前記ＰｏＣサーバーは、ＰｏＣセッションを全般的に維持・管理するＣｏｎｔｒｏｌｌｉｎｇＰｏＣＦｕｎｃｔｉｏｎ(以下、‘ＣＦ’と称する)と、各ＰｏＣセッション間の維持・管理を担当するＰａｒｔｉｃｉｐａｔｉｎｇＰｏＣＦｕｎｃｔｉｏｎ(以下、‘ＰＦ’と称する)とに分けられ、下記の表を参照して詳細に説明する。

前記表１のように、ＣＦはＰｏＣサーバーの機能のうちＰｏＣセッションを総体的に維持管理する役目をする。ＰｏＣサーバーは、ＰｏＣクライアントの発言権(ｆｌｏｏｒ)要請を受け入れて、クライアントの順序を定めて権限を付与する。また、ＰｏＣサーバーは、任意のＰｏＣクライアントが要請したトークバースト(ＴａｌｋＢｕｒｓｔ)をグループＰｏＣ呼出に参加した全ての他のＰｏＣクライアントに分配し、グループＰｏＣ呼出に参加したＰｏＣクライアントの情報を提供する。

下記の表２から分かるように、ＰＦは、ＣＦと各ＰｏＣクライアント間のＰｏＣセッションを管理する。特に、ＰＦは、ＰｏＣクライアントが発言権を要求するか、ＣＦがクライアントに発言権を付与する時、ＣＦとＰｏＣクライアントとの間に発言権を中継する役目をする。また、ＰＦは、ＣＦとクライアントとの間にメディアを中継し、ＣＦとＰｏＣクライアントとの間で異なるコーデックを使用したい場合にはトランスコーディングし、同時セッションの場合には、１つのＰｏＣセッションをフィルタリングする役目を実行する。

上述したように、ＰｏＣサービスシステムにおいてＰｏＣユーザーは、自分のＰｏＣ端末機を介してＧＬＭＳ 50にグループ及びグループメンバーに関する情報を入力することができ、ＧＬＭＳ50から伝送された個人またはグループリストを通じて自分が呼び出すことができるＰｏＣユーザーに関する情報を確認することができる。選択的に、ＰｏＣサービス提供者が信頼できるインターネットやイントラネットのような通信網を介して情報を入力することで、ＧＬＭＳ50にグループ及びグループメンバーに関する情報を修正及び管理することができる。

ＰｏＣ呼出サービスを利用するために、ＰｏＣユーザーは、前記ＳＩＰ／ＩＰコア網３０に自分のＰｏＣアドレスを登録する。ＳＩＰ／ＩＰコア網３０では、ＰｏＣユーザーの要請に応じてＰｏＣユーザーに関する情報を格納する。したがって、他のＰｏＣユーザーがＰｏＣグループ呼出を要請しようとする場合には、上述したように、自分の情報を前記ＳＩＰ／ＩＰコア網３０に登録し、ＧＬＭＳ５０から転送されたグループ識別情報を利用して自分のＳＩＰ／ＩＰコア網３０にグループＰｏＣ呼出を要請する。この時、ＳＩＰ／ＩＰコア網３０は、呼出を要請するＰｏＣユーザー情報を利用してアドレス決定とドメイン位置決定過程を実行し、呼び出しを要請するＰｏＣユーザーが登録されたホームＰｏＣサーバーにＰｏＣ通話要請を伝達する。このＰｏＣ通話要請に対してＰｏＣサーバーは、ＰｏＣセッション開設を準備し、ＧＬＭＳ５０サーバーから各々のユーザー情報を獲得した後、該当ＳＩＰ／ＩＰコア網３０にＰｏＣ通話要請信号を伝達する。この時、イントラドメイン内のユーザーに対するＰｏＣ通話要請である場合、ＰｏＣサーバーは、ＰＦ及びＣＦの機能を共に実行する。通話要請されたＰｏＣユーザーを管理するＰｏＣサーバーは、自分に伝達されたＰｏＣユーザーの情報を利用してＳＩＰ／ＩＰコア網３０の位置決定過程を実行した後、ＰｏＣユーザーにＰｏＣ通話を要請する。

図３は、ＰｏＣサーバーのＣＦブロックとＰＦブロックを説明するための概念図である。

図３を参照すれば、ＰｏＣクライアント１１１、１２１、１３１、１４１はＰＦ１１０、１２０、１３０、１４０を介してＣＦ１００に接続してＰｏＣセッションを開設する。ここで、ＣＦ１００で許可した発言要請者に発言権が付与されると、該当ＰｏＣクライアントの発言を基盤としたメディアが各ＰｏＣクライアントに伝送される。

図４は、ＰｏＣユーザーが発言権を獲得する一般的な手続きを示すフローチャートである。

図４を参照すれば、発言権を獲得するため、ＰｏＣセッションがＰｏＣクライアントＡ１１１とＰｏＣクライアントＢ１２１を連結した状態で、ＰｏＣセッション内でどのＰｏＣクライアントも言っていないとき、ＰｏＣクライアントＡ１１１が端末機に設置されたＰｏＣトークボタンを押す。

それによって、ＰｏＣクライアントＡ１１１は発言権を要請するメッセージであるトークバースト要求メッセージをＰａｒｔｉｃｉｐａｔｉｎｇＰｏＣＦｕｎｃｔｉｏｎの役目をするＰＦＡ１１０に伝送し(ステップＳ１０１)、このトークバースト要請メッセージを受信したＰＦＡ１１０はこのＰｏＣセッションのＣｏｎｔｒｏｌｌｉｎｇＰｏＣｆｕｎｃｔｉｏｎの役目をするＰｏＣサーバー、すなわち、ＣＦ１００にメッセージを伝送する(ステップＳ１０１)。

発言権要請メッセージを受信した後、ＣＦ１００はＰｏＣクライアントＡ１１１に発言権を付与するメッセージであるトークバースト確認応答メッセージを伝送し(ステップＳ１０２)、ＰｏＣクライアントＢ１２１にはユーザーＡからＰｏＣクライアントＡ１１１に発言権を付与したと受信トークバーストメッセージを伝送する(ステップＳ１０３)。このメッセージは話者、すなわち、ＰｏＣクライアントＡ１１１のＩＤを含んでいるのでＰｏＣクライアントＢ１２１は誰が話者であるかが分かる。

以後、メディアセッションがオープンされてＰｏＣクライアントＡ１１１からトークバーストがＰｏＣクライアントＢ１２１に伝達される(ステップＳ１０４)。

以上、ＰｏＣセッションが連結された時の発言権を要請する手続きについて説明した。ＰｏＣセッションが連結されなかった場合、ＰｏＣクライアントＡ１１１がＰｏＣクライアントＢ１２１にＰｏＣセッション設定を要請すれば、その中間でＣｏｎｔｒｏｌｌｉｎｇＰｏＣｆｕｎｃｔｉｏｎの役目をするＰｏＣサーバーがＰｏＣクライアントＢ１２１にＰｏＣセッション開設に関するメッセージを伝送する。それによって、ＰｏＣクライアントＢ１２１は承認応答をＣｏｎｔｒｏｌｌｉｎｇＰｏＣｆｕｎｃｔｉｏｎの役目をするＰｏＣサーバーのＣＦ１００に伝送し、ＣＦ１００はＰｏＣクライアントＡ１１１にトークバースト確認応答メッセージを伝送する。このように発言権を受けたＰｏＣクライアントＡ１１１は、このときからＰｏＣトークボタンを押したまま話し始めると、オープンされたメディアセッションを通じて言葉(音声信号に変われたデータファイル)を伝送する。

図５は、端末機で発言権を予約する一般的な手続きを示すフローチャートである。

図５を参照すれば、ＰｏＣユーザーはＰｏＣセッションに参加し、そのＰｏＣセッションに参加している他の参加者の中で少なくとも一名の参加者からトークバースト(ｔａｌｋｂｕｒｓｔ)を受信する(ステップＳ２０１)。そのＰｏＣユーザーが通話するためにはＰｏＣ端末機に具現されたトークボタン(ｔａｌｋｂｕｔｔｏｎ)を押す。ＰｏＣユーザーがトークボタンを押したか否かを判断して(ステップＳ２０２)、ステップＳ２０２で、ＰｏＣユーザーがトークボタンを押したと判断されると、他の参加者がトークバーストを伝送中であるか否かを判断する(ステップＳ２０３)。

ステップＳ２０３で、他の参加者がトークバーストを伝送中ではないと判断されると、他の参加者は発言権を要請してトークバースト付与メッセージ(ＴａｌｋｂｕｒｓｔＧｒａｎｔｍｅｓｓａｇｅ)を受信した後にトークバーストを伝送する(ステップＳ２１０)。

ステップＳ２０３で、もし、他の参加者がトークバーストを伝送中である場合には、発言権管理機能(例えば、‘キュー’機能)をサポートするか否かを判断する(ステップＳ２２０)。他の参加者がトークバーストを伝送中で発言権管理機能がサポートされると、発言権要請時に発言権が発言権管理者で予約される(ステップＳ２３０)。この発言権はＣｏｎｔｒｏｌｌｉｎｇＰｏＣｆｕｎｃｔｉｏｎの役目をするＰｏＣサーバーのキューに予約される。

ステップＳ２２０で、キュー機能がサポートされないと判断されると、端末機で発言権を要請しない場合もある。そして、端末機で発言権を要請してもＣｏｎｔｒｏｌｌｉｎｇＰｏＣｆｕｎｃｔｉｏｎの役目をするＰｏＣサーバーで発言権の予約を拒絶するようになる(ステップＳ２４０)。

図６は、ＰｏＣサーバーで発言権を管理する一般的な過程を示すフローチャートである。

図６を参照すれば、ＰｏＣセッションでのＰｏＣサーバーの状態は、アイドル(ｉｄｌｅ)あるいはＰｏＣユーザーのトークバーストを伝送する二つの状態に分けることができる(ステップＳ３０１)。ＣＦの役目をするＰｏＣサーバーが発言権要請を受けた時(ステップＳ３０２)、発言権管理機能(例えば、‘キュー’機能)をサポートして(ステップＳ３０３)、他の参加者がトークバーストを伝送中であれば(ステップＳ３１０)、発言権管理リストに要請を受けた発言権を予約する(ステップＳ３１１)。ステップＳ３１０で、他の参加者がトークバーストを伝送していないと判断されると、発言権を要請したＰｏＣクライアントの端末にＴａｌｋｂｕｒｓｔＧｒａｎｔｍｅｓｓａｇｅを伝送し、ＰｏＣユーザーから受信されたトークバーストをＰｏＣセッションに参加している他の聴取者に伝送(中継)する(ステップＳ３１２)。

ＣＦの役目をするＰｏＣサーバーが発言権要請を受けた時、発言権管理機能をサポートしないで他の参加者がトークバーストを伝送中であれば(ステップＳ３２０)、要請された発言権を拒絶する(ステップＳ３２１)。発言権管理機能をサポートしないで他の参加者がトークバーストを伝送しないと、発言権を要請したＰｏＣクライアントの端末にＴａｌｋｂｕｒｓｔＧｒａｎｔｍｅｓｓａｇｅを伝送し、ＰｏＣユーザーから受信されるトークバーストをＰｏＣセッションに参加している他の聴取者に伝送(中継)する(ステップＳ３２２)。

図７は、一般的なＰｏＣシステムで発言権を予約する過程を示すフローチャートである。

図７を参照すれば、ＰｏＣクライアントＢ１２１がトークバーストを伝送している中に(ステップＳ４０１)、ＰｏＣクライアントＡ１１１がＴａｌｋｂｕｒｓｔｒｅｑｕｅｓｔ、すなわち、発言権を要請する(ステップＳ４０２)。この場合、ＣＦの役目をするＰｏＣサーバーＸ１００が発言権管理リスト(例えば、‘キュー’)に発言権を予約して(ステップＳ４０３)、その予約された発言権に関する位置情報(発言手順)をＰｏＣクライアントＡ１１１に伝送する(ステップＳ４０４)。

この時、予約された発言権位置情報はＲＴＣＰＡＰＰパケットのＴａｌｋｂｕｒｓｔＱｕｅｕｅＰｏｓｉｔｉｏｎＳｔａｔｕｓメッセージを通じて報知できる。このような方式でＰｏＣユーザーは自分が要請した発言権が発言権管理リストに予約されたか否かが分かる。

図８は、一般的なＰｏＣシステムで発言権管理リストに予約された発言権がある場合、他の参加者が発言を終了した時に他の発言権を有した参加者がトークバーストを伝送する過程を示すフローチャートである。

図８を参照すれば、ＰｏＣクライアントＡ１１１がトークバーストを伝送して(ステップＳ５０１)、ＰｏＣユーザーは通話が終わってＰｏＣ端末機に具現されたトークボタンを外す。それでは、ＰｏＣクライアントＡ１１１は最後に伝送する必要があるパケットをＣＦを実行するＰｏＣサーバーＸ１００に伝送し(ステップＳ５０２)、トークバースト伝送が終わったという完了メッセージであるＴａｌｋｂｕｒｓｔＣｏｍｐｌｅｔｅＭｅｓｓａｇｅを伝送する(ステップＳ５０３)。この時、ＰｏＣサーバーＸ１００は最後受信したパケットをＰｏＣクライアントＢ１２１に伝送し(ステップＳ５０２)、ＰｏＣクライアントＡ１１１から受けたＴａｌｋｂｕｒｓｔＣｏｍｐｌｅｔｅＭｅｓｓａｇｅを通じて伝送が終了したことを認知して、次の発言権を有したＰｏＣクライアントＢ１２１に発言しても良いという許可のＴａｌｋｂｕｒｓｔＣｏｎｆｉｒｍＭｅｓｓａｇｅを伝送する(ステップＳ５０４)。前記ＴａｌｋｂｕｒｓｔＣｏｎｆｉｒｍＭｅｓｓａｇｅを受信したＰｏＣクライアントＢ１２１は、ＰｏＣユーザーＢの端末機の表示部に発言しても良いという内容を表示する。この時からＰｏＣユーザーＢはトークボタンを押したまま話す(ステップＳ５０５)。

前記のように発言権管理リスト(例えば、‘キュー’)に発言権を予約する従来の技術は、ＰｏＣセッションがアイドル状態である場合にだけトークバースト要請(Ｔａｌｋｂｕｒｓｔｒｅｑｕｅｓｔ)が可能な機能と比較して効果的にＰｏＣシステムを運用することができる。

しかし、前記従来技術は、ＰｏＣシステム環境で会議(ｃｏｎｆｅｒｅｎｃｅｃａｌｌ)する場合は、次のような問題点が導出される。

電話会議(ｃｏｎｆｅｒｅｎｃｅｃａｌｌ)の場合、一つの主題に対して多いＰｏＣユーザーが発言しようとトークバーストを要請するようになる。例えば、予約された発言権が２０個程度になった状態で、おおよそ３人のＰｏＣユーザーが発言した時、結論が容易に出たか、あるいは緊急に他の案件に対して論議しなければならない事態が発生する場合、前記従来技術方式では仕方なく残った１７人のＰｏＣユーザーが全部発言権を受けて発言した後こそ新しい案件に移ることができる。これはＰｏＣシステムにおいて時間と有/無線資源を浪費する原因になる。

本発明の目的は、ＰｏＣシステムのセッション管理サーバーに発言権管理リストをリセットするための機能、すなわち、すべての予約された発言権を一挙に取り消すことができる機能を提供し、任意のＰｏＣユーザーから発言権リセットが要請されると、認証可否によって発言権をリセットするＰｏＣシステムでの発言権除去方法及びそのシステムを提供することにある。

本発明の他の目的は、セッション管理サーバーに発言権リセットを要請できるように発言権リセットを意味するフィールドが定義されたメッセージフォーマットを提供することにある。

本発明の一側面によれば、ＰｏＣシステムの発言権除去方法は、ＰｏＣクライアントがセッション管理サーバーに発言権管理リストに予約された発言権除去要請メッセージを送信するステップと、前記セッション管理サーバーが前記ＰｏＣクライアントから前記発言権除去要請メッセージを受信して、前記予約された発言権を除去するステップと、を含む。

本発明の他の側面によれば、ＰｏＣシステムで予約された発言権を除去方法は、ＰｏＣクライアントがセッション管理サーバーに発言権管理リストに予約された発言権の除去を要請するステップと、前記セッション管理サーバーが前記ＰｏＣクライアントから発言権除去要請メッセージを受信して、前記ＰｏＣクライアントが発言権除去権限があるか否かを判断するステップと、前記ＰｏＣクライアントが前記発言権除去権限がないと判断された場合、前記予約された発言権除去要請を拒絶するステップと、を含む。

本発明のまた他の側面によれば、ＰｏＣシステムは、予約された発言権の除去要請メッセージを送信するＰｏＣクライアントと、前記ＰｏＣクライアントから前記発言権除去要請メッセージを受信して、前記予約された発言権を除去するセッション管理サーバーと、を含む。

本発明のまた他の側面によれば、ＰｏＣシステムは、予約された発言権の除去要請メッセージを送信するＰｏＣクライアントと、前記ＰｏＣクライアントから前記メッセージを受信して、前記ＰｏＣクライアントが発言権除去権限があるか否かを判断し、その判断結果、前記発言権除去権限がない場合、前記予約された発言権の除去要請を拒絶するセッション管理サーバーと、を含む。

本発明のまた他の側面によれば、ＰｏＣ端末は、セッション管理サーバーから発言権除去要請前と発言権除去要請時の中でいずれの一時点で発言権除去権限の承認を受けて、前記セッション管理サーバーに発言権除去要請メッセージを送信する。

本発明によれば、ＰｏＣユーザーが参加しているセッションで非常に多い発言権が予約されているので通話及び会議が進行されない場合、予約された発言権を全部取り消すようにする。したがって、ＰｏＣセッションで行われている対話(Ｃａｌｌｓ)を効果的に管理することができる。

以下、本発明の属する分野における通常の知識を有する者が本発明を容易に実施できるように本発明の好ましい実施例を添付の図面を参照して詳細に説明する。

ＯＭＡ（ＯｐｅｎＭｏｂｉｌｅＡｌｌｉａｎｃｅ)で定義したＰｏＣ(Ｐｕｓｈ−ｔｏ−ｔａｌｋ−ｏｖｅｒ−ｃｅｌｌｕｌａｒ)システムでは、ＲＴＣＰＡＰＰ(Ｒｅａｌ−ｔｉｍｅＴｒａｎｓｐｏｒｔＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌＡＰＰｌｉｃａｔｉｏｎ)パケットを利用したＴＢＣＰ(ＴａｌｋＢｕｒｓｔＣｏｎｔｒｏｌｐｒｏｔｏｃｏｌ)が使用される。このＴＢＣＰは発言権を要請する時、発言権を付与する時、発言権を拒絶する時などのメッセージを伝送する役目をする。

前記ＴＢＣＰの機能は、図面を参照して詳しく説明する。

図９は、本発明を具現するためのＲＴＣＰＡＰＰパケットを利用したトークバースト発言権リセット要請メッセージフォーマットを示す図で、図１０は、図９のメッセージフォーマットを詳細に示す図である。

図９及び図１０を参照すれば(ＩＥＴＦ(ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ)で定義しているＲＦＣ３５５０参照)、ＲＴＣＰＡＰＰパケットで一番目の２ビットフィールドは、ＲＴＰのバージョン(ｖｅｒｓｉｏｎ)用である(本発明ではｖｅｒｓｉｏｎ＝２を示す)。

二番目のビットフィールドは、パッディングビット(ｐａｄｄｉｎｇｂｉｔ)用である。パッディングビットが与えられると、ペイロードに含まれない１または２個のパッディングオクテット(ｐａｄｄｉｎｇｏｃｔｅｔ)が付加されたこが分かる。

三番目の５ビットフィールドは、サブタイプ(ｓｕｂｔｙｐｅ)を示す(ＯＭＡＰｏＣＵｓｅｒｐｌａｎｅｓｐｅｃｉｆｉｃａｔｉｏｎ文書参照)。このサブタイプを利用してＲＴＣＰＡＰＰパケットがどのようなＴＢＣＰの機能を実行しているかが分かる。

例えば、現在ＯＭＡでドラフトされているスペックでは、サブタイプがＴＢＣＰトークバースト要請メッセージ(Ｔａｌｋｂｕｒｓｔｒｅｑｕｅｓｔｍｅｓｓａｇｅ)である場合には、サブタイプの値が０００００で定義されており、ＴＢＣＰトークバースト付与メッセージ(ＴａｌｋｂｕｒｓｔＧｒａｎｔｅｄｍｅｓｓａｇｅ)である場合には、００００１で定義されている。現在まで１６個のＴＢＣＰトークバースト制御メッセージ(Ｔａｌｋｂｕｒｓｔｃｏｎｔｒｏｌｍｅｓｓａｇｅ)を定義しているので、前記サブタイプの値は０１１１１までに定義される。残りの１６個の値は新しく発生するＴＢＣＰトークバースト制御メッセージ(Ｔａｌｋｂｕｒｓｔｃｏｎｔｒｏｌｍｅｓｓａｇｅ)のために予備(ｒｅｓｅｒｖｅｄ)状態になっている。

したがって、本発明では、１００００〜１１１１１の値の中でいずれの一つを選択してサブタイプ値を付与して他のＴＢＣＰトークバースト制御メッセージ値と区分することができる。ここで、前記残っているサブタイプ値１００００を使用して他のＴＢＣＰトークバースト制御メッセージ値と区分する。

しかし、この値が残ったどんな値を有するかに関係なくメッセージの内容が発言権管理リスト(Ｑｕｅｕｅ)に予約された発言権を全部削除する機能を示す場合には、同一なＴＢＣＰトークバースト制御メッセージと見なす。四番目の１バイトフィールドはペイロードタイム用である。それはよく知られたプロトコルである“ＲＴＣＰ”を示すためのフォーマットの中で一つである。“２０４”は“ＲＴＣＰ”ＡＰＰの制御フォーマットを意味する。“２０１”は“ＴＲＣＰ”の“ＲｅｃｅｉｖｅＲｅｐｏｒｔ”を意味することのように多様なタイプがある。

五番目の２バイトフィールドはＬｅｎｇｔｈフィールドである。このフィールドに２の値が使用されると、このメッセージが４バイトオクテット(ｏｃｔｅｔ)２個があることを示す。後にペイロードが付いたらペイロードフィールドで全体４バイトオクテットがいくつあるかそのペイロード長さを示す。六番目の４バイトフィールドは同期化ソース(ＳｙｎｃｈｒｏｎｉｚａｔｉｏｎＳｏｕＲＣｅ)フィールドである。前記ＳＳＲＣ識別子はＲＴＰヘッダーに載せて運ばれ、ＲＴＣＰパケットの多様なフィールドはＲＴＰセッション内で唯一に国際的に要求されるランダムな３２ビット数である。同一な数を選択するためには、同一ネットワークに参加するか、同一な時間に開始することより、手順によって注意して数を選択することが一番重要である。

このフィールドは、発言権管理リストに予約されたすべての発言権の削除を要請するＰｏＣクライアントの同期化ソースを含んでいるので、誰が要請したかを区分可能にする。

七番目の４バイトフィールドはＡＳＣＩＩで表現され、前記パケットがＰｏＣバージョン１で使用されていることを示すフィールドである。

図１１は、本発明による発言権を除去する過程を示すフローチャートである。

図１１を参照すれば、先に予約された発言権を削除するためには発言権削除権限を有している必要がある。例えば、参加しているＰｏＣセッションの開設者、すべての参加者が認定したＰｏＣセッション議長、またはサービス提供者などがこのような権限を有することができる。

もし、誰もこの機能を使用可能にする場合、意思を発言するための発言権を何の理由もなく削除する場合が発生できるので、これを防止するためには権限認証手続きが隋伴されなければならない。

このために、任意のユーザー(ここでは、‘ＰｏＣクライアントＡ’とする)が自分が発言権管理機能を使用するための権限を有するため、それに適当なユーザーであることをＣｏｎｔｒｏｌｌｉｎｇＰｏＣｆｕｎｃｔｉｏｎの役目をするＰｏＣサーバーであるＣＦ１００に登録する(ステップＳ１００１、ステップＳ１００２)。

権限登録はＰｏＣセッション開設時のＩＮＶＩＴＥ＆ＯＫ方法を利用するかあるいは新しいＴＢＣＰを利用して実行することができる。

一つの実施例として、初めてＰｏＣセッションを開設する時、ＣＦはＩＮＶＩＴＥメッセージを通じて誰がそのセッションを開設したか分かるようになる。これによって、ＣＦはＰｏＣセッション開設者のＳＩＰＵＲＩを格納する。“ＵRL”はＰｏＣセッション開設者の“ＵＲＩ”の中で一つである。ＰｏＣクライアントが発言権リセット要請メッセージを伝送した場合に、ＣＦでは要請したＰｏＣクライアントがＰｏＣセッション開設者であるか否かをＳＩＰＵＲＩを通じてチェックしてトークバーストリセット要請を実行する。

他の実施例として、新しいＴＢＣＰを利用することができる。

ＲＴＣＰＡＰＰフォーマットでサブタイプ番号を１０００１あるいは１０００１から１１１１１の間の番号の中で一つを付与して、ＴＢＣＰメッセージ、すなわち、権限登録要請(Ａｕｔｈｏｒｉｚａｔｉｏｎｒｅｇｉｓｔｒａｔｉｏｎｒｅｑｕｅｓｔ)メッセージを作り出す。

ＰｏＣクライアントが前記ＴＢＣＰメッセージをＣＦに送信すれば、ＣＦでは前記ＴＢＣＰメッセージを受信した後、ＰｏＣサービス提供者の政策によって適当なユーザーであるか否かを判断して(ステップＳ１１００)、要請したＰｏＣクライアントに承認(Ｐｅｒｍｉｓｓｉｏｎ)メッセージを伝送する(ステップ１２００)。

発言権管理リストに予約された発言権を全部削除することを希望して、それに適当な権利を有したＰｏＣクライアントが、ＴａｌｋｂｕｒｓｔＱｕｅｕｅＲｅｓｅｔをＣＦ１０００に要請すれば(ステップＳ１３００)、ＣＦ１０００では発言権をリセットできる権限を有しているか否かに対する認証過程を実行する(ステップＳ１４００)。

ステップＳ１４００で、認証されると、ＣＦはＴａｌｋｂｕｒｓｔＱｕｅｕｅをリセットさせて(ステップＳ１５００)、これに対する結果をＴａｌｋｂｕｒｓｔＱｕｅｕｅＲｅｓｅｔを要請したＰｏＣクライアントに通知する(ステップＳ１６００)。

本発明は、ＰｏＣシステムに限定されない。例えば、３ＧＰＰや３ＧＰＰ２で標準化中であるか完成されたＩＭＳ(ＩＰｍｕｌｔｉｍｅｄｉａＣＮ)網を利用してｈａｌｆｄｕｐｌｅｘの通話形態を利用して発言権を制御するサーバーを有した全てのシステムの適用することができる。

以上において説明した本発明は、本発明が属する技術の分野における通常の知識を有する者であれば、本発明の技術的思想を逸脱しない範囲内で、様々な置換、変形及び変更が可能であるので、上述した実施例及び添付された図面に限定されるものではない。

図１は、一般的なＰｏＣサービスシステムを説明するための概念図である。図２は、一般的なＰｏＣサーバーの構造を示す概念図である。図３は、ＰｏＣサーバーのＣＦブロックとＰＦブロックを説明するための概念図である。図４は、ＰｏＣユーザーが発言権を獲得する一般的な手続きを示すフローチャートである。図５は、端末機で発言権を予約する一般的な手続きを示すフローチャートである。図６は、ＰｏＣサーバーで発言権を管理するための一般的な手続きを示すフローチャートである。図７は、一般的なＰｏＣシステムで発言権を予約するための過程を示すフローチャートである。図８は、一般的なＰｏＣシステムで発言権管理リストに予約された発言権がある場合、ほかの参加者のうち一人が発言を終了したときに、その次の発言権を有した参加者がトークバーストを伝送する過程を示すフローチャートである。図９は、本発明を具現するためのＲＴＣＰＡＰＰパケットを利用したトークバースト発言権リセット要請メッセージフォーマットを示す図である。図１０は、図９のメッセージフォーマットを詳細に示す図である。図１１は、本発明によって発言権を除去する過程を示すフローチャートである。

符号の説明

Ｓ１００１権限登録
Ｓ１１００承認可否判断
Ｓ１２００承認
Ｓ１３００発言権予約リセット要請
Ｓ１４００認証判断
Ｓ１５００発言権予約リセット
Ｓ１６００結果通知

Claims

ＰｏＣシステムの発言権除去方法であって、
ＰｏＣクライアントがセッション管理サーバーに発言権管理リストに予約された発言権除去要請メッセージを送信するステップと、
前記セッション管理サーバーが前記ＰｏＣクライアントから前記発言権除去要請メッセージを受信して、前記予約された発言権を除去するステップと、
を含むことを特徴とするＰｏＣシステムの発言権除去方法。
前記予約された発言権を除去するステップは、
前記セッション管理サーバーが、前記発言権除去要請メッセージを送信したＰｏＣクライアントが発言権除去権限がある否かを判断するステップと、
前記ＰｏＣクライアントが前記発言権除去権限がある場合、前記予約された発言権を除去するステップと、
を含むことを特徴とする請求項１に記載のＰｏＣシステムの発言権除去方法。
ＰｏＣシステムの予約された発言権除去方法であって、
ＰｏＣクライアントがセッション管理サーバーに発言権管理リストに予約された発言権の除去を要請するステップと、
前記セッション管理サーバーが前記ＰｏＣクライアントから発言権除去要請メッセージを受信して、前記ＰｏＣクライアントが発言権除去権限があるか否かを判断するステップと、
前記ＰｏＣクライアントが前記発言権除去権限がない場合、前記予約された発言権の除去要請を拒絶するステップと、
を含むことを特徴とするＰｏＣシステムの予約された発言権除去方法。
前記ＰｏＣクライアントが発言権管理リストに予約された発言権の除去を要請するステップは、前記セッション管理サーバーから前記発言権除去権限の承認を受けるステップを含むことを特徴とする請求項３に記載のＰｏＣシステムの予約された発言権除去方法。
前記発言権除去権限の承認を受けるステップは、発言権除去要請前と前記発言権除去要請時の中でいずれの一時点で実行されることを特徴とする請求項４に記載のＰｏＣシステムの予約された発言権除去方法。
前記発言権除去要請メッセージは、ＲＴＣＰ(ｒｅａｌ-ｔｉｍｅｔｒａｎｓｐｏｒｔｃｏｎｔｒｏｌｐｒｏｔｏｃｏｌ)ＡＰＰ(ａｐｐｌｉｃａｔｉｏｎ)パケットのＴＢＣＰ(ＴａｌｋＢｕｒｓｔＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ)メッセージを利用することを特徴とする請求項３に記載のＰｏＣシステムの予約された発言権除去方法。
前記ＴＢＣＰメッセージは、ＲＴＣＰＡＰＰパケットのサブタイプ(ｓｕｂｔｙｐｅ)フィールドの値として予備(ｒｅｓｅｒｖｅｄ)値の中でいずれの一つを選択することを特徴とする請求項６に記載のＰｏＣシステムの予約された発言権除去方法。
ＰｏＣシステムであって、
予約された発言権の除去要請メッセージを送信するＰｏＣクライアントと、
前記ＰｏＣクライアントから予約された発言権の除去要請メッセージを受信して、前記予約された発言権を除去するセッション管理サーバーと、
を含むことを特徴とするＰｏＣシステム。
前記セッション管理サーバーは、前記ＰｏＣクライアントが発言権除去権限がある否かを判断して、前記発言権除去権限がある場合、前記予約された発言権を除去することを特徴とする請求項８に記載のＰｏＣシステム。
ＰｏＣシステムであって、
予約された発言権の除去要請メッセージを送信するＰｏＣクライアントと、
前記ＰｏＣクライアントから前記予約された発言権の制御要請メッセージを受信して、前記ＰｏＣクライアントが発言権除去権限があるが否かを判断して、前記発言権除去権限がない場合、前記予約された発言権の除去要請を拒絶するセッション管理サーバーと、
を含むことを特徴とするＰｏＣシステム。
前記発言権除去要請メッセージは、ＲＴＣＰ(ｒｅａｌ-ｔｉｍｅｔｒａｎｓｐｏｒｔｃｏｎｔｒｏｌｐｒｏｔｏｃｏｌ)ＡＰＰ(ａｐｐｌｉｃａｔｉｏｎ)パケットのＴＢＣＰ(ＴａｌｋＢｕｒｓｔＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ)メッセージを利用することを特徴とする請求項１０に記載のＰｏＣシステム。
前記ＴＢＣＰメッセージは、ＲＴＣＰＡＰＰパケットのサブタイプ(ｓｕｂｔｙｐｅ)フィールド値として予備(ｒｅｓｅｒｖｅｄ)値の中でいずれの一つを選択することを特徴とする請求項１１に記載のＰｏＣシステム。
ＰｏＣ端末であって、
セッション管理サーバーから発言権除去要請前と発言権除去要請時の中でいずれの一時点で発言権除去権限の承認を受ける手段と、
前記セッション管理サーバーに発言権除去要請メッセージを送信する手段と、
を含むことを特徴とするＰｏＣ端末。
前記発言権除去要請メッセージは、ＲＴＣＰ(ｒｅａｌ−ｔｉｍｅｔｒａｎｓｐｏｒｔｃｏｎｔｒｏｌｐｒｏｔｏｃｏｌ)ＡＰＰ(ａｐｐｌｉｃａｔｉｏｎ)パケットのＴＢＣＰ(ＴａｌｋＢｕｒｓｔＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ)メッセージであることを特徴とする請求項１３に記載のＰｏＣ端末。
前記ＴＢＣＰメッセージは、ＲＴＣＰＡＰＰパケットのサブタイプ(ｓｕｂｔｙｐｅ)フィールドの値として予備(ｒｅｓｅｒｖｅｄ)値の中でいずれの一つを定義することを特徴とする請求項１４に記載のＰｏＣ端末。