プッシュツートークオーバーセルラー網でＰｏＣ参加者の意見を収集する方法及びそのシステム
【課題】本発明は、ＰｏＣシステムに意見を収集することができる意見投票機能を提供して、ユーザが意見を収集する時に、発言権使用可否と関係なく意見投票手続を行うプッシュツートークオーバーセルラー網（PoC Network）におけるＰｏＣクライアント意見収集方法及びそのシステムを提供する。
【解決手段】その方法は、任意のユーザからセッション管理サーバーに投票機能使用要請及び投票しようとする内容を含むメッセージを伝達する段階と、投票機能がグループ内の他のユーザにより占有された状態であるか否かを判断する段階と、投票機能が他のユーザにより占有されていないものと判断されれば、グループに属する他のユーザに投票しようとする内容を伝達する段階と、投票しようとする内容に対する応答を伝達する段階とを含む。
【解決手段】その方法は、任意のユーザからセッション管理サーバーに投票機能使用要請及び投票しようとする内容を含むメッセージを伝達する段階と、投票機能がグループ内の他のユーザにより占有された状態であるか否かを判断する段階と、投票機能が他のユーザにより占有されていないものと判断されれば、グループに属する他のユーザに投票しようとする内容を伝達する段階と、投票しようとする内容に対する応答を伝達する段階とを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プッシュツートークオーバーセルラー（Push to talk over Cellular：ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法に関する。
【背景技術】
【０００２】
移動通信が画期的に発展し、通信網が拡大されるにしたがって、携帯電話(Cellular Phone)を用いたサービスやアプリケーションがさらに拡張され且つ多様化されている。同時に、位置サービス、マルチメディアサービス、ＰＴＴ（push to talk）サービスのような付加的なサービスへの携帯電話ユーザの要求も増大している。ＰＴＴサービスは、無線機器やＴＲＳ(Trunk Radio System)によって可能であったグループ通話と音声通話はもちろん、インスタントメッセンジャー、状態表示など多様な付加機能を支援する。
【０００３】
現在、移動通信網においてこのようなＰＴＴ（Push to Talk）機能を導入するＰｏＣ（Push-to-talk over cellular:以下、ＰｏＣという）サービスに対する標準化作業が論議されている。ＰｏＣサービスの特徴のうち１つは、ユーザが複数のＰｏＣセッションに属していて、必要に応じてＰｏＣセッション間を移動しつつ通話をすることができることである。このような特徴は、移動通信サービスを定義している団体であるＯＭＡ（Open Mobile Alliance）に明示された要求事項である。
【０００４】
図１は、一般的なＰｏＣ（Push-to-talk over cellular）サービスシステムを概略的に示す図である。図１を参照すれば、ＰｏＣクライアント１０は、移動端末に設けられるサービス要請者であり、一般的にアクセス網２０を介してＳＩＰ（session Initiation Protocol）及びＩＰ（Internet Protocol）マルチメディアを支援するＳＩＰ／ＩＰコア３０網に連結される。
【０００５】
ＰｏＣクライアント１０は、ＰｏＣユーザ端末機に常駐し、ＰｏＣサービスへの接続を提供する。ＰｏＣクライアント１０は、主としてＰｏＣセッションを生成し、ＰｏＣセッションに参加し、ＰｏＣセッションを終了する。また、ＰｏＣクライアント１０は、トークバーストを形成し伝達する機能、インスタントパーソナルアラート(Instant Personal alert)を支援する機能、Ｐｏｃサービスに接続する時、認証を行う機能などの役目を行う。以下、別の言及がない限り、ＰｏＣクライアント１０とＰｏＣユーザは、Ｐｏｃサービス加入者と同じものとする。
【０００６】
ＳＩＰ／ＩＰコア３０は、ＰｏＣサービスを支援するために、ＰｏＣサーバ６０と、ＧＬＭＳ（Group List and Management System）５０、及びプレゼンスサーバ７０に連結される。
【０００７】
ＰｏＣサーバ６０は、ＰｏＣセッションを維持、管理するControlling PoC Function（ＣＦ）や、一対一のＰｏＣ通話や一対多通話(又はグループ通話)のためのＰｏＣセッションに参加するためのParticipating PoC Function（ＰＦ）などの機能を有する。
【０００８】
以下、ＰｏＣサーバ内の機能別ブロックを図２を参照して説明する。図２は、一般的なＰｏＣサーバの構成を示す概念図である。
【０００９】
ＰｏＣサーバは、ＰｏＣセッションの維持及び管理を全般的に制御するためのControlling PoC Function（以下、ＣＦという）と、各セッション間の維持管理を制御するParticipating PoC Function（以下、ＰＦという）を共に行う。以下、下記の表１、２を参照して説明する。
【００１０】
【表１】
表１に示されるように、ＣＦを行うＰｏＣサーバ（又はControlling PoCサーバ）は、ＰｏＣセッションを管理する役目をする。特に、Controlling PoCサーバは、ＰｏＣクライアントから発言権要請を受信し、順序を定め、クライアントに権限を付与する。Controlling PoCサーバは、任意のＰｏＣクライアントが要請したトークバーストをグループＰｏＣ呼に参加した全ての他のＰｏＣクライアントに分配し、グループＰｏＣ呼に参加したＰｏＣクライアントの情報を提供する。
【００１１】
下記表２に示されるように、ＰＦを行うＰｏＣサーバ（又はParticipating PoCサーバ）は、Controlling PoCサーバと各ＰｏＣクライアント間のＰｏＣセッションを管理する。特に、Participating PoCサーバは、ＰｏＣクライアントが発言権を要求したり、Controlling PoCサーバがＰｏＣクライアントに発言権を付与する時、Controlling PoCサーバとＰｏＣクライアントとの間で発言権を中継する役目をする。また、Participating PoCサーバは、Controlling PoCサーバとＰｏＣクライアントとの間にメディアを中継する役目、異なるコーデック間のトランスコーディングを行い、同時ＰｏＣセッションの場合には、１つのＰｏＣセッションで話している時、他のＰｏＣセッションでも話しながらＰｏＣユーザの選択によって１つをフィルタリングする役目を行う。
【００１２】
【表２】
前述したようなＰｏＣサービスシステムにおいて、ＰｏＣユーザの端末機を介してＧＬＭＳ５０にグループ及びグループメンバーに関する情報を入力することができ、ＧＬＭＳ５０から伝達された個人またはグループ目録を通じて自身が呼び出すことができる他のＰｏＣユーザの情報を受信することができる。あるいは、グループ及びグループメンバーの生成、修正及び管理のために、インターネットやイントラネットのような通信網を介してＧＬＭＳ５０に前記グループ及びグループメンバーに関する情報を入力する方法もある。
【００１３】
ＰｏＣ呼サービスを利用するために、ＰｏＣユーザは、ＳＩＰ／ＩＰコア３０にＰｏＣアドレスを登録する。ＳＩＰ／ＩＰコア３０は、ＰｏＣユーザの要請によりＰｏＣユーザに関する情報を格納する。したがって、他のＰｏＣユーザがグループＰｏＣ呼出を試みる場合、ＰｏＣユーザは、自身の情報をＳＩＰ／ＩＰコア３０にまず登録し、ＧＬＭＳ５０から伝達されたグループ識別情報を利用して自身のＳＩＰ／ＩＰコア３０にグループＰｏＣ呼を要請する。この時、ＳＩＰ／ＩＰコア３０は、要請するＰｏＣユーザ情報を利用してアドレス決定とドメイン位置決定を行った後、要請するＰｏＣユーザが登録されたホームＰｏＣサーバにＰｏＣ呼要請を伝達する。ＰｏＣサーバは、このようなＰｏＣ呼要請に対してＰｏＣセッション開設を準備し、ＧＬＭＳ５０から各ユーザ情報を獲得した後、該当ＳＩＰ／ＩＰコアにＰｏＣ呼要請信号を伝達する。イントラドメイン内のユーザに対するＰｏＣ呼要請の場合、ＰｏＣサーバは、ＰＦ及びＣＦの機能を共に行う。通話要請されたＰｏＣユーザを管理するＰｏＣサーバは、自身に伝達されたＰｏＣユーザの情報を利用してＳＩＰ／ＩＰコア３０の位置決定後、ＰｏＣユーザにＰｏＣ呼を要請する。
【００１４】
図３は、ＰｏＣサーバのＣＦブロックとＰＦブロックを概略的に示す図である。図３を参照すれば、ＰｏＣクライアント１１１、１２１、１３１、１４１は、ＰＦ１１０、１２０、１３０、１４０を介してＣＦ１００に接続してＰｏＣセッション開設を提供する。ここで、ＣＦ１００で許諾した発言要請者に発言権が付与されれば、該当ＰｏＣクライアントの発言を基盤とするメディアが各ＰｏＣクライアントに伝達される。
【００１５】
図４は、ＰｏＣユーザが発言権を獲得する一般的な手続に関する信号の流れを示す図である。
【００１６】
図４を参照すれば、発言権を獲得するために、ＰｏＣセッションがクライアントＡ １１１とクライアントＢ １２１を連結した状態でＰｏＣセッション内にいずれのＰｏＣクライアントも話していない時、ＰｏＣクライアントＡ １１１がＰｏＣ端末機に設置されたＰｏＣトークボタンを押す。
【００１７】
それにより、ＰｏＣクライアントＡ １１１は、発言権を要請するトークバースト要請（Talk Burst Request）メッセージをParticipating PoC functionの役目をするＰＦ Ａ １１０に伝達する（Ｓ１０１）。すると、ＰＦ Ａ １１０は、このセッションのControlling PoC functionの役目をするControlling PoCサーバ、すなわちＣＦ １００に前記トークバースト要請メッセージを伝達する（Ｓ１０１）。
【００１８】
ＣＦ １００は、トークバースト要請メッセージを受信した後、ＰｏＣクライアントＡ １１１に発言権を付与するトークバースト確認応答（Talk Burst Confirm Response）メッセージを伝達し（Ｓ１０２）、ＰｏＣクライアントＢ １２１にＰｏＣクライアントＡ １１１に発言権を付与した旨のユーザＡからのトークバースト受信（Receiving Talk Burst from User A）メッセージを送る（Ｓ１０３）。このメッセージには、話者、すなわちＰｏＣクライアントＡ １１１のＩＤが含まれており、これにより、ＰｏＣクライアントＢ １２１は、誰が話者なのかを把握することができる。
【００１９】
そして、メディアセッションが開かれ、ＰｏＣクライアントＡ １１１からトークバーストメディアがＰｏＣクライアントＢ １２１に伝達される（Ｓ１０４）。
【００２０】
しかし、前述のような従来技術は、グループＰｏＣ通話において、全体の意見を全て聞いて収集しようとする場合に、発言権を要請した全ての人の意見を考慮しなければならないので、発言権付与時間や、発言権が付与されたときの意見を提示する時間などに関する全ての手続をグループ員の数だけ行わなければならない。このため、手続が複雑であり、多くの時間が浪費される。
【発明の開示】
【発明が解決しようとする課題】
【００２１】
本発明の目的は、ＰｏＣシステムに意見を収集することができる意見投票機能を提供して、ユーザが意見を収集する時に、発言権の使用可否と関係なく意見投票手続を行うことができるＰｏＣネットワークにおけるＰｏＣクライアントの意見を収集する方法及びそのシステムを提供することにある。
【課題を解決するための手段】
【００２２】
本発明によれば、グループ内の任意のユーザからセッション管理サーバに投票機能使用要請及び投票しようとする内容を含むメッセージを伝達する段階と、セッション管理サーバで投票機能がグループ内の他のユーザにより占有された状態であるか否かを判断する段階と、セッション管理サーバで投票機能が他のユーザにより占有されていないものと判断されれば、グループに属する他のユーザに投票しようとする内容を伝達する段階と、他のグループユーザにより投票しようとする内容に対する応答を伝達する段階と、を含むプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法が提供される。
【００２３】
本発明によれば、グループ内の任意のユーザによりセッション管理サーバに投票機能の使用を要請する段階と、セッション管理サーバで投票機能が他のユーザにより占有された状態であるか否かを判断する段階と、セッション管理サーバで投票機能がグループ内の他のユーザにより占有されていないものと判断されれば、現在投票機能使用を要請したユーザに投票機能使用可能を通知する段階と、投票機能使用可能信号を受信したユーザが、投票しようとする内容をセッション管理サーバに伝達する段階と、セッション管理サーバでグループ内の他のユーザに投票しようとする内容を伝達する段階と、他のグループユーザが、投票しようとする内容に対する応答を送信する段階と、を含むＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法が提供される。
【００２４】
本発明によれば、投票機能の使用を要請する任意のクライアントと、任意のクライアントにより要請された投票機能に参加する少なくとも１つ以上のクライアントと、任意のクライアントから投票機能要請が伝達されれば、投票機能が他のユーザにより占有されているか否かを判断し、投票機能が他のユーザにより占有されていない場合、グループに属する他のユーザに投票しようとする内容を伝達するセッション管理サーバと、を含むＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステムが提供される。
【発明の効果】
【００２５】
本発明によれば、ＰｏＣユーザが、自身が参加しているグループ通話に多くの人々が参加している場合において、意思決定をしなければならない状況の発生時に、発言権と関係なく意見投票機能を１回に行うことによって、同時にいろいろな人々から意見を収集することができるようになる。
【００２６】
したがって、従来の発言権を申請し付与する手続が省略されるので、意見収集過程が簡素になり、それにより、時間を節約することができる。
【００２７】
また、意見収集結果をＰｏＣサーバで統計を行うので正確性を保障することができる。
【発明を実施するための最良の形態】
【００２８】
以下、本発明の好ましい実施形態を添付の図面を参照して説明する。以下の説明で、既に知られた構成や構成に関する詳細な説明は、発明の簡潔性及び明瞭化のために省略されている。
【００２９】
図５は、本発明を具現するためのＰｏＣサーバに関するブロックダイヤグラムであり、図６は、本発明を具現するためのＰｏＣ端末に関するブロックダイヤグラムである。
【００３０】
まず、ＰｏＣクライアントが意見投票機能（意見収集機能）を選択できなければならないので、図６に示すように、ＰｏＣクライアントが使用するＰｏＣ端末１１１０は、全体的な機能を制御する端末制御部１１１１と、意見投票機能が選択された場合に、セッション管理サーバに意見収集を要請する意見投票要請部１１１２とを含む。
【００３１】
同一セッションに参加中の他のユーザから或る任意の主題に対して意見を収集しようとする場合、ＰｏＣクライアントは、前記意見投票要請部１１１２を通じてセッション管理サーバに意見を収集することを要請することができる。
【００３２】
また、ＰｏＣ端末１１１０からの意見投票機能要請によって意見を収集するために、ＰｏＣサーバは、図５に示されたように、全般的な機能を制御するＰｏＣ制御部１０００と、各クライアントと連係されたセッションを管理してセッションを中継するＰｏＣ中継部１１００と、任意のＰｏＣ端末から意見投票機能を使用するための要請信号が受信されれば、意見投票機能の使用の認証及び他のユーザにより意見投票機能が占有されたか否かを判断する意見投票管理部１１０１とを含む。
【００３３】
前記意見投票管理部１１０１は、ＰｏＣユーザの意見投票機能（voting function）を活性化させ、活性化された意見投票機能の選択肢をユーザに通知し、ＰｏＣユーザが選択肢を見て決定した場合、ＰｏＣユーザからその結果を収集する。
【００３４】
上記のような構成が備えられた状態で、意見投票機能を使用するために、ＰｏＣクライアントは、ＰｏＣサーバに意見投票機能の使用を要請する。この要請を伝達するために、本発明は、ＴＢＣＰ（Talk Burst Control Protocol）としてＲＴＣＰ ＡＰＰを利用する。
【００３５】
ＯＭＡ（Open Mobile Alliance）において定義されたＰｏＣシステムでは、ＲＴＣＰ ＡＰＰパケットを基盤とするＴＢＣＰ（Talk Burst Control protocol）が使われる。このＴＢＣＰは、発言権を要請、付与、拒絶する時等のメッセージを運搬する役目をする。また、ＲＴＰを用いて情報を伝達するアプリケーションをコントロールする役目を行う。
【００３６】
ＲＴＣＰ ＡＰＰを利用した意見投票要請メッセージは、図９及び図１０を参照して後述する。
【００３７】
ＰｏＣサーバについてさらに詳述すれば、ＰｏＣサーバは、基本的にＰＦ（Participating PoC Function）、ＣＦ（Controlling PoC function）及び投票機能を提供する。
【００３８】
ＰＦとＣＦについての説明は、従来技術に詳細に説明されているので省略する。
【００３９】
前記ＰｏＣサーバでの意見投票機能を担当する意見投票管理部１１０１は、ＰｏＣクライアントから受信された意見投票機能活性化に対する応答をすることができる。例えば、意見投票機能を利用したり現在他の参加者が意見投票機能を使用しているので使用することができないなどの内容を応答手続を通じて伝達する。
【００４０】
前記意見投票管理部１１０１は、該当ＰｏＣグループに対して意見投票機能を活性化することができなければならない。すなわち意見投票管理部１１０１は、ＰｏＣサーバ自身の意見投票機能を活性化させ、該当ＰｏＣグループで意見投票機能を使用することを参加している全てのＰｏＣユーザに通知する。また、意見投票管理部１１０１は、ＰｏＣユーザが選択した決定を集めてその結果を計算及び結合し、ＰｏＣグループに参加している全てのＰｏＣユーザに最終結果を通知しなければならない。
【００４１】
図７は、本発明によってＰｏＣクライアントから意見を収集するための過程に関する信号の流れを示す図である。
【００４２】
まず、グループ通話中に任意の１の参加者（図７のＰｏＣクライアントＡ）が１の主題に対して全体の意見を収集する必要が発生すれば、投票機能をＰｏＣサーバ（ＰＦ Ａ、ＣＦ）１１００、１０００に要請する（Ｓ１０１、Ｓ１０２）。
【００４３】
投票機能要請を受けたＣＦ １０００は、進行中の意見投票機能が存在するかをチェックする。図７では、進行中の意見投票機能が存在しない場合を示している。
【００４４】
すると、ＣＦ １０００は、要請された意見投票機能を行うために意見投票機能を活性化させ（Ｓ１１０）、意見収集投票を行うことができるという応答メッセージを準備し、意見投票を要請したＰｏＣユーザ（ＰｏＣクライアントＡ）に伝達する（Ｓ１２０、Ｓ１２１）。
【００４５】
一方、進行中の意見投票機能が存在する場合には、要請拒否あるいは失敗メッセージを準備する。このような場合については、図８を参照して後に説明する。
【００４６】
意見投票機能を要請するためのメッセージは、グループの全ての参加者に伝達される（Ｓ１３１、Ｓ１３２）。
【００４７】
この時、伝達される意見投票機能のためのメッセージは、意見投票機能を要請したＰｏＣクライアントに関する情報、意見投票の主題及び他の関連情報を含む。
【００４８】
本発明で意見投票機能に使われるプロトコルは、ＲＴＣＰアプリケーションパケット（ＲＴＣＰ：ＡＰＰ）であり、Application dependant dataにＸＭＬを用いて意見投票関連情報を乗せて送られる。ここで、ＸＭＬ（Extensible Markup Language）を使用する前に、ＰｏＣ意見投票を定義するＸＭＬ schema文書を準備しなければならない。このＸＭＬ schemaは、各Document Instanceによって内容が異なることができる。例えば、この投票機能を定義するＸＭＬ schemaは、Initiator、投票開始時間、投票理由、各項目をFirst、Second、Third、Fourthなどとして多様な内容を定義する。そして、ＸＭＬ schemaに定義された内容は、ＲＴＣＰ ＡＰＰメッセージフォーマットのApplication dependant dataフィールドに記録され、ＰｏＣクライアントに伝達される。
【００４９】
一方、投票機能要請は、前記ＲＴＣＰ：ＡＰＰを用いて要請されることができるが、既存の発言権を用いてさらに容易な方法で要求することができる。この方式は、ＰｏＣユーザが発言権を獲得し、音声を通じて意見投票しようとする主題、そして主題を選択するための番号を提示する。
【００５０】
特に、ＰｏＣユーザが入力装置を介して任意の主題を選択すれば、その選択は、ＰｏＣサーバの意見投票管理部１１０１が選択された番号を読み取ることができるように送信されなければならない。
【００５１】
グループの各参加者が意見投票要請（voting request）とApplication dependant dataフィールドにＸＭＬを用いたメッセージを受信すれば、ＸＭＬがＸＭＬ schemaで定義した通りに使われたかに対する確認（validation）過程が遂行される。このために、ＰｏＣクライアントは、ＸＭＬ schemaを有するＸＭＬサーバ接続を提供する。仮に、ＸＭＬが正確に使われたと判断されれば、ＰｏＣクライアント内の意見投票機能のためにＸＭＬを用いた情報が、ＸＳＬＴ、ＨＴＴＰなどのＸＭＬを表現可能な言語を使用してディスプレイされる。ＰｏＣユーザは、キーパッドなどを用いて自身の決定を選択した後、これをさらにＰｏＣサーバに伝達する（Ｓ１３３）。例えば、1)オプション１、2)オプション２、3)オプション３、4)オプション４の中から１つを選択して、それをＲＴＣＰ ＡＰＰを通じてＰｏＣサーバに伝達する。
【００５２】
ＣＦ １０００は、各参加者から送信された決定を収集し（Ｓ１４０）、各項目別に結果を導き出す。前記収集過程は、1)オプション１、2)オプション２、3)オプション３、4)オプション４を押した参加者の数を計算し、必要に応じて百分率で表すこともでき、いろいろな統計指標で表すことができる。
【００５３】
次に、投票結果をグループに参加している全てのユーザに通知する（Ｓ１５０）。
【００５４】
Application dependent dataフィールドに何も作成せず、投票機能だけを開始（initiation）させるＲＴＣＰ：ＡＰＰメッセージを送る方式がありえる。
【００５５】
このような場合、ＰｏＣサーバ側に投票機能活性化に対する要請がまず受信され、意見投票主題（theme）及びこれと関連した情報が別途に受信されることができる。
【００５６】
図８は、他のユーザにより意見投票機能が既に占有された場合に関する信号の流れを示す図である。
【００５７】
まず、グループ通話中に任意の１の参加者（ＰｏＣクライアントＡ）が１つの主題に対して全体の意見収集を要求すれば、意見投票機能をＰｏＣサーバ（ＰＦ Ａ、ＣＦ）１１００、１０００に要請する（Ｓ２０１、Ｓ２０２）。
【００５８】
意見投票機能要請を受けたＣＦ １０００は、進行中の意見投票が存在するかをチェックする。進行中の意見投票機能が存在する場合（Ｓ２１０）、意見投票機能を要請したクライアントＡ １１１０に投票機能（voting function）が既に他のユーザにより占有されたことを通知するエラーメッセージを送信する（Ｓ３０１、Ｓ３０２）。
【００５９】
図９は、本発明を具現するためのＲＴＣＰ ＡＰＰパケットフォーマットを示す図であり、図１０は、図９の意見投票メッセージフィールドを示す図である。
【００６０】
図９及び図１０を参照すれば（ＩＥＴＦで定義しているＲＦＣ ３５５０参照）、ＲＴＣＰ ＡＰＰパケットは、最初の２ビットフィールドではＲＴＰのバージョン（version）を示している（本発明では、version＝２を示す）。
【００６１】
次のビットフィールドは、パディングビット（padding bit）フィールドである。パディングビットフィールドが与えられれば、ペイロードに属しない１または２のパディングoctetが付加されたものであることが分かる。
【００６２】
三番目の５ビットフィールドは、subtypeを示す（OMA PoC User plane specification文書参照）、このsubtypeを用いてＲＴＣＰ ＡＰＰパケットがどんなＴＢＣＰの役目を行っているか分かる。
【００６３】
例えば、現在ＯＭＡで準備されているスペックでは、ＴＢＣＰ Talk burst requestメッセージである場合には、subtypeの値が０００００に定義されており、ＴＢＣＰ Talk burst Granted messageである場合には、００００１に定義されている。現在まで１６個のＴＢＣＰ（Talk Burst Control Protocol）メッセージが定義されており、０１１１１までのsubtype値が定義されている。残りの１６個は、後に新しく生じるＴＢＣＰ Talk burst control messageのために予備（reserved）状態になっている。
【００６４】
従って、本発明では、１００００〜１１１１１からいずれか１つを選択してsubtype値を与えて他のＴＢＣＰ Talk burst control message値と区分することができる。残っているsubtype値１０００１を使用して他のＴＢＣＰ Talk burst controlメッセージ値と異なる形式で区分される。
【００６５】
しかし、この値が、残ったいずれの値を有するかに関係なく、メッセージの内容が投票を要求する機能を示す場合、同じＴＢＣＰ Talk burst controlメッセージとして見なす。
【００６６】
四番目の１byteフィールドは、packet typeとして２０４値を有し、このメッセージがＲＴＣＰ ＡＰＰパケットであることを示している。
【００６７】
五番目の２byteフィールドは、Lengthフィールドであって、メッセージの長さを示す。このフィールドに２が使われれば、前記メッセージは、２個の4byte octetがあることを示す。後にペイロードが付加されれば、このフィールドで全体４byte octetがいくつ存在するかを示す。
【００６８】
六番目の４byteフィールドは、Synchronization SouRCe/Contributing SouRCeフィールドである。このフィールドが示すものは、誰がＲＴＣＰ ＡＰＰメッセージを発信したかに対する同期化ソースを含んで誰が投票を要請したかを区分するようにする。
【００６９】
七番目の４byteフィールドは、ＡＳＣＩＩで表現される名前フィールドであり、そのメッセージがＰｏＣ投票に使われるメッセージであることを示している。
【００７０】
八番目は、Application dependant dataフィールドであって、Applicationを運用するのに必要な情報が記録される。特に、前記情報は、ＸＭＬを用いて意見投票機能の形式で作成した情報を含む。ＰｏＣクライアントやＰｏＣサーバの意見投票機能は、前記Application dependant dataフィールドの情報に基づいて機能を発揮するようになる。
【００７１】
Application dependant dataフィールドに１つのＸＭＬを利用したPoC vote requestの例を作成した。まず、１番目の項目は、version １．０とＵＴＦ−８でencodingしてＸＭＬを使用するという宣言文である。２番目の項目は、PoC_voteを使用し、www.samsung.comをnamespaceとして使用するという内容とwww.samsung.comのvote_service.xsdをＸＭＬスキーマ（schema）として使用するという内容を含む宣言文である。３番目の項目voting id＝“３９６２５”は、votingを使用し、ｉｄは、３９６２５の値を有することを示す。前記３９６２５値を通じて他の主題のvotingと区別することができる。そのサブ項目は、votingに含まれる情報を各々の項目を区分して記述したものである。例えば、votingを要請した人は、John Doeであり、voting開始時間は、２００５年３月１５日１６時５５分０５秒である。votingの主題は、‘会食メニュー決定のための投票’であり、その下部項目は、１．牛カルビ、２．三枚肉、３．海産物湯、４．ロブスターである。その下にあるvoting id＝“３９６２６’は、前記votingとは異なるvotingであって、１回のvoting requestに２回あるいはそれ以上のvotingをする場合に使用される。下記の図１１のvote_service.xsd XML schemaでさらに説明するが、schemaに定められた回数のvotingをすることができる。この例では、minOccurs=“1”maxOccurs=“unbounded”であるので、voting requestをする場合に少なくとも１つのvotingはなされなければならないし、それ以上は、votingを要請する人の決定によって無限代まですることができる。
【００７２】
図１１は、ＰｏＣ投票のためのＸＭＬスキーマ（schema）の一例を示す図である。図１１を参照すれば、まず、このＸＭＬ schemaは、ＰｏＣ投票をするための１つの例であって、図１０のApplication dependant dataフィールドに作成されたＸＭＬdocumentのために作成されている。
【００７３】
１番目の項目は、version １．０とＵＴＦ−８でencodingしてＸＭＬを使用するという宣言文である。２番目の項目は、ＸＭＬ schemaが作成された以後、www.samsung.comにschemaが定義され、www.w3.org/2001/XMLschema形式に従い、確認（validation）を通じてelement形式をこのschemaで定義された通り使用しなければならないこと、アトリビュート（attribute）項目は、定形化された形式が無いことを示す。３番目の項目からは、各elementに対する定義を記述している。まず、PoC_vote elementを定義し、PoC_vote下部elementとしてvoting elementがあることを示す。
【００７４】
voting elementのアトリビュートは、前記図１０で説明したように、少なくとも１回は使われなければならないし、それ以上は制限がなく、ＩＤを有するので他の投票と区別できる属性を有する。use=“required”の意味は、ｉｄは必ず使用されなければならないということである。voting elementは、Initiator、StartTime、Voting_reason、Item elementを有し、Item elementは、First、Second、Third、Fourth elementを有する。ThirdとFourthは、使用されないこともできることをminOccurs=“0”を通じて示している。すなわち多肢選択だけでなく二者択一のvotingを具現することができる。
【００７５】
本発明では、ＲＴＣＰ ＡＰＰの具現方法としてＸＭＬを例にとって説明した。しかし、テキストやＨＴＭＬ、ＳＩＰプロトコルによる具現も本発明の範囲に属することは、本発明の当業者にとって自明である。
【００７６】
以上、本発明の好ましい実施例について添付の図面を参照して説明したが、本発明は、前述の実施例に限定されるものでなく、本発明の属する技術分野において通常の知識を有する者が本発明の技術的思想及び範囲から逸脱しない範囲内で様々に変形または変更して実施することができる。
【産業上の利用可能性】
【００７７】
本発明は、意見収集過程が簡素になり、それにより、時間を節約することができる効果を有し、プッシュツートークオーバーセルラー網でＰｏＣ参加者の意見を収集する方法及びそのシステムとして有用である。
【図面の簡単な説明】
【００７８】
【図１】、一般的なＰｏＣ（Push-to-talk over Cellular）サービスシステムの概念図。
【図２】一般的なＰｏＣサーバの概略的な構成を示す図。
【図３】一般的なＰｏＣサーバのControlling PoC Function（ＣＦ）ブロックとParticipating PoC Function（ＰＦ）ブロックを示すための概念図。
【図４】ＰｏＣユーザが発言権を獲得する一般的な手続に関する信号の流れを示す図。
【図５】本発明を具現するためのＰｏＣサーバのブロックダイヤグラム。
【図６】本発明を具現するためのＰｏＣサーバのブロックダイヤグラム。
【図７】本発明によってＰｏＣクライアントから意見を収集するための過程に関する信号の流れを示す図。
【図８】他のＰｏＣユーザにより投票機能（voting function）が既に占有された場合に関する信号の流れを示す図。
【図９】本発明を具現するためのＲＴＣＰ ＡＰＰパケットのフォーマットを示す図。
【図１０】意見投票機能を要請する場合のメッセージフォーマットを示す図。
【図１１】ＰｏＣ投票のためＸＭＬスキーマ（schema）の一例を示す図。
【技術分野】
【０００１】
本発明は、プッシュツートークオーバーセルラー（Push to talk over Cellular：ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法に関する。
【背景技術】
【０００２】
移動通信が画期的に発展し、通信網が拡大されるにしたがって、携帯電話(Cellular Phone)を用いたサービスやアプリケーションがさらに拡張され且つ多様化されている。同時に、位置サービス、マルチメディアサービス、ＰＴＴ（push to talk）サービスのような付加的なサービスへの携帯電話ユーザの要求も増大している。ＰＴＴサービスは、無線機器やＴＲＳ(Trunk Radio System)によって可能であったグループ通話と音声通話はもちろん、インスタントメッセンジャー、状態表示など多様な付加機能を支援する。
【０００３】
現在、移動通信網においてこのようなＰＴＴ（Push to Talk）機能を導入するＰｏＣ（Push-to-talk over cellular:以下、ＰｏＣという）サービスに対する標準化作業が論議されている。ＰｏＣサービスの特徴のうち１つは、ユーザが複数のＰｏＣセッションに属していて、必要に応じてＰｏＣセッション間を移動しつつ通話をすることができることである。このような特徴は、移動通信サービスを定義している団体であるＯＭＡ（Open Mobile Alliance）に明示された要求事項である。
【０００４】
図１は、一般的なＰｏＣ（Push-to-talk over cellular）サービスシステムを概略的に示す図である。図１を参照すれば、ＰｏＣクライアント１０は、移動端末に設けられるサービス要請者であり、一般的にアクセス網２０を介してＳＩＰ（session Initiation Protocol）及びＩＰ（Internet Protocol）マルチメディアを支援するＳＩＰ／ＩＰコア３０網に連結される。
【０００５】
ＰｏＣクライアント１０は、ＰｏＣユーザ端末機に常駐し、ＰｏＣサービスへの接続を提供する。ＰｏＣクライアント１０は、主としてＰｏＣセッションを生成し、ＰｏＣセッションに参加し、ＰｏＣセッションを終了する。また、ＰｏＣクライアント１０は、トークバーストを形成し伝達する機能、インスタントパーソナルアラート(Instant Personal alert)を支援する機能、Ｐｏｃサービスに接続する時、認証を行う機能などの役目を行う。以下、別の言及がない限り、ＰｏＣクライアント１０とＰｏＣユーザは、Ｐｏｃサービス加入者と同じものとする。
【０００６】
ＳＩＰ／ＩＰコア３０は、ＰｏＣサービスを支援するために、ＰｏＣサーバ６０と、ＧＬＭＳ（Group List and Management System）５０、及びプレゼンスサーバ７０に連結される。
【０００７】
ＰｏＣサーバ６０は、ＰｏＣセッションを維持、管理するControlling PoC Function（ＣＦ）や、一対一のＰｏＣ通話や一対多通話(又はグループ通話)のためのＰｏＣセッションに参加するためのParticipating PoC Function（ＰＦ）などの機能を有する。
【０００８】
以下、ＰｏＣサーバ内の機能別ブロックを図２を参照して説明する。図２は、一般的なＰｏＣサーバの構成を示す概念図である。
【０００９】
ＰｏＣサーバは、ＰｏＣセッションの維持及び管理を全般的に制御するためのControlling PoC Function（以下、ＣＦという）と、各セッション間の維持管理を制御するParticipating PoC Function（以下、ＰＦという）を共に行う。以下、下記の表１、２を参照して説明する。
【００１０】
【表１】
表１に示されるように、ＣＦを行うＰｏＣサーバ（又はControlling PoCサーバ）は、ＰｏＣセッションを管理する役目をする。特に、Controlling PoCサーバは、ＰｏＣクライアントから発言権要請を受信し、順序を定め、クライアントに権限を付与する。Controlling PoCサーバは、任意のＰｏＣクライアントが要請したトークバーストをグループＰｏＣ呼に参加した全ての他のＰｏＣクライアントに分配し、グループＰｏＣ呼に参加したＰｏＣクライアントの情報を提供する。
【００１１】
下記表２に示されるように、ＰＦを行うＰｏＣサーバ（又はParticipating PoCサーバ）は、Controlling PoCサーバと各ＰｏＣクライアント間のＰｏＣセッションを管理する。特に、Participating PoCサーバは、ＰｏＣクライアントが発言権を要求したり、Controlling PoCサーバがＰｏＣクライアントに発言権を付与する時、Controlling PoCサーバとＰｏＣクライアントとの間で発言権を中継する役目をする。また、Participating PoCサーバは、Controlling PoCサーバとＰｏＣクライアントとの間にメディアを中継する役目、異なるコーデック間のトランスコーディングを行い、同時ＰｏＣセッションの場合には、１つのＰｏＣセッションで話している時、他のＰｏＣセッションでも話しながらＰｏＣユーザの選択によって１つをフィルタリングする役目を行う。
【００１２】
【表２】
前述したようなＰｏＣサービスシステムにおいて、ＰｏＣユーザの端末機を介してＧＬＭＳ５０にグループ及びグループメンバーに関する情報を入力することができ、ＧＬＭＳ５０から伝達された個人またはグループ目録を通じて自身が呼び出すことができる他のＰｏＣユーザの情報を受信することができる。あるいは、グループ及びグループメンバーの生成、修正及び管理のために、インターネットやイントラネットのような通信網を介してＧＬＭＳ５０に前記グループ及びグループメンバーに関する情報を入力する方法もある。
【００１３】
ＰｏＣ呼サービスを利用するために、ＰｏＣユーザは、ＳＩＰ／ＩＰコア３０にＰｏＣアドレスを登録する。ＳＩＰ／ＩＰコア３０は、ＰｏＣユーザの要請によりＰｏＣユーザに関する情報を格納する。したがって、他のＰｏＣユーザがグループＰｏＣ呼出を試みる場合、ＰｏＣユーザは、自身の情報をＳＩＰ／ＩＰコア３０にまず登録し、ＧＬＭＳ５０から伝達されたグループ識別情報を利用して自身のＳＩＰ／ＩＰコア３０にグループＰｏＣ呼を要請する。この時、ＳＩＰ／ＩＰコア３０は、要請するＰｏＣユーザ情報を利用してアドレス決定とドメイン位置決定を行った後、要請するＰｏＣユーザが登録されたホームＰｏＣサーバにＰｏＣ呼要請を伝達する。ＰｏＣサーバは、このようなＰｏＣ呼要請に対してＰｏＣセッション開設を準備し、ＧＬＭＳ５０から各ユーザ情報を獲得した後、該当ＳＩＰ／ＩＰコアにＰｏＣ呼要請信号を伝達する。イントラドメイン内のユーザに対するＰｏＣ呼要請の場合、ＰｏＣサーバは、ＰＦ及びＣＦの機能を共に行う。通話要請されたＰｏＣユーザを管理するＰｏＣサーバは、自身に伝達されたＰｏＣユーザの情報を利用してＳＩＰ／ＩＰコア３０の位置決定後、ＰｏＣユーザにＰｏＣ呼を要請する。
【００１４】
図３は、ＰｏＣサーバのＣＦブロックとＰＦブロックを概略的に示す図である。図３を参照すれば、ＰｏＣクライアント１１１、１２１、１３１、１４１は、ＰＦ１１０、１２０、１３０、１４０を介してＣＦ１００に接続してＰｏＣセッション開設を提供する。ここで、ＣＦ１００で許諾した発言要請者に発言権が付与されれば、該当ＰｏＣクライアントの発言を基盤とするメディアが各ＰｏＣクライアントに伝達される。
【００１５】
図４は、ＰｏＣユーザが発言権を獲得する一般的な手続に関する信号の流れを示す図である。
【００１６】
図４を参照すれば、発言権を獲得するために、ＰｏＣセッションがクライアントＡ １１１とクライアントＢ １２１を連結した状態でＰｏＣセッション内にいずれのＰｏＣクライアントも話していない時、ＰｏＣクライアントＡ １１１がＰｏＣ端末機に設置されたＰｏＣトークボタンを押す。
【００１７】
それにより、ＰｏＣクライアントＡ １１１は、発言権を要請するトークバースト要請（Talk Burst Request）メッセージをParticipating PoC functionの役目をするＰＦ Ａ １１０に伝達する（Ｓ１０１）。すると、ＰＦ Ａ １１０は、このセッションのControlling PoC functionの役目をするControlling PoCサーバ、すなわちＣＦ １００に前記トークバースト要請メッセージを伝達する（Ｓ１０１）。
【００１８】
ＣＦ １００は、トークバースト要請メッセージを受信した後、ＰｏＣクライアントＡ １１１に発言権を付与するトークバースト確認応答（Talk Burst Confirm Response）メッセージを伝達し（Ｓ１０２）、ＰｏＣクライアントＢ １２１にＰｏＣクライアントＡ １１１に発言権を付与した旨のユーザＡからのトークバースト受信（Receiving Talk Burst from User A）メッセージを送る（Ｓ１０３）。このメッセージには、話者、すなわちＰｏＣクライアントＡ １１１のＩＤが含まれており、これにより、ＰｏＣクライアントＢ １２１は、誰が話者なのかを把握することができる。
【００１９】
そして、メディアセッションが開かれ、ＰｏＣクライアントＡ １１１からトークバーストメディアがＰｏＣクライアントＢ １２１に伝達される（Ｓ１０４）。
【００２０】
しかし、前述のような従来技術は、グループＰｏＣ通話において、全体の意見を全て聞いて収集しようとする場合に、発言権を要請した全ての人の意見を考慮しなければならないので、発言権付与時間や、発言権が付与されたときの意見を提示する時間などに関する全ての手続をグループ員の数だけ行わなければならない。このため、手続が複雑であり、多くの時間が浪費される。
【発明の開示】
【発明が解決しようとする課題】
【００２１】
本発明の目的は、ＰｏＣシステムに意見を収集することができる意見投票機能を提供して、ユーザが意見を収集する時に、発言権の使用可否と関係なく意見投票手続を行うことができるＰｏＣネットワークにおけるＰｏＣクライアントの意見を収集する方法及びそのシステムを提供することにある。
【課題を解決するための手段】
【００２２】
本発明によれば、グループ内の任意のユーザからセッション管理サーバに投票機能使用要請及び投票しようとする内容を含むメッセージを伝達する段階と、セッション管理サーバで投票機能がグループ内の他のユーザにより占有された状態であるか否かを判断する段階と、セッション管理サーバで投票機能が他のユーザにより占有されていないものと判断されれば、グループに属する他のユーザに投票しようとする内容を伝達する段階と、他のグループユーザにより投票しようとする内容に対する応答を伝達する段階と、を含むプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法が提供される。
【００２３】
本発明によれば、グループ内の任意のユーザによりセッション管理サーバに投票機能の使用を要請する段階と、セッション管理サーバで投票機能が他のユーザにより占有された状態であるか否かを判断する段階と、セッション管理サーバで投票機能がグループ内の他のユーザにより占有されていないものと判断されれば、現在投票機能使用を要請したユーザに投票機能使用可能を通知する段階と、投票機能使用可能信号を受信したユーザが、投票しようとする内容をセッション管理サーバに伝達する段階と、セッション管理サーバでグループ内の他のユーザに投票しようとする内容を伝達する段階と、他のグループユーザが、投票しようとする内容に対する応答を送信する段階と、を含むＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法が提供される。
【００２４】
本発明によれば、投票機能の使用を要請する任意のクライアントと、任意のクライアントにより要請された投票機能に参加する少なくとも１つ以上のクライアントと、任意のクライアントから投票機能要請が伝達されれば、投票機能が他のユーザにより占有されているか否かを判断し、投票機能が他のユーザにより占有されていない場合、グループに属する他のユーザに投票しようとする内容を伝達するセッション管理サーバと、を含むＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステムが提供される。
【発明の効果】
【００２５】
本発明によれば、ＰｏＣユーザが、自身が参加しているグループ通話に多くの人々が参加している場合において、意思決定をしなければならない状況の発生時に、発言権と関係なく意見投票機能を１回に行うことによって、同時にいろいろな人々から意見を収集することができるようになる。
【００２６】
したがって、従来の発言権を申請し付与する手続が省略されるので、意見収集過程が簡素になり、それにより、時間を節約することができる。
【００２７】
また、意見収集結果をＰｏＣサーバで統計を行うので正確性を保障することができる。
【発明を実施するための最良の形態】
【００２８】
以下、本発明の好ましい実施形態を添付の図面を参照して説明する。以下の説明で、既に知られた構成や構成に関する詳細な説明は、発明の簡潔性及び明瞭化のために省略されている。
【００２９】
図５は、本発明を具現するためのＰｏＣサーバに関するブロックダイヤグラムであり、図６は、本発明を具現するためのＰｏＣ端末に関するブロックダイヤグラムである。
【００３０】
まず、ＰｏＣクライアントが意見投票機能（意見収集機能）を選択できなければならないので、図６に示すように、ＰｏＣクライアントが使用するＰｏＣ端末１１１０は、全体的な機能を制御する端末制御部１１１１と、意見投票機能が選択された場合に、セッション管理サーバに意見収集を要請する意見投票要請部１１１２とを含む。
【００３１】
同一セッションに参加中の他のユーザから或る任意の主題に対して意見を収集しようとする場合、ＰｏＣクライアントは、前記意見投票要請部１１１２を通じてセッション管理サーバに意見を収集することを要請することができる。
【００３２】
また、ＰｏＣ端末１１１０からの意見投票機能要請によって意見を収集するために、ＰｏＣサーバは、図５に示されたように、全般的な機能を制御するＰｏＣ制御部１０００と、各クライアントと連係されたセッションを管理してセッションを中継するＰｏＣ中継部１１００と、任意のＰｏＣ端末から意見投票機能を使用するための要請信号が受信されれば、意見投票機能の使用の認証及び他のユーザにより意見投票機能が占有されたか否かを判断する意見投票管理部１１０１とを含む。
【００３３】
前記意見投票管理部１１０１は、ＰｏＣユーザの意見投票機能（voting function）を活性化させ、活性化された意見投票機能の選択肢をユーザに通知し、ＰｏＣユーザが選択肢を見て決定した場合、ＰｏＣユーザからその結果を収集する。
【００３４】
上記のような構成が備えられた状態で、意見投票機能を使用するために、ＰｏＣクライアントは、ＰｏＣサーバに意見投票機能の使用を要請する。この要請を伝達するために、本発明は、ＴＢＣＰ（Talk Burst Control Protocol）としてＲＴＣＰ ＡＰＰを利用する。
【００３５】
ＯＭＡ（Open Mobile Alliance）において定義されたＰｏＣシステムでは、ＲＴＣＰ ＡＰＰパケットを基盤とするＴＢＣＰ（Talk Burst Control protocol）が使われる。このＴＢＣＰは、発言権を要請、付与、拒絶する時等のメッセージを運搬する役目をする。また、ＲＴＰを用いて情報を伝達するアプリケーションをコントロールする役目を行う。
【００３６】
ＲＴＣＰ ＡＰＰを利用した意見投票要請メッセージは、図９及び図１０を参照して後述する。
【００３７】
ＰｏＣサーバについてさらに詳述すれば、ＰｏＣサーバは、基本的にＰＦ（Participating PoC Function）、ＣＦ（Controlling PoC function）及び投票機能を提供する。
【００３８】
ＰＦとＣＦについての説明は、従来技術に詳細に説明されているので省略する。
【００３９】
前記ＰｏＣサーバでの意見投票機能を担当する意見投票管理部１１０１は、ＰｏＣクライアントから受信された意見投票機能活性化に対する応答をすることができる。例えば、意見投票機能を利用したり現在他の参加者が意見投票機能を使用しているので使用することができないなどの内容を応答手続を通じて伝達する。
【００４０】
前記意見投票管理部１１０１は、該当ＰｏＣグループに対して意見投票機能を活性化することができなければならない。すなわち意見投票管理部１１０１は、ＰｏＣサーバ自身の意見投票機能を活性化させ、該当ＰｏＣグループで意見投票機能を使用することを参加している全てのＰｏＣユーザに通知する。また、意見投票管理部１１０１は、ＰｏＣユーザが選択した決定を集めてその結果を計算及び結合し、ＰｏＣグループに参加している全てのＰｏＣユーザに最終結果を通知しなければならない。
【００４１】
図７は、本発明によってＰｏＣクライアントから意見を収集するための過程に関する信号の流れを示す図である。
【００４２】
まず、グループ通話中に任意の１の参加者（図７のＰｏＣクライアントＡ）が１の主題に対して全体の意見を収集する必要が発生すれば、投票機能をＰｏＣサーバ（ＰＦ Ａ、ＣＦ）１１００、１０００に要請する（Ｓ１０１、Ｓ１０２）。
【００４３】
投票機能要請を受けたＣＦ １０００は、進行中の意見投票機能が存在するかをチェックする。図７では、進行中の意見投票機能が存在しない場合を示している。
【００４４】
すると、ＣＦ １０００は、要請された意見投票機能を行うために意見投票機能を活性化させ（Ｓ１１０）、意見収集投票を行うことができるという応答メッセージを準備し、意見投票を要請したＰｏＣユーザ（ＰｏＣクライアントＡ）に伝達する（Ｓ１２０、Ｓ１２１）。
【００４５】
一方、進行中の意見投票機能が存在する場合には、要請拒否あるいは失敗メッセージを準備する。このような場合については、図８を参照して後に説明する。
【００４６】
意見投票機能を要請するためのメッセージは、グループの全ての参加者に伝達される（Ｓ１３１、Ｓ１３２）。
【００４７】
この時、伝達される意見投票機能のためのメッセージは、意見投票機能を要請したＰｏＣクライアントに関する情報、意見投票の主題及び他の関連情報を含む。
【００４８】
本発明で意見投票機能に使われるプロトコルは、ＲＴＣＰアプリケーションパケット（ＲＴＣＰ：ＡＰＰ）であり、Application dependant dataにＸＭＬを用いて意見投票関連情報を乗せて送られる。ここで、ＸＭＬ（Extensible Markup Language）を使用する前に、ＰｏＣ意見投票を定義するＸＭＬ schema文書を準備しなければならない。このＸＭＬ schemaは、各Document Instanceによって内容が異なることができる。例えば、この投票機能を定義するＸＭＬ schemaは、Initiator、投票開始時間、投票理由、各項目をFirst、Second、Third、Fourthなどとして多様な内容を定義する。そして、ＸＭＬ schemaに定義された内容は、ＲＴＣＰ ＡＰＰメッセージフォーマットのApplication dependant dataフィールドに記録され、ＰｏＣクライアントに伝達される。
【００４９】
一方、投票機能要請は、前記ＲＴＣＰ：ＡＰＰを用いて要請されることができるが、既存の発言権を用いてさらに容易な方法で要求することができる。この方式は、ＰｏＣユーザが発言権を獲得し、音声を通じて意見投票しようとする主題、そして主題を選択するための番号を提示する。
【００５０】
特に、ＰｏＣユーザが入力装置を介して任意の主題を選択すれば、その選択は、ＰｏＣサーバの意見投票管理部１１０１が選択された番号を読み取ることができるように送信されなければならない。
【００５１】
グループの各参加者が意見投票要請（voting request）とApplication dependant dataフィールドにＸＭＬを用いたメッセージを受信すれば、ＸＭＬがＸＭＬ schemaで定義した通りに使われたかに対する確認（validation）過程が遂行される。このために、ＰｏＣクライアントは、ＸＭＬ schemaを有するＸＭＬサーバ接続を提供する。仮に、ＸＭＬが正確に使われたと判断されれば、ＰｏＣクライアント内の意見投票機能のためにＸＭＬを用いた情報が、ＸＳＬＴ、ＨＴＴＰなどのＸＭＬを表現可能な言語を使用してディスプレイされる。ＰｏＣユーザは、キーパッドなどを用いて自身の決定を選択した後、これをさらにＰｏＣサーバに伝達する（Ｓ１３３）。例えば、1)オプション１、2)オプション２、3)オプション３、4)オプション４の中から１つを選択して、それをＲＴＣＰ ＡＰＰを通じてＰｏＣサーバに伝達する。
【００５２】
ＣＦ １０００は、各参加者から送信された決定を収集し（Ｓ１４０）、各項目別に結果を導き出す。前記収集過程は、1)オプション１、2)オプション２、3)オプション３、4)オプション４を押した参加者の数を計算し、必要に応じて百分率で表すこともでき、いろいろな統計指標で表すことができる。
【００５３】
次に、投票結果をグループに参加している全てのユーザに通知する（Ｓ１５０）。
【００５４】
Application dependent dataフィールドに何も作成せず、投票機能だけを開始（initiation）させるＲＴＣＰ：ＡＰＰメッセージを送る方式がありえる。
【００５５】
このような場合、ＰｏＣサーバ側に投票機能活性化に対する要請がまず受信され、意見投票主題（theme）及びこれと関連した情報が別途に受信されることができる。
【００５６】
図８は、他のユーザにより意見投票機能が既に占有された場合に関する信号の流れを示す図である。
【００５７】
まず、グループ通話中に任意の１の参加者（ＰｏＣクライアントＡ）が１つの主題に対して全体の意見収集を要求すれば、意見投票機能をＰｏＣサーバ（ＰＦ Ａ、ＣＦ）１１００、１０００に要請する（Ｓ２０１、Ｓ２０２）。
【００５８】
意見投票機能要請を受けたＣＦ １０００は、進行中の意見投票が存在するかをチェックする。進行中の意見投票機能が存在する場合（Ｓ２１０）、意見投票機能を要請したクライアントＡ １１１０に投票機能（voting function）が既に他のユーザにより占有されたことを通知するエラーメッセージを送信する（Ｓ３０１、Ｓ３０２）。
【００５９】
図９は、本発明を具現するためのＲＴＣＰ ＡＰＰパケットフォーマットを示す図であり、図１０は、図９の意見投票メッセージフィールドを示す図である。
【００６０】
図９及び図１０を参照すれば（ＩＥＴＦで定義しているＲＦＣ ３５５０参照）、ＲＴＣＰ ＡＰＰパケットは、最初の２ビットフィールドではＲＴＰのバージョン（version）を示している（本発明では、version＝２を示す）。
【００６１】
次のビットフィールドは、パディングビット（padding bit）フィールドである。パディングビットフィールドが与えられれば、ペイロードに属しない１または２のパディングoctetが付加されたものであることが分かる。
【００６２】
三番目の５ビットフィールドは、subtypeを示す（OMA PoC User plane specification文書参照）、このsubtypeを用いてＲＴＣＰ ＡＰＰパケットがどんなＴＢＣＰの役目を行っているか分かる。
【００６３】
例えば、現在ＯＭＡで準備されているスペックでは、ＴＢＣＰ Talk burst requestメッセージである場合には、subtypeの値が０００００に定義されており、ＴＢＣＰ Talk burst Granted messageである場合には、００００１に定義されている。現在まで１６個のＴＢＣＰ（Talk Burst Control Protocol）メッセージが定義されており、０１１１１までのsubtype値が定義されている。残りの１６個は、後に新しく生じるＴＢＣＰ Talk burst control messageのために予備（reserved）状態になっている。
【００６４】
従って、本発明では、１００００〜１１１１１からいずれか１つを選択してsubtype値を与えて他のＴＢＣＰ Talk burst control message値と区分することができる。残っているsubtype値１０００１を使用して他のＴＢＣＰ Talk burst controlメッセージ値と異なる形式で区分される。
【００６５】
しかし、この値が、残ったいずれの値を有するかに関係なく、メッセージの内容が投票を要求する機能を示す場合、同じＴＢＣＰ Talk burst controlメッセージとして見なす。
【００６６】
四番目の１byteフィールドは、packet typeとして２０４値を有し、このメッセージがＲＴＣＰ ＡＰＰパケットであることを示している。
【００６７】
五番目の２byteフィールドは、Lengthフィールドであって、メッセージの長さを示す。このフィールドに２が使われれば、前記メッセージは、２個の4byte octetがあることを示す。後にペイロードが付加されれば、このフィールドで全体４byte octetがいくつ存在するかを示す。
【００６８】
六番目の４byteフィールドは、Synchronization SouRCe/Contributing SouRCeフィールドである。このフィールドが示すものは、誰がＲＴＣＰ ＡＰＰメッセージを発信したかに対する同期化ソースを含んで誰が投票を要請したかを区分するようにする。
【００６９】
七番目の４byteフィールドは、ＡＳＣＩＩで表現される名前フィールドであり、そのメッセージがＰｏＣ投票に使われるメッセージであることを示している。
【００７０】
八番目は、Application dependant dataフィールドであって、Applicationを運用するのに必要な情報が記録される。特に、前記情報は、ＸＭＬを用いて意見投票機能の形式で作成した情報を含む。ＰｏＣクライアントやＰｏＣサーバの意見投票機能は、前記Application dependant dataフィールドの情報に基づいて機能を発揮するようになる。
【００７１】
Application dependant dataフィールドに１つのＸＭＬを利用したPoC vote requestの例を作成した。まず、１番目の項目は、version １．０とＵＴＦ−８でencodingしてＸＭＬを使用するという宣言文である。２番目の項目は、PoC_voteを使用し、www.samsung.comをnamespaceとして使用するという内容とwww.samsung.comのvote_service.xsdをＸＭＬスキーマ（schema）として使用するという内容を含む宣言文である。３番目の項目voting id＝“３９６２５”は、votingを使用し、ｉｄは、３９６２５の値を有することを示す。前記３９６２５値を通じて他の主題のvotingと区別することができる。そのサブ項目は、votingに含まれる情報を各々の項目を区分して記述したものである。例えば、votingを要請した人は、John Doeであり、voting開始時間は、２００５年３月１５日１６時５５分０５秒である。votingの主題は、‘会食メニュー決定のための投票’であり、その下部項目は、１．牛カルビ、２．三枚肉、３．海産物湯、４．ロブスターである。その下にあるvoting id＝“３９６２６’は、前記votingとは異なるvotingであって、１回のvoting requestに２回あるいはそれ以上のvotingをする場合に使用される。下記の図１１のvote_service.xsd XML schemaでさらに説明するが、schemaに定められた回数のvotingをすることができる。この例では、minOccurs=“1”maxOccurs=“unbounded”であるので、voting requestをする場合に少なくとも１つのvotingはなされなければならないし、それ以上は、votingを要請する人の決定によって無限代まですることができる。
【００７２】
図１１は、ＰｏＣ投票のためのＸＭＬスキーマ（schema）の一例を示す図である。図１１を参照すれば、まず、このＸＭＬ schemaは、ＰｏＣ投票をするための１つの例であって、図１０のApplication dependant dataフィールドに作成されたＸＭＬdocumentのために作成されている。
【００７３】
１番目の項目は、version １．０とＵＴＦ−８でencodingしてＸＭＬを使用するという宣言文である。２番目の項目は、ＸＭＬ schemaが作成された以後、www.samsung.comにschemaが定義され、www.w3.org/2001/XMLschema形式に従い、確認（validation）を通じてelement形式をこのschemaで定義された通り使用しなければならないこと、アトリビュート（attribute）項目は、定形化された形式が無いことを示す。３番目の項目からは、各elementに対する定義を記述している。まず、PoC_vote elementを定義し、PoC_vote下部elementとしてvoting elementがあることを示す。
【００７４】
voting elementのアトリビュートは、前記図１０で説明したように、少なくとも１回は使われなければならないし、それ以上は制限がなく、ＩＤを有するので他の投票と区別できる属性を有する。use=“required”の意味は、ｉｄは必ず使用されなければならないということである。voting elementは、Initiator、StartTime、Voting_reason、Item elementを有し、Item elementは、First、Second、Third、Fourth elementを有する。ThirdとFourthは、使用されないこともできることをminOccurs=“0”を通じて示している。すなわち多肢選択だけでなく二者択一のvotingを具現することができる。
【００７５】
本発明では、ＲＴＣＰ ＡＰＰの具現方法としてＸＭＬを例にとって説明した。しかし、テキストやＨＴＭＬ、ＳＩＰプロトコルによる具現も本発明の範囲に属することは、本発明の当業者にとって自明である。
【００７６】
以上、本発明の好ましい実施例について添付の図面を参照して説明したが、本発明は、前述の実施例に限定されるものでなく、本発明の属する技術分野において通常の知識を有する者が本発明の技術的思想及び範囲から逸脱しない範囲内で様々に変形または変更して実施することができる。
【産業上の利用可能性】
【００７７】
本発明は、意見収集過程が簡素になり、それにより、時間を節約することができる効果を有し、プッシュツートークオーバーセルラー網でＰｏＣ参加者の意見を収集する方法及びそのシステムとして有用である。
【図面の簡単な説明】
【００７８】
【図１】、一般的なＰｏＣ（Push-to-talk over Cellular）サービスシステムの概念図。
【図２】一般的なＰｏＣサーバの概略的な構成を示す図。
【図３】一般的なＰｏＣサーバのControlling PoC Function（ＣＦ）ブロックとParticipating PoC Function（ＰＦ）ブロックを示すための概念図。
【図４】ＰｏＣユーザが発言権を獲得する一般的な手続に関する信号の流れを示す図。
【図５】本発明を具現するためのＰｏＣサーバのブロックダイヤグラム。
【図６】本発明を具現するためのＰｏＣサーバのブロックダイヤグラム。
【図７】本発明によってＰｏＣクライアントから意見を収集するための過程に関する信号の流れを示す図。
【図８】他のＰｏＣユーザにより投票機能（voting function）が既に占有された場合に関する信号の流れを示す図。
【図９】本発明を具現するためのＲＴＣＰ ＡＰＰパケットのフォーマットを示す図。
【図１０】意見投票機能を要請する場合のメッセージフォーマットを示す図。
【図１１】ＰｏＣ投票のためＸＭＬスキーマ（schema）の一例を示す図。
【特許請求の範囲】
【請求項１】
プッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法において、
グループ内の任意のユーザからセッション管理サーバに投票機能使用要請及び投票しようとする内容を含むメッセージを伝達する段階と、
セッション管理サーバで投票機能がグループ内の他のユーザにより占有された状態であるか否かを判断する段階と、
セッション管理サーバで投票機能が他のユーザにより占有されていないものと判断されれば、グループに属する他のユーザに投票しようとする内容を伝達する段階と、
他のグループユーザから投票しようとする内容に対する応答を伝達する段階と、を含むプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項２】
投票機能が他のユーザにより占有された状態であると判断されれば、投票機能を要請したユーザに他のユーザにより投票機能が占有されたことを通知する段階をさらに含むことを特徴とする請求項１に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項３】
前記投票しようとする内容に対する応答を送信する段階以後、セッション管理サーバは、投票結果をグループユーザに通知する段階をさらに含むことを特徴とする請求項１に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項４】
前記投票しようとする内容に対する応答を送信する段階以後、セッション管理サーバは、投票結果統計を収集する段階をさらに含むことを特徴とする請求項１に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項５】
前記投票機能使用要請及び投票しようとする内容を含むメッセージは、ＲＴＣＰ（Real-time Transport Control Protocol）ＡＰＰ（application）パケットのＴＢＣＰ（Talk Burst Control Protocol）メッセージを利用することを特徴とする請求項１に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項６】
前記投票機能使用要請及び投票しようとする内容情報提供のためのＴＢＣＰメッセージは、ＲＴＣＰ ＡＰＰパケットのサブタイプ（subtype）フィールドの予備値として選択することを特徴とする請求項５に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項７】
前記投票機能使用要請のために、ＲＴＣＰ ＡＰＰパケットのＳＳＲＣ（Synchronization SouRC）フィールドに投票機能を要請したユーザソースを含むことを特徴とする請求項６に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項８】
前記投票しようとする内容は、ＲＴＣＰ ＡＰＰパケットのApplication dependent dataフィールドに記録されることを特徴とする請求項６に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項９】
ＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法において、
グループ内の任意のユーザによりセッション管理サーバに投票機能使用を要請する段階と、
セッション管理サーバで投票機能が他のユーザにより占有された状態であるか否かを判断する段階と、
セッション管理サーバで投票機能がグループ内の他のユーザにより占有されていないものと判断されれば、現在投票機能使用を要請したユーザに投票機能使用可能を通知する段階と、
投票機能使用可能信号を受信したユーザは、投票しようとする内容をセッション管理サーバに伝達する段階と、
セッション管理サーバでグループ内の他のユーザに投票しようとする内容を伝達する段階と、
他のグループユーザにより投票しようとする内容に対する応答を送信する段階と、を含むＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
【請求項１０】
前記投票機能が他のユーザにより占有された状態であると判断されれば、投票機能を要請したユーザに他のユーザにより投票機能が占有されたことを通知する段階をさらに含むことを特徴とする請求項９に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
【請求項１１】
前記投票しようとする内容に対する応答を送信する段階以後、セッション管理サーバは、投票結果をグループユーザに通知する段階をさらに含むことを特徴とする請求項９に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
【請求項１２】
前記投票しようとする内容に対する応答を送信する段階以後、セッション管理サーバは、投票結果統計を収集する段階をさらに含むことを特徴とする請求項９に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
【請求項１３】
前記投票機能使用要請及び投票しようとする内容を含むメッセージは、ＲＴＣＰ（Real-time Transport Control Protocol）ＡＰＰ（application）パケットのＴＢＣＰ（Talk Burst Control Protocol）メッセージを利用することを特徴とする請求項９に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
【請求項１４】
前記投票機能使用要請のために、ＲＴＣＰ ＡＰＰパケットのＳＳＲＣ（Synchronization SouRC）フィールドに投票機能を要請したユーザソースを含むことを特徴とする請求項１３に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
【請求項１５】
前記投票機能使用可能信号が受信された後、投票しようとする内容情報をセッション管理サーバに伝達する段階で伝達される投票しようとする内容は、ＸＭＬで作成されて伝達されることを特徴とする請求項９に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
【請求項１６】
ＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステムにおいて、
投票機能使用を要請する任意のクライアントと、
任意のクライアントにより要請された投票機能に参加する少なくとも１つ以上のクライアントと、
任意のクライアントから投票機能要請が伝達されれば、投票機能が他のユーザにより占有されているか否かを判断し、投票機能が他のユーザにより占有されていない場合、グループに属する他のユーザに投票しようとする内容を伝達するセッション管理サーバと、を含むＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステム。
【請求項１７】
前記投票機能が他のユーザにより占有された場合、前記セッション管理サーバは、投票機能を要請したユーザに他のユーザにより投票機能が占有されたことを通知することを特徴とする請求項１６に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステム。
【請求項１８】
前記セッション管理サーバは、グループユーザから投票しようとする内容に対する応答を受信すれば、投票結果統計を収集し、投票結果をグループユーザに通知することを特徴とする請求項１７に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステム。
【請求項１９】
前記投票機能使用要請及び投票しようとする内容を含むメッセージは、ＲＴＣＰ（Real-time Transport Control Protocol）ＡＰＰ（application）パケットのＴＢＣＰ（Talk Burst Control Protocol）メッセージを利用することを特徴とする請求項１６に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステム。
【請求項２０】
前記投票機能使用要請のために、ＲＴＣＰ ＡＰＰパケットのＳＳＲＣ（Synchronization SouRC）フィールドに投票機能を要請したユーザソースを含むことを特徴とする請求項１６に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステム。
【請求項２１】
前記投票しようとする内容情報は、ＲＴＣＰ ＡＰＰパケットのApplication dependent dataフィールドに記録されることを特徴とする請求項１６に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステム。
【請求項２２】
前記投票機能使用可能信号を受信した後、投票しようとする内容情報をセッション管理サーバに伝達する段階で投票しようとする内容は、ＸＭＬで作成されて伝達されることを特徴とする請求項１６に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステム。
【請求項２３】
ＰｏＣネットワークでＰｏＣクライアントの意見を収集するために投票機能を要請する端末において、
端末の全体機能を制御する制御部と、
意見投票機能使用の要請時に、セッション管理サーバに意見投票を要請する意見投票要請部と、を含むＰｏＣネットワークでＰｏＣクライアントの意見を収集するために投票機能を要請する端末。
【請求項２４】
ＰｏＣネットワークでＰｏＣクライアントの意見を収集するために投票機能を提供するセッション管理サーバにおいて、
グループ内の任意のクライアントから投票機能を使用するための要請が伝達されれば、投票機能がグループ内の他のユーザにより占有された状態であるか否かを判断し、投票機能がグループ内の他のユーザにより占有されていない場合、グループに属するユーザに投票しようとする内容を伝達するセッション管理サーバ。
【請求項１】
プッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法において、
グループ内の任意のユーザからセッション管理サーバに投票機能使用要請及び投票しようとする内容を含むメッセージを伝達する段階と、
セッション管理サーバで投票機能がグループ内の他のユーザにより占有された状態であるか否かを判断する段階と、
セッション管理サーバで投票機能が他のユーザにより占有されていないものと判断されれば、グループに属する他のユーザに投票しようとする内容を伝達する段階と、
他のグループユーザから投票しようとする内容に対する応答を伝達する段階と、を含むプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項２】
投票機能が他のユーザにより占有された状態であると判断されれば、投票機能を要請したユーザに他のユーザにより投票機能が占有されたことを通知する段階をさらに含むことを特徴とする請求項１に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項３】
前記投票しようとする内容に対する応答を送信する段階以後、セッション管理サーバは、投票結果をグループユーザに通知する段階をさらに含むことを特徴とする請求項１に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項４】
前記投票しようとする内容に対する応答を送信する段階以後、セッション管理サーバは、投票結果統計を収集する段階をさらに含むことを特徴とする請求項１に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項５】
前記投票機能使用要請及び投票しようとする内容を含むメッセージは、ＲＴＣＰ（Real-time Transport Control Protocol）ＡＰＰ（application）パケットのＴＢＣＰ（Talk Burst Control Protocol）メッセージを利用することを特徴とする請求項１に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項６】
前記投票機能使用要請及び投票しようとする内容情報提供のためのＴＢＣＰメッセージは、ＲＴＣＰ ＡＰＰパケットのサブタイプ（subtype）フィールドの予備値として選択することを特徴とする請求項５に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項７】
前記投票機能使用要請のために、ＲＴＣＰ ＡＰＰパケットのＳＳＲＣ（Synchronization SouRC）フィールドに投票機能を要請したユーザソースを含むことを特徴とする請求項６に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項８】
前記投票しようとする内容は、ＲＴＣＰ ＡＰＰパケットのApplication dependent dataフィールドに記録されることを特徴とする請求項６に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
【請求項９】
ＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法において、
グループ内の任意のユーザによりセッション管理サーバに投票機能使用を要請する段階と、
セッション管理サーバで投票機能が他のユーザにより占有された状態であるか否かを判断する段階と、
セッション管理サーバで投票機能がグループ内の他のユーザにより占有されていないものと判断されれば、現在投票機能使用を要請したユーザに投票機能使用可能を通知する段階と、
投票機能使用可能信号を受信したユーザは、投票しようとする内容をセッション管理サーバに伝達する段階と、
セッション管理サーバでグループ内の他のユーザに投票しようとする内容を伝達する段階と、
他のグループユーザにより投票しようとする内容に対する応答を送信する段階と、を含むＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
【請求項１０】
前記投票機能が他のユーザにより占有された状態であると判断されれば、投票機能を要請したユーザに他のユーザにより投票機能が占有されたことを通知する段階をさらに含むことを特徴とする請求項９に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
【請求項１１】
前記投票しようとする内容に対する応答を送信する段階以後、セッション管理サーバは、投票結果をグループユーザに通知する段階をさらに含むことを特徴とする請求項９に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
【請求項１２】
前記投票しようとする内容に対する応答を送信する段階以後、セッション管理サーバは、投票結果統計を収集する段階をさらに含むことを特徴とする請求項９に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
【請求項１３】
前記投票機能使用要請及び投票しようとする内容を含むメッセージは、ＲＴＣＰ（Real-time Transport Control Protocol）ＡＰＰ（application）パケットのＴＢＣＰ（Talk Burst Control Protocol）メッセージを利用することを特徴とする請求項９に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
【請求項１４】
前記投票機能使用要請のために、ＲＴＣＰ ＡＰＰパケットのＳＳＲＣ（Synchronization SouRC）フィールドに投票機能を要請したユーザソースを含むことを特徴とする請求項１３に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
【請求項１５】
前記投票機能使用可能信号が受信された後、投票しようとする内容情報をセッション管理サーバに伝達する段階で伝達される投票しようとする内容は、ＸＭＬで作成されて伝達されることを特徴とする請求項９に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
【請求項１６】
ＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステムにおいて、
投票機能使用を要請する任意のクライアントと、
任意のクライアントにより要請された投票機能に参加する少なくとも１つ以上のクライアントと、
任意のクライアントから投票機能要請が伝達されれば、投票機能が他のユーザにより占有されているか否かを判断し、投票機能が他のユーザにより占有されていない場合、グループに属する他のユーザに投票しようとする内容を伝達するセッション管理サーバと、を含むＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステム。
【請求項１７】
前記投票機能が他のユーザにより占有された場合、前記セッション管理サーバは、投票機能を要請したユーザに他のユーザにより投票機能が占有されたことを通知することを特徴とする請求項１６に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステム。
【請求項１８】
前記セッション管理サーバは、グループユーザから投票しようとする内容に対する応答を受信すれば、投票結果統計を収集し、投票結果をグループユーザに通知することを特徴とする請求項１７に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステム。
【請求項１９】
前記投票機能使用要請及び投票しようとする内容を含むメッセージは、ＲＴＣＰ（Real-time Transport Control Protocol）ＡＰＰ（application）パケットのＴＢＣＰ（Talk Burst Control Protocol）メッセージを利用することを特徴とする請求項１６に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステム。
【請求項２０】
前記投票機能使用要請のために、ＲＴＣＰ ＡＰＰパケットのＳＳＲＣ（Synchronization SouRC）フィールドに投票機能を要請したユーザソースを含むことを特徴とする請求項１６に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステム。
【請求項２１】
前記投票しようとする内容情報は、ＲＴＣＰ ＡＰＰパケットのApplication dependent dataフィールドに記録されることを特徴とする請求項１６に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステム。
【請求項２２】
前記投票機能使用可能信号を受信した後、投票しようとする内容情報をセッション管理サーバに伝達する段階で投票しようとする内容は、ＸＭＬで作成されて伝達されることを特徴とする請求項１６に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集するシステム。
【請求項２３】
ＰｏＣネットワークでＰｏＣクライアントの意見を収集するために投票機能を要請する端末において、
端末の全体機能を制御する制御部と、
意見投票機能使用の要請時に、セッション管理サーバに意見投票を要請する意見投票要請部と、を含むＰｏＣネットワークでＰｏＣクライアントの意見を収集するために投票機能を要請する端末。
【請求項２４】
ＰｏＣネットワークでＰｏＣクライアントの意見を収集するために投票機能を提供するセッション管理サーバにおいて、
グループ内の任意のクライアントから投票機能を使用するための要請が伝達されれば、投票機能がグループ内の他のユーザにより占有された状態であるか否かを判断し、投票機能がグループ内の他のユーザにより占有されていない場合、グループに属するユーザに投票しようとする内容を伝達するセッション管理サーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公表番号】特表２００８−５３７３７７（Ｐ２００８−５３７３７７Ａ）
【公表日】平成２０年９月１１日（２００８．９．１１）
【国際特許分類】
【出願番号】特願２００８−５０２９０４（Ｐ２００８−５０２９０４）
【出願日】平成１８年３月２２日（２００６．３．２２）
【国際出願番号】ＰＣＴ／ＫＲ２００６／００１０３５
【国際公開番号】ＷＯ２００６／１０１３４０
【国際公開日】平成１８年９月２８日（２００６．９．２８）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
【公表日】平成２０年９月１１日（２００８．９．１１）
【国際特許分類】
【出願日】平成１８年３月２２日（２００６．３．２２）
【国際出願番号】ＰＣＴ／ＫＲ２００６／００１０３５
【国際公開番号】ＷＯ２００６／１０１３４０
【国際公開日】平成１８年９月２８日（２００６．９．２８）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
[ Back to top ]