JP5208724B2

JP5208724B2 - プッシュツートークオーバーセルラー網でＰｏＣ参加者の意見を収集する方法及びそのシステム

Info

Publication number: JP5208724B2
Application number: JP2008502904A
Authority: JP
Inventors: スン−ジンパク; ジュン−グパク; サン−キュンスン; ボ−スンジュン
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2005-03-22
Filing date: 2006-03-22
Publication date: 2013-06-12
Anticipated expiration: 2026-03-22
Also published as: CN101147361B; US20060234745A1; CN101147361A; WO2006101340A1; KR101158573B1; JP2008537377A; EP1861959A1; US7577454B2; EP1861959B1; KR20060102054A; EP1861959A4

Description

本発明は、プッシュツートークオーバーセルラー（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）の一例を示す図。

Claims

プッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法において、
ＰｏＣクライアントがＰｏＣサーバに投票機能使用要請及び二つ以上の投票主題と前記二つ以上の投票主題に関連した情報とを含む投票しようとする内容を含むメッセージを伝達する段階と、
前記ＰｏＣサーバで投票機能が前記ＰｏＣ網上の他のＰｏＣクライアントにより占有された状態であるか否かを判断する段階と、
前記ＰｏＣサーバで前記投票機能が前記ＰｏＣ網上の前記他のＰｏＣクライアントにより占有されていないものと判断されれば、前記ＰｏＣ網上のＰｏＣクライアントに前記投票しようとする内容を伝達する段階と、
前記ＰｏＣ網上のＰｏＣクライアントが前記投票しようとする内容に対する応答を前記ＰｏＣサーバに伝達する段階と、を含むプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
投票機能が前記ＰｏＣ網上の前記他のＰｏＣクライアントにより占有された状態であると判断されれば、前記ＰｏＣクライアントに、前記ＰｏＣ網上の前記他のＰｏＣクライアントにより投票機能が占有されたことを通知する段階をさらに含むことを特徴とする請求項１に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
前記投票しようとする内容に対する応答を送信する段階以後、前記ＰｏＣサーバは、投票結果を前記ＰｏＣクライアントに通知する段階をさらに含むことを特徴とする請求項１に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
前記投票しようとする内容に対する応答を送信する段階以後、前記ＰｏＣサーバが投票結果統計を収集する段階をさらに含むことを特徴とする請求項１に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
前記投票機能使用要請及び投票しようとする内容を含むメッセージは、ＲＴＣＰ（Realtime Transport Control Protocol）ＡＰＰ（application）パケットのＴＢＣＰ（Talk Burst Control Protocol）メッセージを利用することを特徴とする請求項１に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
前記投票機能使用要請及び投票しようとする内容情報提供のためのＴＢＣＰメッセージは、ＲＴＣＰＡＰＰパケットのサブタイプ（subtype）フィールドの予備値として選択することを特徴とする請求項５に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
前記投票機能使用要請のために、ＲＴＣＰＡＰＰパケットのＳＳＲＣ（Synchronization SouRC）フィールドに投票機能を要請したユーザソースを含むことを特徴とする請求項６に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
前記投票しようとする内容は、ＲＴＣＰＡＰＰパケットのApplication dependent dataフィールドに記録されることを特徴とする請求項６に記載のプッシュツートークオーバーセルラー（ＰｏＣ）網でＰｏＣ参加者の意見を収集する方法。
ＰｏＣネットワーク上でＰｏＣサーバがＰｏＣクライアントの意見を収集する方法において、
ＰｏＣクライアントから意見投票動作を遂行する投票機能の使用を要請するための投票機能使用要請を受信する段階と、
投票機能が他のＰｏＣクライアントにより占有された状態であるか否かを判断する段階と、
前記投票機能が前記他のＰｏＣクライアントにより占有されていないものと判断されれば、前記ＰｏＣクライアントに投票機能使用可能を通知する段階と、
前記ＰｏＣクライアントから二つ以上の投票主題と前記二つ以上の投票主題に関連した情報とを含む投票しようとする内容を受信する段階と、
前記ＰｏＣネットワーク上のＰｏＣクライアントに前記投票しようとする内容を伝達する段階と、
前記ＰｏＣネットワーク上のＰｏＣクライアントから前記投票しようとする内容に対する応答を収集する段階と、を含むＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
前記投票機能が前記他のＰｏＣクライアントにより占有された状態であると判断されれば、前記ＰｏＣクライアントに、前記他のＰｏＣクライアントにより投票機能が占有されたことを通知する段階をさらに含むことを特徴とする請求項９に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
前記投票しようとする内容に対する応答を送信する段階以後、投票結果を前記ＰｏＣネットワーク上のＰｏＣクライアントに通知する段階をさらに含むことを特徴とする請求項９に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
前記投票しようとする内容に対する応答を送信する段階以後、投票結果統計を収集する段階をさらに含むことを特徴とする請求項９に記載のＰｏＣネットワークでＰｏＣクライアントの意見を収集する方法。
ＰｏＣネットワークでＰｏＣクライアントの意見を収集するために投票機能を提供するＰｏＣサーバにおいて、
要請ＰｏＣクライアントから意見投票動作を遂行する投票機能を使用するための投票機能要請を受信し、前記投票機能が他のＰｏＣクライアントにより占有された状態であるか否かを判断し、前記投票機能が前記他のＰｏＣクライアントにより占有されていない場合、前記要請ＰｏＣクライアントに投票機能使用可能を通知した後、前記要請ＰｏＣクライアントより二つ以上の投票主題と前記二つ以上の投票主題に関連した情報を含む投票しようとする内容を受信してＰｏＣクライアントに伝達し、前記ＰｏＣクライアントより前記投票しようとする内容に対する応答を収集することを特徴とするＰｏＣサーバ。
前記投票機能が前記他のＰｏＣクライアントにより占有された状態であると判断されれば、前記要請ＰｏＣクライアントに前記他のＰｏＣクライアントにより投票機能が占有されたことを通知することを特徴とする請求項１３に記載のＰｏＣサーバ。
投票結果を前記ＰｏＣクライアントに通知することを特徴とする請求項１３に記載のＰｏＣサーバ。
投票結果統計を収集することを特徴とする請求項１３に記載のＰｏＣサーバ。
ＰｏＣクライアントの意見を収集する方法において、
投票機能使用要請及び二つ以上の投票主題と前記二つ以上の投票主題に関連した情報とを含む投票しようとする内容を生成する過程と、
ＰｏＣサーバに投票機能の使用を要請する過程と、
前記ＰｏＣサーバから投票機能使用可能を受信する過程と、
ＰｏＣクライアントに前記投票しようとする内容を伝達するために、前記ＰｏＣサーバに前記投票しようとする内容を伝達する過程と、を含むＰｏＣクライアントの意見を収集する方法。
前記投票機能使用要請及び前記投票しようとする内容を含むメッセージは、ＲＴＣＰ（Realtime Transport Control Protocol）ＡＰＰ（application）パケットのＴＢＣＰ（Talk Burst Control Protocol）メッセージを利用することを特徴とする請求項１７に記載のＰｏＣクライアントの意見を収集する方法。
前記投票機能使用要請のために、ＲＴＣＰＡＰＰパケットのＳＳＲＣ（Synchronization SouRC)フィールドに投票機能を要請したユーザソースを含むことを特徴とする請求項１８に記載のＰｏＣクライアントの意見を収集する方法。
前記投票機能使用可能信号を受信した後、投票しようとする内容を前記ＰｏＣサーバに伝達する段階で伝達される前記投票しようとする内容は、ＸＭＬで作成されて伝達されることを特徴とする請求項１８に記載のＰｏＣクライアントの意見を収集する方法。